Git fast forward VS no fast forward merge

La fusion Git nous permet d'effectuer une avance rapide et aucune fusion rapide des branches. Avez-vous des idées quand utiliser la fusion rapide et quand ne pas utiliser la fusion rapide?

L' --no-ffoption est utile lorsque vous souhaitez avoir une idée claire de votre branche de fonctionnalité. Donc, même si entre-temps aucune validation n'a été effectuée, FF est possible - vous voulez toujours que chaque validation dans la ligne principale corresponde à une fonctionnalité. Ainsi, vous traitez une branche de fonctionnalité avec un groupe de validations comme une seule unité et les fusionnez comme une seule unité. Il ressort clairement de votre historique lorsque vous fusionnez une branche avec --no-ff.

Si vous ne vous souciez pas d'une telle chose - vous pourriez probablement vous en tirer avec FF chaque fois que cela est possible. Ainsi, vous aurez une sensation de flux de travail plus semblable à celle d'un svn.

Par exemple, l'auteur de cet article pense que l' --no-ffoption devrait être par défaut et son raisonnement est proche de celui que j'ai exposé ci-dessus:

Considérez la situation où une série de validations mineures sur la branche "feature" constituent collectivement une nouvelle fonctionnalité: si vous faites simplement "git merge feature_branch" sans --no-ff, "il est impossible de voir dans l'historique Git quels objets de commit ensemble ont implémenté une fonctionnalité - vous devez lire manuellement tous les messages du journal. La restauration d'une fonctionnalité entière (c'est-à-dire un groupe de validations) est un véritable casse-tête [si elle --no-ffn'est pas utilisée], alors qu'elle est facile à faire si l' --no-ffindicateur a été utilisé [car c'est juste un commit]. "

Je peux donner un exemple couramment vu dans le projet.

Ici, l'option --no-ff(c'est-à-dire la vraie fusion ) crée un nouveau commit avec plusieurs parents et fournit un meilleur suivi de l'historique. Sinon, --ff(c'est -à- dire fusion rapide ) est par défaut.

$ 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

(*) Notez qu'ici, si la newFeaturebranche est réutilisée, au lieu de créer une nouvelle branche, git devra --no-ffquand même faire une fusion. Cela signifie que la fusion rapide n'est pas toujours éligible.

Lorsque nous travaillons sur un environnement de développement et que nous fusionnons notre code avec la branche production / production, alors Git no fast forward peut être une meilleure option. Habituellement, lorsque nous travaillons dans la branche de développement pour une seule fonctionnalité, nous avons tendance à avoir plusieurs validations. Le suivi des modifications avec plusieurs validations peut s'avérer peu pratique ultérieurement. Si nous fusionnons avec la branche staging / production en utilisant Git no fast forward, il n'y aura qu'un seul commit. Maintenant, chaque fois que nous voulons revenir sur la fonctionnalité, il suffit de revenir sur ce commit. La vie est facile.

Il est également possible que l'on veuille avoir des branches de fonctionnalités personnalisées où le code est simplement placé en fin de journée. Cela permet de suivre le développement plus en détail.

Je ne voudrais pas polluer le développement maître avec du code qui ne fonctionne pas, faisant ainsi --no-ff peut être juste ce que l'on cherche.

Par ailleurs, il peut ne pas être nécessaire de valider le code de travail sur une branche personnalisée, car l'historique peut être réécrit git rebase -iet forcé sur le serveur tant que personne d'autre ne travaille sur cette même branche.