¿Puedo hacer cumplir una rama de solo fusión en git?

Question

estoy usando git, y Soy la creación de las siguientes ramas para soportar mi flujo de trabajo:

• liberación, que sólo contiene lanzó el software,
• pruebas, que contiene software lanzado al grupo de prueba,
• desarrollar, que es donde ocurre el desarrollo,
• some_topic_branch, donde las características, etc. agregarán.

Las ramas de tema se ramifican y se fusionan en develop. Cuando estemos listos para una versión de prueba, las pruebas de fusión se desarrollarán. Cuando se aprueba la producción de un lanzamiento de prueba, el lanzamiento se fusiona en las pruebas.

Esto es todo bastante fácil de configurar, pero me pregunto acerca de las opciones de cumplimiento en git. Por ejemplo, ¿es posible aplicar una política en la que los únicos compromisos en la rama de la versión se combinen con las pruebas, evitando que los cambios sucedan directamente en la rama de la versión?

Answer 1

Bueno, más o menos. Pero no creo que quieras ir allí.

Como dice Jason, hay ganchos que puede usar para evitar ciertos comportamientos. En este caso, podríamos usar el enganche pre commit para evitar que alguien ejecute "git commit". Pero esto es problemático en varios aspectos:

1. Por diversas razones de seguridad, ganchos git no se distribuyen con el repositorio, por lo que no puede obligar a la gente a utilizar sus ganchos en sus repositorios. Recuerde, sus repositorios son suyos, no para que decida qué hacen en sus repositorios.
2. ¿Qué sucede cuando haces un pull o merge y obtienes conflictos? Para resolver estos conflictos debes poder usar "git commit", que ahora hemos desactivado.

Esto simplemente crea más problemas de los que resuelve.

Sin embargo, puede resolver esto de otras maneras. Puede crear un flujo de trabajo que haga cumplir estos principios. Por ejemplo, imagine que tiene a la persona A a cargo de fusionar la rama de prueba con la rama de publicación. Si permite que solo esta persona pueda enviar los cambios al repositorio central (o que el repositorio de personas ES el repositorio "central"), él/ella podría obtener cambios de la rama de prueba del repositorio de prueba, o la rama de prueba de probador B (usa tu imaginación).

Lo importante aquí es darse cuenta de que puede aplicar una política mediante el diseño de cómo comunica los cambios entre sí. No todos deben poder enviar sus cambios al un repositorio. Demonios, ni siquiera necesitan impulsar sus cambios en absoluto. La persona/persona de prueba podría obtener cambios de los desarrolladores, tan pronto como deseen algo probado, y de esta manera usted podría dejar que la prueba decida cuándo están listos para introducir nuevos cambios, no dejar que los desarrolladores decidan cuándo los evaluadores deben obtener su prueba. cosas. Mismo principio.

Answer 2

Debería poder aplicar esto utilizando algunos de los ganchos git.

Answer 3

Es posible que desee comprobar Git flow para obtener más ideas sobre este tipo de workflow.

Answer 4

Más recientemente, un marco hecho para la aplicación de la autorización, gitolite, puede ayudar a poner en marcha todo tipo de políticas, por ejemplo para permitir sólo el probador de fusionar en el "Testing" rama.

Además, gitolite propone con VREFs (explicado en "Gitolite Update Hook exclude a repository") la posibilidad de definir muchos "ganchos de actualización" que controlarán las confirmaciones que se envían al repositorio administrado por gitolite.

Pero todos esos controles son para un repositorio "central", no para todos los repos indirectos clonados en las estaciones de trabajo de los distintos desarrolladores.