¿Cuándo deben crearse las ramas de desarrollo?

Estamos moviendo el equipo de nuestro proyecto de usar una sola rama Principal / Troncal, a múltiples ramas de Desarrollo / Trabajo que deberían fusionarse regularmente en Principal. Basamos nuestro nuevo proceso en este artículo y en la Guía de ramificación de TFS (estamos usando TFS y Visual Studio 2010).

Actualmente hay entre 1 y 5 personas trabajando en el proyecto en cualquier momento. Main debe ser estable en todo momento porque queremos que la opción se libere cuando lo necesitemos. No tenemos sprints fijos, al menos no todavía, y en este momento lanzamos cada 1-2 semanas.

Justo en este momento, cada persona está reparando errores en la aplicación. En un par de semanas comenzaremos a desarrollar un nuevo componente grande para la aplicación.

Un punto conflictivo que estamos encontrando es cuando se deben crear ramas de desarrollo . Implementaremos múltiples historias de usuarios en paralelo dependiendo del conjunto de habilidades del desarrollador. Hemos pensado en crear una rama para cada desarrollador, pero eso no tiene sentido porque siempre habrá alguna necesidad de colaboración en un trabajo. No podemos seguir adelante con una sola rama de desarrollo porque queremos fusionarnos con Main mientras se completa otro trabajo.

¿Alguien tiene alguna orientación sobre esto?

No me gustan las ramas arbitrarias, es decir, las correcciones de errores de Fred o las correcciones de errores de Harry. Me siento mucho más cómodo con una característica (independiente) de una rama que permite que múltiples desarrolladores operen en una característica; pero para que la función se fusione solo cuando esté completa.

Entonces, en este momento solo necesita la rama "corrección de errores", pero una vez que comience el desarrollo, debe crear una rama para cada característica importante. De esta forma, cuando terminen, se pueden fusionar y liberar sin depender de otras funciones más molestas.

No estoy seguro de lo bueno que es combinar TFS, pero estoy seguro de que lo sabrá en unos meses :)

No podemos seguir adelante con una sola rama de desarrollo porque queremos fusionarnos con Main mientras se completa otro trabajo.

Parece que ya sabes que se deben crear múltiples ramas de desarrollo. Me vienen a la mente dos escenarios probables:

1. Cada uno de los cinco desarrolladores están trabajando en partes independientes del proyecto (corrección de errores) - Asegúrese de que un ramal individual se crea para cada desarrollador. Esto coloca la responsabilidad y la responsabilidad en cada desarrollador para asegurarse de que su conjunto de cambios no entre en conflicto con el trabajo de otra persona. Es muy probable que uno de sus cinco desarrolladores se equivoque. Si ese es el caso, no tiene ningún sentido que todos los demás sean retenidos.
2. Desarrollos de funciones múltiples : independientemente del número de desarrolladores que trabajen en una función / error en particular, estos deben separarse. Un ejemplo de que esto es beneficioso es que todas las confirmaciones de código son parte de la (s) característica (s) que se está (n) desarrollando (no hay dudas).

Ramas de trabajo implícitas con DVCS

Usamos Mercurial para que haya una rama de trabajo implícita en el cuadro de desarrollo de desarrolladores. Los compromisos siempre se realizan en el espacio de trabajo local. Cuando se completa una pieza de trabajo liberable, se envía al servidor principal de repositorios donde se crea y prueba automáticamente.

Casi nunca creamos ramas explícitas, pero de nuevo nuestros sprints nunca duran más de 1 semana y las tarjetas no tardan más de 1-2 días en completarse.

Además, puede mitigar el dolor de fusión al enhebrar el trabajo de otras partes del código u otros proyectos para que las personas no tengan que hacer fusiones difíciles todo el tiempo.

He utilizado tanto una sola rama por historia como una rama por versión (todos los desarrolladores registran sus historias para el desarrollo y si alguno de ellos rompe la rama de desarrollo, se rompe para todos). Recomiendo encarecidamente una rama por historia si no le gustan los conflictos. La rama de desarrollo siempre permanecerá estable para todos los desarrolladores y no habrá tiempo de espera para que un desarrollador trabaje en un código que otro desarrollador ya haya roto. Cuando termine su historia, todo su código estará en su sucursal. Lo fusionará con el desarrollador pero no con el check-in y la prueba, en caso de que surjan conflictos, lo resolverá y le preguntará a la persona con la que está en conflicto para evitar eliminar su código. Luego fusionarse con dev. Esto ayuda a todos los desarrolladores a trabajar sin problemas. También depende del tamaño de la empresa. Nuestra empresa tiene 200 desarrolladores trabajando simultáneamente en una base de código, pero rama separada para sus historias. Una vez que el código se fusiona con la rama de desarrollo, la rama de la historia se elimina inmediatamente. Espero que esto ayude. Gracias

Si esto se basa en git, simplemente cree una rama para cada corrección de errores, corrija el error en el menor tiempo posible, combine la rama de corrección de errores con la rama de desarrollo, luego empuje el cambio a la rama de desarrollo. Revisar las solicitudes de extracción y la fusión debería ser la máxima prioridad, porque cuanto más rápido lo haga, mayores serán las posibilidades de que la fusión no cause problemas. Una vez fusionados, estas ramas se pueden eliminar.