Flujo de trabajo de Git para múltiples equipos.

Vamos a comenzar a usar Git (todavía no lo uso), y quiero definir el flujo de trabajo.

Tenemos 4 equipos en 4 ubicaciones globales diferentes, desarrollando juntos el mismo producto. Cada equipo posee una parte del código del producto, pero a veces también tienen que hacer cambios en el código propiedad de otros equipos.

¿Hay alguna recomendación para un flujo de trabajo de Git para dicho entorno?

Ya he visto este artículo , pero el enfoque aquí es "creamos sucursales adicionales tan raramente como sea posible", y creo más en el enfoque de "sucursal para cada historia de usuario".

Además, este artículo presenta un buen enfoque.

Tenía en mente tener una rama maestra, una rama permanente por cada equipo que se fusionaba periódicamente con el maestro, y una rama por historia de usuario fusionándose con las ramas de los equipos. ¿Tiene sentido o no funcionaría?

git version-control

— Igor Oks
fuente

Usamos este modelo de ramificación , pero creo que si lees "rama característica" como "rama de historia", encaja muy bien con tu segundo artículo.

Estoy seguro de que 10 personas podrían responder a esto con 10 respuestas diferentes. Esto es lo que funciona para mí: tenemos un repositorio principal alojado en github que denota el lanzamiento 'actual'. Las versiones anteriores están ramificadas (aunque el etiquetado también funciona). Se alienta a los miembros del equipo a crear sucursales para las tareas en las que están trabajando. Cuando se completa, hacen una solicitud de extracción para masterizar (o donde sea que necesite fusionarse) y luego alguien más revisa la solicitud de extracción y es responsable de fusionarla en master. También son responsables de limpiar la sucursal una vez que se ha fusionado.

Puede que le interesen los submódulos para mantener separadas las bases de código de los diferentes equipos. Luego pueden bifurcar las bases de código de los demás y enviar parches al editar las partes del código de los demás.

— Fred Foo

@larsmans & carbonbasednerd: sus comentarios deberían haber sido respuestas, habrían recibido votos de mi parte. * 8 ')

— Mark Booth

Respuestas:

Eche un vistazo al modelo de ramificación Git exitoso , que tiene una buena estrategia de ramificación para el desarrollo de características en todas las versiones.

Un exitoso modelo de ramificación git

Podría implementar algo similar con un nivel adicional para las ramas de equipo entre la rama 'desarrollar' y las 'ramas de características'. Tener sucursales de equipo también permitiría que dos equipos colaboren de manera más efectiva mediante la fusión entre sus sucursales de equipo.

— Nick Haddad
fuente

Diría que cada equipo tiene su propia versión del repositorio, con un repositorio global al que todos se comprometen (como en el kernel de Linux, donde el repositorio de Linus ES el kernel y el repositorio central).

Luego, para mantener el código del producto, puede usar submódulos como dijo @larsmans, luego cada equipo solo puede trabajar principalmente en la parte que es más importante para ellos y si necesitan trabajar con otra parte, pueden hacerlo, pero tendrá que recordar actualizar el submódulo, y aquí es donde radica el problema (dado que es muy fácil equivocarse al usar git, afortunadamente también es fácil alejarse de ellos).

Pero dado que sus equipos están acostumbrados a esto y son conscientes de que están cambiando el código de otro equipo, es más fácil para ellos recordar hacer la actualización del submódulo, antes de cambiar un módulo externo.

— Coyote21
fuente