tag - Cuándo usar la opción de fusión ''- no-ff'' en Git

qué tipos de etiquetas existen en git (3)

Un modelo exitoso de ramificación de Git recomienda usar --no-ff cuando se fusionan ramas:

El --no-ff hace que la fusión siempre cree un nuevo objeto de confirmación, incluso si la combinació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. [...]
Sí, creará algunos objetos de compromiso más (vacíos), pero la ganancia es mucho mayor que ese costo. Desafortunadamente, no he encontrado una forma de hacer --no-ff el comportamiento predeterminado de Git Merge todavía, pero realmente debería ser así.

Comprender el flujo de trabajo de Git , sin embargo, recomienda no usar --no-ff :

Así que agrega una regla nueva: "Cuando se fusiona en su rama de características, use –-no-ff para forzar una nueva confirmación". Esto hace el trabajo y usted sigue adelante. [...]
Los misterios de la tirita --no-ff , la bisect rota y la blame son todos síntomas de que estás usando un destornillador como martillo. [...]

Ambos enfoques parecen razonables para escenarios de diferencia, pero ¿qué se considera "buena práctica"?

¿Cuándo usas --no-ff , cuando no, por qué?

Depende realmente de lo que estás tratando de hacer. Mi regla de oro es que si la fusión "significa algo" uso la opción --no-ff. Cuando la fusión realmente no significa nada y es posible que haya utilizado una rebase no hay ninguna razón para usar --no-ff

Lo que pasa con git es que es una herramienta muy poderosa, y puedes usarla de muchas maneras, la mayoría de las cuales no están mal. Preguntar cuál es la "manera correcta" de hacerlo es como preguntar cuál es la forma correcta de pintar una imagen.

Al menos para mí es una serie de formas en constante evolución, me gusta hacerlo, con frecuentes discusiones en el equipo acerca de cómo queremos colaborar en el código. De esto tratamos de derivar una especie de estándar de "cómo se hace aquí", pero es solo nuestra forma de hacerlo.

Eso realmente depende de su flujo de trabajo y de cómo está utilizando las sucursales.

Digamos que tiene un "maestro" y dos ramas de características, "foo" y "barra", en desarrollo.

En este caso, las ramas solo existen para permitir que diferentes desarrolladores trabajen sin conflictos, cuando se realizan las funciones, se deben fusionar en maestras, y no es importante saber si esas características se implementaron en diferentes ramas.

Pero podría tener un flujo de trabajo diferente, donde las ramas, "foo" y "bar", se refieren a módulos independientes en su sistema.

En este caso, algunas confirmaciones pueden cambiar los archivos fuera del alcance del módulo. Cuando combina esas dos ramas con el maestro, el registro de los archivos, fuera del módulo específico, puede volverse confuso y difícil saber de dónde provienen esos cambios.

Debe decidir si la fusión histórica de la sucursal es importante para su flujo de trabajo.

Y después de los comentarios, prefiero la rebase y pull --rebase workflow.

Para el caso de una bifurcación terminada con una sola confirmación, no use --no-ff , solo avance rápido, porque la historia será mucho más simple y menos abarrotada. Es difícil argumentar que --no-ff te ofrece ventajas en este caso, porque no interesa ver una rama paralela de desarrollo con una sola confirmación, frente a una única confirmación en una línea secuencial:

# No fast-forward $ git merge --no-ff awesome-feature * 3aa649c Merge branch ''awesome-feature'' |/ | * 35ec88f Add awesome feature |/ * 89408de Modify feature-001.txt and fix-001.txt * c1abcde Add feature-003 # versus fast-forward $ git merge awesome-feature * 35ec88f Add awesome feature * 89408de Modify feature-001.txt and fix-001.txt * c1abcde Add feature-003

Para el caso de una sucursal terminada con más de una confirmación única, depende de usted, independientemente de si desea mantener el hecho de que el desarrollo ramificado ocurrió en paralelo vs secuencial. Probablemente usaría --no-ff para más de una confirmación, solo para poder ver visualmente este trabajo ramificado, y para poder manipularlo fácilmente con un solo git revert -m 1 <sha-of-merge-commit> si tuviera que hacerlo

# No fast-forward $ git merge --no-ff epic-feature * d676897 Merge branch ''epic-feature'' |/ | * ba40d93 Add octocat.txt | * b09d343 Add bye.txt | * 75e18c8 Add hello.txt |/ * 89408de Modify feature-001.txt and fix-001.txt * c1abcde Add feature-003 # versus fast-forward $ git merge epic-feature * ba40d93 Add octocat.txt * b09d343 Add bye.txt * 75e18c8 Add hello.txt * 89408de Modify feature-001.txt and fix-001.txt * c1abcde Add feature-003

Vea cómo en este caso de fusión de avance rápido, sin información adicional en los mensajes de confirmación, es difícil decir que los últimos 3 commits realmente pertenecen juntos como una característica.