Estrategias de flujo de trabajo para mitigar conflictos de fusión de twigs temáticas

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 twigs, más difícil es fusionarse.

Estoy considerando proponer este flujo de trabajo bastante simple: digamos que tengo una twig maestra (versión), una twig de desarrollo y twigs de tema de eso. Distintos desarrolladores están trabajando en sus twigs temáticas por separado, arrastrando y empujando esas twigs temáticas a un repository 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 de su twig de características en la twig de desarrollo, que se pone en un server de testing y se testing, y una vez que la característica testing completa, se fusionó con master y se lanzó a producción.

Aquí está mi pregunta ¿Deben los desarrolladores fusionar sus twigs temáticas periódicamente? Si lo hace, se asegurará de que TODOS se fusionen nuevamente en dev bastante limpiamente (o al less 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?

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

Es beneficioso si la persona más cercana a los cambios que hicieron que ocurriera este conflicto es quien lo está solucionando. Si dejas que un mantenedor maneje esto (o algún otro desarrollador) esa persona podría 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 es posible que a su jefe no le guste que el líder técnico esté usando su time para resolver conflictos. De lo contrario, este model 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 twigs de tema del server, sino que mantengan sus twigs de tema localmente y solo tengan, por ejemplo, maestría y desarrollo en el server. Si en su lugar extraen del desarrollo, fusionan sus cosas, resuelven conflictos localmente y también realizan testings locales antes de que se desarrollen. De esta forma, los desarrolladores pueden impulsar el desarrollo y el líder técnico puede centrarse en el desarrollo de testings y otros types de testings, como las testings de performance, etc.

Sin embargo, si todavía desea el rol de integrador, existe una herramienta llamada git rerere . Permite al integrador combinar periódicamente las twigs, 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 podría automatizar esto con un git hook, por ejemplo, hacer la fusión con un script y simplemente notificar al integrador si ha ocurrido un conflicto.

Algunos leyendo:

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/

Aclamaciones