Git avance rápido VS sin fusión de avance rápido
Git merge nos permite realizar fusiones de ramas con avance rápido y sin avance rápido. ¿Alguna idea de cuándo utilizar la combinación de avance rápido y cuándo no utilizar la combinación de avance rápido?
La --no-ffopción es útil cuando desea tener una noción clara de su rama de funciones. Entonces, incluso si mientras tanto no se realizaron confirmaciones, FF es posible; a veces aún desea que cada confirmación en la línea principal corresponda a una característica. Por lo tanto, trata una rama de características con un montón de confirmaciones como una sola unidad y las fusiona como una sola unidad. De su historial se desprende claramente cuándo presenta una fusión de ramas con --no-ff.
Si no le importan esas cosas, probablemente pueda salirse con la suya con FF siempre que sea posible. Por lo tanto, tendrá una sensación de flujo de trabajo más parecida a la de svn.
Por ejemplo, el autor de este artículo cree que esa --no-ffopción debería ser la predeterminada y su razonamiento se acerca al que describí anteriormente:
Considere la situación en la que una serie de confirmaciones menores en la rama "función" constituyen colectivamente una nueva característica: si simplemente hace "git merge feature_branch" sin --no-ff", es imposible ver en el historial de Git cuáles de los objetos de confirmación juntos tienen implementó una característica: tendría que 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-ffno se usa], mientras que se hace fácilmente si --no-ffse usó la bandera [porque es sólo un compromiso]".
Puedo dar un ejemplo que se ve comúnmente en el proyecto.
Aquí, la opción --no-ff(es decir, true merge ) crea una nueva confirmación con varios padres y proporciona un mejor seguimiento del historial. De lo contrario, --ff(es decir, combinación de avance rápido ) es la opción predeterminada.
$ 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 created at merge with proper message
commit 'finish the feature'
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 newFeaturerama se reutiliza, en lugar de crear una nueva rama, git tendrá que realizar una --no-fffusión de todos modos. Esto significa que la combinación de avance rápido no siempre es elegible.
