Git avance rápido VS sin fusión de avance rápido

Question

Git merge nos permite realizar un avance rápido y no una fusión de avance rápido. ¿Alguna idea de cuándo usar la fusión de avance rápido y cuándo no usar la fusión de avance rápido?

Answer 1

La opción --no-ff es útil cuando desea tener una noción clara de su rama de características. Por lo tanto, aunque mientras tanto no se hayan realizado confirmaciones, es posible FF; aún desea que a veces cada confirmación en la línea principal corresponda a una característica. Así que trata una rama de características con un grupo de confirmaciones como una sola unidad, y las combina como una sola unidad. Está claro de su historial cuando aparece la fusión de sucursales con --no-ff.

Si no te importa eso, probablemente puedas salir con FF siempre que sea posible. Por lo tanto, tendrá más sensación de flujo de trabajo similar a svn.

Por ejemplo, el autor de este article piensa que --no-ff opción debe ser defecto y su razonamiento es similar a la que he descrito:

Consideremos la situación en la que una serie de confirmaciones de menor importancia en la rama "característica" colectivamente crear una nueva función: si acaba de hacer "git merge feature_branch" sin --no-ff, "es imposible ver en el historial de Git qué objetos de confirmación juntos han implementado una característica: debería leer manualmente todos los mensajes de registro. Revertir una característica completa (es decir, un grupo de confirmaciones) es un verdadero dolor de cabeza [si --no-ff no se usa], mientras que se hace fácilmente si se usó la bandera --no-ff [porque es j ust one commit]. "

Answer 2

Es posible también que uno puede desear tener ramas de características personalizadas donde el código se acaba de colocar al final del día. Eso permite seguir el desarrollo con más detalles.

No quisiera contaminar el desarrollo maestro con código que no funciona, haciendo así --no-ff puede ser lo que se está buscando.

Como nota al margen, puede que no sea necesario asignar código de trabajo en una bifurcación personalizada, ya que el historial se puede volver a escribir git rebase -i y forzar en el servidor siempre que nadie más esté trabajando en esa misma bifurcación.

Answer 3

Puedo dar un ejemplo visto comúnmente en el proyecto.

Aquí, --no-ff (es decir, true merge) crea una nueva confirmación con múltiples padres y proporciona un mejor seguimiento del historial. De lo contrario, --ff (es decir, fast-forward merge) es por defecto.

$ git checkout master 
$ git checkout -b newFeature 
$ ... 
$ git commit -m 'work from day 1' 
$ ... 
$ git commit -m 'work from day 2' 
$ ... 
$ git commit -m 'finish the feature' 
$ git checkout master 
$ git merge --no-ff newFeature -m 'add new feature' 
$ git log 
// something like below 
commit 'add new feature' 
commit 'finish the feature'  // => commit created at merge with proper message 
commit 'work from day 2' 
commit 'work from day 1' 
$ gitk       // => see details with graph 

$ git checkout -b anotherFeature  // => create a new branch (*) 
$ ... 
$ git commit -m 'work from day 3' 
$ ... 
$ git commit -m 'work from day 4' 
$ ... 
$ git commit -m 'finish another feature' 
$ git checkout master 
$ git merge anotherFeature  // --ff is by default, message will be ignored 
$ git log 
// something like below 
commit 'work from day 4' 
commit 'work from day 3' 
commit 'add new feature' 
commit 'finish the feature' 
commit ... 
$ gitk       // => see details with graph 

(*) Tenga en cuenta que aquí si la rama newFeature se reutiliza, en lugar de crear una nueva rama, GIT tendrá que realizar una combinación --no-ff de todos modos. Esto significa que la fusión rápida no es elegible.