Mantener un historial de git limpio cuando se usa gitflow: los compromisos no fusionados en el desarrollo

Usando gitflow, al crear una release-1.0.0rama y la fusión a la vez mastery develop, ambas ramas tendrán una confirmación que faltan:

masterno tendrá el commit donde release-1.0.0se fusionódevelop
developno tendrá el commit donde release-1.0.0se fusionómaster

En su lugar, después de hotfix-1.0.1crearse y fusionarse master, cuando se fusiona develop, los commits para fusionar incluirán el commit anterior donde release-1.0.0se fusionó master; así se verá así:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Si esto suena confuso, puede notar fácilmente que todo lo que ve developes generalmente un par de commits detrás master(aunque el desarrollo, en teoría, solo debería estar adelante ya que es la rama principal. Esos commits son fusiones de release-x.x.xa master).

¿Cómo se debe manejar esto para mantener un historial limpio?

git gitflow

— Christopher Francisco
fuente

Defina "historial limpio".

— Jace Browning el

¿Quieres una historia limpia? No uses gitflow. Por definición, contamina tu historia. En cambio, piense en lo que realmente necesita y cree un flujo de trabajo en torno a eso, de modo que realmente se ajuste a cómo desea trabajar.

— FP

La fusión para dominar será una "copia", no es necesario fusionarla para desarrollarla. Realice correcciones urgentes desde la rama de la versión anterior, no maestra, y fusione ambas desde allí, y no tendrá el problema. Master no agrega mucho al modelo, por lo que en realidad puedes dejarlo completamente, en mi opinión.

— axl

@axl Entiendo lo que quieres decir, pero estoy tratando de seguir gitflow lo más cerca posible de su documentación. Prefiero no hacer ningún tipo de "hackz" porque dado que muchos desarrolladores ya adoptaron gitflow, ya deberían tener una solución para esta cosa simple

— Christopher Francisco el

Hay varias discusiones sobre cómo resolver varios problemas con GitFlow en GitHub y otros lugares. A veces simplemente no hay una bala de plata.

— axl

Creo que un buen enfoque es evitar tener dos ramas "principales", master y desarrollo, que son redundantes. Aquí se explica a fondo , calificado cactus-flowpor el autor.

Algunos puntos se destacan en lugar de git-flow:

Solo una rama principal
Solo fusiones de avance rápido

Para mí, el último es importante, ya que después de usar git-flow durante mucho tiempo aún no he visto qué es útil sobre las --no-fffusiones.

Estoy tratando de seguir gitflow lo más cerca posible de su documentación. Prefiero no hacer ningún tipo de "hackz" porque dado que muchos desarrolladores ya han adoptado gitflow, ya deberían tener una solución para esta cosa simple

En mi humilde opinión, ese es tu gran error. No hay razón para que te quedes con git-flow tanto como sea posible. Puede usarse en miles de proyectos, pero eso no afecta el suyo, no lo hace bueno.

Git-flow es un buen punto de partida, pero debería pensar en adaptarlo a sus herramientas y flujo de trabajo en lugar de al revés.

— Sergio Basurco
fuente