Estrategias de flujo de trabajo para mitigar conflictos de fusión de ramas de tema

Question

Estoy en la cúspide de vender git a mis superiores. Nos están escuchando hablar de eso, de todos modos. Hay una cosa de la que no estoy seguro, y me gustaría ver cómo las personas lidian con esto. Básicamente, mi pregunta proviene del entendimiento fundamental de que cuanto más lejos se permiten un par de ramas, más difícil es fusionarse.

Estoy considerando proponer este flujo de trabajo bastante simple: digamos que tengo una rama maestra (versión), una rama de desarrollo y ramas de tema de eso. Distintos desarrolladores están trabajando en sus ramas temáticas por separado, arrastrando y empujando esas ramas temáticas a un repositorio central tan a menudo como sienten que tienen código de trabajo. Periódicamente, cuando un desarrollador lo solicita, el mantenedor (en nuestra organización esa persona tiene el título "lead técnico") se fusiona desde su rama de características en la rama de desarrollo, que se pone en un servidor de prueba y se prueba, y una vez prueba completa, se fusionó con master y se lanzó a producción.

Aquí está mi pregunta. ¿Deben los desarrolladores fusionar sus ramas temáticas periódicamente? Si lo hace, se asegurará de que TODOS se fusionen nuevamente en dev bastante limpiamente (o al menos atrape los conflictos antes de que puedan salirse de control). Lo único que sé que a mi gerente le desagradará es que ese es el trabajo que tienen que hacer para aplacar su herramienta, en lugar de trabajar para entregar código al proyecto. ¿Pensamientos?

Answer 1

Todos sabemos que habrá conflictos. La pregunta es realmente: ¿quién debería resolver los conflictos?

Es beneficioso que la persona más cercana a los cambios que causó este conflicto sea la que lo está solucionando. Si deja que un mantenedor maneje esto (o algún otro desarrollador) esa persona puede no saber de qué se trata el código. Entonces sí, los desarrolladores probablemente deberían ser responsables de resolver los conflictos de fusión. Es un intercambio.

Su problema está relacionado con el flujo de trabajo y que a su jefe podría no gustarle que el líder técnico esté usando su tiempo para resolver conflictos. De lo contrario, este modelo no es malo en absoluto. Este rol que el líder técnico tiene a menudo se llama "integrador" y a menudo implica resolver conflictos y significa que el integrador necesita saber sobre el código y necesita comunicarse mucho con los desarrolladores (también hay otras herramientas en git que pueden simplificar este escenario)

Lo que podría hacer, es dejar que los desarrolladores no empujen y extraigan sus ramas de tema del servidor, sino que mantengan sus ramas de tema localmente y solo tengan, p. dominar y desarrollar en el servidor. Si, en su lugar, extraen de desarrollo, fusionan sus cosas, resuelven conflictos localmente y también prueban localmente antes de que se desarrollen. De esta forma, los desarrolladores pueden impulsar el desarrollo y el líder técnico puede enfocarse en probar y desarrollar otros tipos de pruebas, como pruebas de rendimiento, etc.

Sin embargo, si aún desea el rol de integrador, existe una herramienta llamada git rerere. Permite al integrador combinar periódicamente las ramas, resolver conflictos, restablecer para deshacer la fusión y git registrará automáticamente cómo se resolvió el conflicto. Esta es una muy buena manera de minimizar los conflictos de resolución de trabajo. Incluso puedes automatizar esto con un git hook, p. realice la fusión con un script y simplemente notifique al integrador si ha ocurrido un conflicto.

un poco de lectura:

http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/

Saludos