¿Por qué git realiza fusiones de avance rápido por defecto?

Viniendo de mercurial, uso ramas para organizar características. Naturalmente, también quiero ver este flujo de trabajo en mi historia.

Comencé mi nuevo proyecto usando git y terminé mi primera función. Al fusionar la función, me di cuenta de que git usa el avance rápido, es decir, aplica mis cambios directamente a la rama maestra si es posible y se olvida de mi rama.

Entonces, para pensar en el futuro: soy el único que trabaja en este proyecto. Si uso el enfoque predeterminado de git (fusión de avance rápido), mi historial daría como resultado una rama maestra gigante. Nadie sabe que usé una rama separada para cada característica, porque al final solo tendré esa rama maestra gigante. ¿No te parecerá poco profesional?

Según este razonamiento, no quiero la fusión de avance rápido y no puedo ver por qué es el valor predeterminado. ¿Qué tiene de bueno?

La fusión de avance rápido tiene sentido para las ramas de corta duración, pero en una historia más compleja , la fusión sin avance rápido puede hacer que la historia sea más fácil de entender y facilitar la reversión de un grupo de confirmaciones.

Advertencia : el reenvío no rápido también tiene posibles efectos secundarios. Revise https://sandofsky.com/blog/git-workflow.html , evite el 'no-ff' con sus "confirmaciones de puntos de control" que rompen la bisección o la culpa, y considere cuidadosamente si debería ser su enfoque predeterminado master.

^{(De nvie.com , Vincent Driessen , publique " Un modelo de ramificación Git exitoso ")}

Incorporando una característica terminada en desarrollo

Las funciones terminadas se pueden combinar en la rama de desarrollo para agregarlas a la próxima versión:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

El --no-ffindicador hace que la fusión siempre cree un nuevo objeto de confirmación, incluso si la fusión se puede realizar con un avance rápido. Esto evita perder información sobre la existencia histórica de una rama de características y agrupa todas las confirmaciones que juntas agregaron la característica.

Jakub Narębski también menciona la configuraciónmerge.ff :

De forma predeterminada, Git no crea una confirmación de fusión adicional al fusionar una confirmación que es descendiente de la confirmación actual. En cambio, la punta de la rama actual se reenvía rápidamente.
Cuando se establece en false, esta variable le dice a Git que cree una confirmación de fusión adicional en tal caso (equivalente a dar el--no-ff opción desde la línea de comando).
Cuando se establece en ' only', solo se permiten esas fusiones de avance rápido (equivalente a dar la --ff-onlyopción desde la línea de comando).

El avance rápido es el predeterminado porque:

• Las ramas de corta duración son muy fáciles de crear y usar en Git
• Las ramas de corta duración a menudo aíslan muchas confirmaciones que pueden reorganizarse libremente dentro de esa rama
• esos commits son en realidad parte de la rama principal: una vez reorganizados, la rama principal se reenvía rápidamente para incluirlos.

Pero si anticipa un flujo de trabajo iterativo en un tema / rama de características (es decir, me fusiono, luego vuelvo a esta rama de características y agrego más confirmaciones), entonces es útil incluir solo la fusión en la rama principal, en lugar de todos los commits intermedios de la rama de características.

En este caso, puede terminar configurando este tipo de archivo de configuración :

[branch "master"]
# This is the list of cmdline options that should be added to git-merge 
# when I merge commits into the master branch.

# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.

# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.

mergeoptions = --no-commit --no-ff

El OP agrega en los comentarios:

Veo algo de sentido en el avance rápido para ramas [de corta duración], pero convertirlo en la acción predeterminada significa que git asume que ... a menudo tiene ramas [de corta duración]. ¿Razonable?

Jefromi responde:

Creo que la vida útil de las sucursales varía mucho de un usuario a otro. Sin embargo, entre los usuarios experimentados, probablemente haya una tendencia a tener muchas más ramas de corta duración.

Para mí, una rama de corta duración es la que creo para facilitar una determinada operación (rebase, probable, o parches y pruebas rápidas), y luego eliminar inmediatamente una vez que haya terminado.
Eso significa que probablemente debería ser absorbido por la rama del tema de la que se bifurcó , y la rama del tema se fusionará como una rama. Nadie necesita saber qué hice internamente para crear la serie de confirmaciones que implementan esa característica dada.

Más en general, agrego:

realmente depende de su flujo de trabajo de desarrollo :

• Si es lineal, una rama tiene sentido.
• Si necesita aislar características y trabajar en ellas durante un largo período de tiempo y fusionarlas repetidamente, varias ramas tienen sentido.

Consulte "¿ Cuándo debe ramificarse? "

En realidad, cuando considera el modelo de rama Mercurial, está en su núcleo una rama por repositorio (aunque puede crear cabezas anónimas, marcadores e incluso ramas con nombre )
Consulte "Git y Mercurial - Comparar y contrastar" .

Mercurial, por defecto, utiliza líneas de código anónimas y ligeras, que en su terminología se llaman "cabezas".
Git usa ramas con nombre livianas, con mapeo inyectivo para mapear nombres de ramas en repositorio remoto a nombres de ramas de seguimiento remoto.
Git "lo obliga" a nombrar ramas (bueno, con la excepción de una sola rama sin nombre, que es una situación llamada " CABEZA separada "), pero creo que esto funciona mejor con flujos de trabajo con muchas ramas, como el flujo de trabajo de rama temática, lo que significa múltiples ramas en un solo paradigma de repositorio.

Permítanme ampliar un poco en un VonC 's respuesta muy amplia :

Primero, si lo recuerdo correctamente, el hecho de que Git por defecto no crea confirmaciones de fusión en el caso de avance rápido proviene de considerar los "repositorios iguales" de una sola rama, donde se usa la atracción mutua para sincronizar esos dos repositorios (un puede encontrar el primer flujo de trabajo como primer ejemplo en la documentación de la mayoría de los usuarios, incluido "El manual del usuario de Git" y "Control de versiones con ejemplos"). En este caso, no usa pull para fusionar una rama completamente realizada, la usa para mantenerse al día con otros trabajos. No desea tener hechos efímeros y sin importancia cuando realiza una sincronización guardada y almacenada en el repositorio, guardada para el futuro.

Tenga en cuenta que la utilidad de las ramas de características y de tener múltiples ramas en un solo repositorio se produjo solo más tarde, con un uso más extendido de VCS con un buen soporte de fusión, y al probar varios flujos de trabajo basados ​​en la fusión. Es por eso que, por ejemplo, Mercurial originalmente admitía solo una rama por repositorio (más sugerencias anónimas para rastrear ramas remotas), como se vio en revisiones anteriores de "Mercurial: la guía definitiva".

En segundo lugar, cuando se siguen las mejores prácticas de la utilización de ramas de características , a saber, que las ramas de características deben todo inicio de la versión estable (por lo general de la última versión), para ser capaz de cereza recoger y seleccionar las funciones que desea incluir seleccionando las ramas de características en combinación, se Por lo general, no están en una situación de avance rápido ... lo que hace que este problema sea discutible. Debe preocuparse por crear una verdadera fusión y no avanzar rápidamente al fusionar una primera rama (suponiendo que no coloque cambios de confirmación única directamente en 'maestro'); todas las otras fusiones posteriores son, por supuesto, en una situación que no avanza rápidamente.

HTH