¿Cuál es la diferencia entre `git merge` y` git merge --no-ff`?

Usando gitk log, no pude detectar una diferencia entre los dos. ¿Cómo puedo observar la diferencia (con un comando git o alguna herramienta)?

El --no-ffindicador evita la git mergeejecución de un "avance rápido" si detecta que su actual HEADes un antepasado de la confirmación que está intentando fusionar. Un avance rápido es cuando, en lugar de construir una confirmación de fusión, git simplemente mueve el puntero de la rama para apuntar a la confirmación entrante. Esto ocurre comúnmente cuando se realiza un git pullsin cambios locales.

Sin embargo, ocasionalmente desea evitar que ocurra este comportamiento, generalmente porque desea mantener una topología de rama específica (por ejemplo, se está fusionando en una rama de tema y quiere asegurarse de que se vea de esa manera cuando lea el historial). Con el fin de hacer eso, se puede pasar la --no-ffbandera y git mergelo harás siempre la construcción de una fusión en lugar de avance rápido.

Del mismo modo, si desea ejecutar git pullo usar git mergepara avanzar explícitamente y desea rescatar si no puede avanzar rápidamente, puede usar la --ff-onlybandera. De esta manera, puede hacer algo como git pull --ff-onlypensar sin pensar, y luego, si se produce un error, puede regresar y decidir si desea fusionar o cambiar la base.

Respuesta gráfica a esta pregunta.

Aquí hay un sitio con una explicación clara y una ilustración gráfica del uso git merge --no-ff:

Hasta que vi esto, estaba completamente perdido con git. El uso le --no-ffpermite a alguien que revisa el historial ver claramente la sucursal que desprotegió para trabajar. (ese enlace apunta a la herramienta de visualización de "red" de github) Y aquí hay otra gran referencia con ilustraciones. Esta referencia complementa muy bien la primera con un mayor enfoque en aquellos menos familiarizados con git.

Información básica para novatos como yo

Si eres como yo, y no un Git-guru, mi respuesta aquí describe cómo manejar la eliminación de archivos del seguimiento de git sin eliminarlos del sistema de archivos local, lo que parece estar mal documentado pero a menudo ocurre. Otra situación nueva es obtener el código actual , que aún logra eludirme.

Ejemplo de flujo de trabajo

Actualicé un paquete a mi sitio web y tuve que volver a mis notas para ver mi flujo de trabajo; Pensé que era útil agregar un ejemplo a esta respuesta.

Mi flujo de trabajo de comandos git:

git checkout -b contact-form
(do your work on "contact-form")
git status
git commit -am  "updated form in contact module"
git checkout master
git merge --no-ff contact-form
git branch -d contact-form
git push origin master

Abajo: uso real, incluyendo explicaciones.
Nota: la salida a continuación se corta; git es bastante detallado.

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   ecc/Desktop.php
#       modified:   ecc/Mobile.php
#       deleted:    ecc/ecc-config.php
#       modified:   ecc/readme.txt
#       modified:   ecc/test.php
#       deleted:    passthru-adapter.igs
#       deleted:    shop/mickey/index.php
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       ecc/upgrade.php
#       ecc/webgility-config.php
#       ecc/webgility-config.php.bak
#       ecc/webgility-magento.php

Observe 3 cosas de arriba:
1) En la salida puede ver los cambios de la actualización del paquete ECC, incluida la adición de nuevos archivos.
2) Observe también que hay dos archivos (no en la /ecccarpeta) que eliminé independientemente de este cambio. En lugar de confundir esas eliminaciones de archivos con ecc, haré una cleanuprama diferente más tarde para reflejar la eliminación de esos archivos.
3) ¡No seguí mi flujo de trabajo! Me olvidé de git mientras intentaba que ecc volviera a funcionar.

A continuación: en lugar de hacer el todo incluido git commit -am "updated ecc package"que normalmente haría, solo quería agregar los archivos en la /ecccarpeta. Esos archivos eliminados no eran específicamente parte de mi git add, pero debido a que ya estaban rastreados en git, necesito eliminarlos del commit de esta rama:

$ git checkout -b ecc
$ git add ecc/*
$ git reset HEAD passthru-adapter.igs
$ git reset HEAD shop/mickey/index.php
Unstaged changes after reset:
M       passthru-adapter.igs
M       shop/mickey/index.php

$ git commit -m "Webgility ecc desktop connector files; integrates with Quickbooks"

$ git checkout master
D       passthru-adapter.igs
D       shop/mickey/index.php
Switched to branch 'master'
$ git merge --no-ff ecc
$ git branch -d ecc
Deleted branch ecc (was 98269a2).
$ git push origin master
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 59.00 KiB, done.
Total 14 (delta 10), reused 0 (delta 0)
To [email protected]:me/mywebsite.git
   8a0d9ec..333eff5  master -> master

Script para automatizar lo anterior

Habiendo usado este proceso más de 10 veces en un día, me dediqué a escribir scripts por lotes para ejecutar los comandos, así que hice un git_update.sh <branch> <"commit message">script casi adecuado para realizar los pasos anteriores. Aquí está la fuente de Gist para ese guión.

En lugar de git commit -amseleccionar archivos de la lista "modificada" producida a través de git statusy luego pegarlos en este script. Esto sucedió porque hice docenas de ediciones pero quería varios nombres de sucursales para ayudar a agrupar los cambios.

Estrategias de fusión

Fusión explícita : crea una nueva confirmación de fusión. (Esto es lo que obtendrás si lo usaste --no-ff).

Fusión de avance rápido : avance rápidamente, sin crear una nueva confirmación:

Rebase : establezca un nuevo nivel base:

Squash: aplastar o exprimir (algo) con fuerza para que quede plano:

La --no-ffopción garantiza que no se produzca una combinación de avance rápido y que siempre se creará un nuevo objeto de confirmación . Esto puede ser deseable si desea que git mantenga un historial de ramas de características.              En la imagen de arriba, el lado izquierdo es un ejemplo del historial de git después de usar git merge --no-ffy el lado derecho es un ejemplo de uso git mergedonde era posible una fusión ff.

EDITAR : una versión anterior de esta imagen indicaba solo un padre principal para la confirmación de fusión. Las confirmaciones de fusión tienen varias confirmaciones primarias que git usa para mantener un historial de la "rama característica" y de la rama original. Los enlaces principales múltiples se resaltan en verde.

Esta es una vieja pregunta, y esto se menciona de manera algo sutil en las otras publicaciones, pero la explicación que hizo este clic para mí es que las fusiones no rápidas requerirán una confirmación por separado .

El indicador --no-ff 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