rama - ¿Cuál es la diferencia entre `git merge` y` git merge--no-ff`?
git merge--no-ff example (5)
Usando el gitk log , no pude ver una diferencia entre los dos. ¿Cómo puedo observar la diferencia (con un comando git o alguna herramienta)?
Respuesta gráfica a esta pregunta.
Aquí hay un sitio con una explicación clara y una ilustración gráfica del uso de git merge --no-ff :
Hasta que vi esto, estaba completamente perdido con git. El uso de --no-ff permite que alguien que revise el historial vea claramente la rama en la que se registró 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 a la primera con un enfoque más en aquellos que están menos familiarizados con git.
Información básica para newbs como yo
Si eres como yo y no eres 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 poco documentado pero a menudo ocurre. Otra nueva situación es obtener el código actual , que todavía 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; Me pareció ú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 de abajo está cortada; git es bastante verboso.
$ 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
Note 3 cosas desde arriba:
1) En la salida puede ver los cambios de la actualización del paquete ECC, incluida la adición de nuevos archivos.
2) También note que hay dos archivos (no en la carpeta /ecc ) que eliminé independientemente de este cambio. En lugar de confundir esas eliminaciones de archivos con ecc , haré una rama de cleanup diferente más adelante 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 git commit -am "updated ecc package" completo de git commit -am "updated ecc package" normalmente lo haría, solo quería agregar los archivos en la carpeta /ecc . Esos archivos eliminados no fueron específicamente parte de mi git add , pero debido a que ya fueron rastreados en git, necesito eliminarlos de la confirmación 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.
Después de haber usado este proceso más de 10 veces en un día, he git_update.sh <branch> <"commit message"> a escribir scripts por lotes para ejecutar los comandos, por lo que hice un git_update.sh <branch> <"commit message"> casi apropiado para realizar los pasos anteriores. Aquí está la fuente de Gist para ese script.
En lugar de git commit -am , estoy seleccionando archivos de la lista "modificada" producida a través git status y luego pegándolos en este script. Esto sucedió porque hice docenas de ediciones pero quería varios nombres de sucursales para ayudar a agrupar los cambios.
El indicador --no-ff evita que git merge ejecute un "avance rápido" si detecta que su HEAD actual es un antecesor 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 su rama para que apunte a la confirmación entrante. Esto ocurre comúnmente cuando se hace un git pull sin ningún cambio local.
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). Para hacer eso, puedes pasar la bandera --no-ff y git merge siempre construirá una combinación en lugar de un avance rápido.
De manera similar, si desea ejecutar un git pull o usar git merge para avanzar explícitamente y desea rescatar si no puede avanzar, puede usar la --ff-only . De esta manera, puede hacer algo como git pull --ff-only sin pensarlo, y luego, si se git pull --ff-only error, puede regresar y decidir si desea fusionar o reajustar.
Esta es una pregunta antigua, y esto se menciona de forma algo sutil en las otras publicaciones, pero la explicación que hizo este clic para mí es que las fusiones que no avanzan en el futuro requerirán un compromiso por separado .
La --no-ff garantiza que no se producirá una combinación de avance rápido y que siempre se creará un nuevo objeto de confirmación . Esto puede ser deseable si quieres que git mantenga un historial de ramas de características. En la imagen anterior, el lado izquierdo es un ejemplo del historial de git después de usar git merge --no-ff y el lado derecho es un ejemplo del uso de git merge donde fue posible una ff merge.
EDITAR : una versión anterior de esta imagen indicaba solo un solo padre para la confirmación de fusión. Las confirmaciones de combinación tienen múltiples confirmaciones principales que git utiliza para mantener un historial de la "rama de características" y de la rama original. Los múltiples enlaces principales están resaltados en verde.
- Fusión explícita, no de avance rápido
- Implícito a través de rebase o combinación de avance rápido
- Calabaza en fusión
