Las twigs de Github siempre van delante o detrás

Tenemos un repository con 2 sucursales. Uno llamado dev y el otro prd . Seguimos un process normal para enviar requestes de extracción de nuestros Forks para fusionar nuestros cambios con dev . Posteriormente, se realiza una request de extracción y fusión desde dev en prd para hacer estas actualizaciones en vivo.

El problema es que, en un momento dado, mientras se fusionaba de dev a prd , la twig de prd se prd permanentemente "por delante" de dev (a veces la stack de commits ahead). El efecto contrario ocurrirá si tratamos de fusionar prd nuevo en dev , excepto que estará detrás.

¿Cómo podemos sincronizar ambas twigs porque estos estados están causando confusión en el equipo?

Nota: está adelante sin cambios de files, solo se están registrando los commits.

Debido a la forma en que las fusiones funcionan en Git, este es un comportamiento normal.

En Git, una fusión es un compromiso como cualquier otro, solo tiene dos (o más) padres. Contiene los cambios necesarios para fusionar el contenido. Cuando fusionas una twig con otra, la twig fuente no cambia . Entonces, cuando dev se fusiona en prod, solo prod cambios.

Aquí hay un ejemplo visual. Digamos que dev se bifurcó prod en commit 3. prod está ahora en commit 7 y dev está en E. prod está verificado.

 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 [prod] [HEAD] \ A -- B -- C -- D -- E [dev] 

Cuando dev se fusiona en prod con el command git merge dev , este es el resultado.

 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [HEAD] \ / A -- B -- C -- D -- E [dev] 

La combinación da como resultado un nuevo compromiso cuyos padres son 7 y E. Contiene todos los cambios necesarios para unirlos. prod avanza a este nuevo compromiso. dev permanece en E.

Esta es la razón por la cual prod estará siempre por delante del dev después de la fusión. La exception es "reenvío rápido". Digamos que esto sucede.

 1 -- 2 -- 3 -- 4 [prod] [HEAD] \ A -- B -- C [dev] 

dev se separó de prod en 4. El trabajo se ha realizado en dev pero no en prod. prod está verificado. Cuando git merge dev finaliza, git reconocerá que no hay necesidad de una fusión y hará un "avance rápido".

 1 -- 2 -- 3 -- 4 \ A -- B -- C [dev] [prod] [HEAD] 

prod se avanza a C, el mismo lugar dev. Puede anular este comportamiento con git merge --no-ff para "no avanzar rápido". Esto se recomienda para las twigs de características, donde es importante retener el hecho de que un set de confirmaciones era parte de una característica cohesiva, pero innecesario si solo está haciendo que una twig de producción se ponga al día con el desarrollo.

El hecho de que sus fusiones no sean de reenvío rápido indica que los compromisos se realizaron directamente a prod , esos son compromisos 4 a 7 en nuestro ejemplo. En muchos flujos de trabajo esto no debería suceder, las confirmaciones solo deberían hacerse para dev y luego fusionarse en prod. Debería investigar eso, podría haber cambios en prod que no están en desarrollo. Alguien probablemente pinched prod caliente.

La forma más sencilla de solucionar esta situación es fusionar dev en prod y luego eliminar inmediatamente dev y ramificarlo nuevamente fuera de prod. No se preocupe, se conservará el historial de sucursal.

 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [dev] [HEAD] \ / A -- B -- C -- D -- E 

git branch -d dev le impedirá eliminar una twig que no se ha fusionado por completo. Por ejemplo, si el repository se viera así …

 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 [prod] [HEAD] \ / A -- B -- C -- D -- E -- F -- G [dev] 

Y ejecutó git branch -d dev , git se rehusaría a eliminar la twig. NO use -D o -f para forzarlo, de lo contrario perderá trabajo del desarrollador. Simplemente combine dev en prod y luego intente de nuevo.

Hay otras maneras de manejar esta situación, pero eso es lo más simple. Después de eso, tus commits deberían avanzar rápidamente.