Cómo mantener las ramas de git de larga ejecución

Question

Las ramas de Git idealmente deberían durar poco tiempo, probablemente durante 1-2 días. Luego se fusiona en alguna línea principal.

Pero en algunos casos, cuando trabajamos en funciones muy grandes, tenemos sucursales. Y cuando 2 o 3 personas trabajan en estas funciones muy grandes en áreas exclusivas de código, se vuelve difícil mantenerlas.

En medio de las correcciones urgentes que van a la rama estable, necesitamos mantener estas 2-3 ramas grandes sincronizadas con la rama estable. Así que terminamos haciendo esto, bastante a menudo.

(in feature-branch1) $ git merge stable 
(in feature-branch2) $ git merge stable 
(in feature-branch3) $ git merge stable 

¿Hay una manera correcta de mantener estas ramas largas en git? Al hacer lo anterior, la historia de Git es un poco desordenada. Estas ramas de características en su mayoría son empujadas a un control remoto, lo que significa que no podemos ver rebase como una opción. ¿Que más puedo hacer?

Answer 1

La fusión en la rama estable de vez en cuando es lo más fácil y lo mejor que puede hacer para mantener su rama de características actualizada. No recomendaría el reajuste porque podría haber más personas trabajando en la función al mismo tiempo y tendrían que restablecer mucho sus sucursales locales cada vez que hubiera un impulso forzado. Incluso si solo una persona trabaja en la rama de características, la fusión es mejor porque muestra claramente el punto en la historia donde trajo correcciones de la rama estable.

Sí, su historia puede parecer desordenada una vez que fusiona la rama de características en estable. Pero siempre que evite el desorden de las micro-fusiones diarias de su git pulls (use git pull --rebase), podrá apreciar fusiones significativas reales.

Si realmente desea evitar la fusión de nuevas características desde estable a la rama de características, pero solo quiere correcciones de errores, puede seleccionar cuidadosamente las correcciones de errores en la rama de características. Sin embargo, esto puede requerir mucho trabajo porque requiere que siempre estés al tanto de todo lo que sucede en forma estable. Utilice git cherry para ayudarle a salir:

# commits from "stable" that are not present in 
# the current branch will be prefixed with "+" 
git cherry HEAD stable 

Answer 2

La rebase es posible si el equipo es lo suficientemente pequeño y está formado por usuarios de git razonablemente experimentados.

Lo que puede hacer es, por ejemplo, acordar que la rama de funciones se volverá a establecer en estable cada noche. O podría enviar un correo electrónico cuando vuelva a establecer la base de la rama de características en estable.

Todo debe estar bien, pero en caso de que olvide la sincronización con la rama de la característica porcentualizada, digamos que cometió C en la parte superior de la antigua rama de la característica oldFB, que ha sido rebasada en oldFB':

S1 - oldFB - C <-- feature-branch 
    \ 
    S2 - oldFB' - D <-- origin/feature-branch 

todavía es posible reajustar su commit (s) C ejecutando:

git checkout feature-branch 
git rebase --onto origin/feature-branch oldFB C 

tenga en cuenta que tendrá que encontrar manualmente la confirmación llamado oldFB en el diagrama de arriba.

Answer 3

La mejor opción es combinar sólo las pequeñas ramas de corrección de errores de función/requeridos en sus ramas de características de larga vida. De esta manera solo obtienes lo que necesitas. Tenga en cuenta que si permite que estas ramas vivan el tiempo suficiente, en última instancia, podrían estar bastante fuera de sincronía con el maestro.De vez en cuando, es posible que desee crear una bifurcación temporal de su bifurcación de funciones de larga duración y fusionar el master en ella solo para realizar comprobaciones de cordura: vea si hay conflictos, vea si los cambios en el maestro interrumpen la función y así sucesivamente. en.

Lo mejor sería fusionar periódicamente master en sus ramas de características de larga duración. Esto es bastante seguro, pero también puede combinar muchos cambios que no le interesan y complicar las cosas.

Deseo no recomiendo volver a establecer las bases periódicamente en el maestro. Hace que sea difícil para todos mantenerse sincronizados, y también hace que sea mucho más difícil mantener un historial complejo (fusiones) en sus ramas de características y hace que la resolución de conflictos sea más dolorosa.