Leçons dans Git: fusionner / rebaser

Le système de contrôle de version distribué appelé Git a changé la façon dont les développeurs envisagent la fusion et la ramification de code, par rapport aux systèmes de contrôle de version précédents comme CVS et SVN.


Avec Git, ces opérations sont devenues relativement faciles et rapides à faire. Ce système permet aux développeurs de créer de nouvelles fonctionnalités isolées de la branche principale et de les intégrer ultérieurement lorsque la fonctionnalité est prête pour l’intégration.

Si vous débutez avec Git, les liens suivants devraient vous aider à démarrer rapidement:

  • Git – Le guide simple
  • Git Basics
  • Git Branching Basics
  • Un modèle de branchement Git réussi

Dans Git, il existe deux façons principales d’intégrer les modifications d’une branche dans une autre:

  1. fusionner
  2. rebaser

Nous verrons la fusion avec l’option -ff et l’option -no-ff. Remarque: il n’y a pas de commande git –no-ff rebase.

Une configuration de démonstration rapide

Avant d’examiner les deux façons de fusionner Git, commençons par configurer un référentiel Git fonctionnel avec les commandes suivantes:

1
2
3
4
5
6

mkdir mycode

écho “foo bar baz” > mycode / foo.txt

git init mycode

cd mycode

git add foo.txt

git commit -m “Message de validation”

Créons maintenant une nouvelle branche nommée “myfeature” et basculons dessus:

1 git checkout -b myfeature

Nous pouvons maintenant apporter une modification au fichier “foo.txt” dans la branche “myfeature” de notre référentiel local:

1
2

echo -e “foo bar baznquux” > foo.txt

git commit -a -m “a ajouté ma fonctionnalité”

Supposons que notre modification “myfeature” est terminée, et maintenant nous aimerions intégrer cette fonctionnalité dans notre branche “master”.

Notre graphique git ressemblerait à ceci:

1
2
3

   B myfeature

  /

Un maître

Comme indiqué précédemment à propos de Git, nous avons deux façons de procéder: effectuer une fusion ou une rebase.

Comment utiliser: git merge

La commande git merge joint deux ou plusieurs branches ensemble.

Tout d’abord, revenons au “maître”, afin que nous puissions appliquer la fusion sur notre branche principale.

1 git checkout master

Nous pouvons maintenant procéder à la fusion, mais examinons d’abord les deux façons différentes de créer une fusion.

Souvent, le chef de branche actuel est un ancêtre du commit nommé («myfeature»). C’est le cas le plus courant. Dans ce scénario, un nouveau commit n’est pas nécessaire pour stocker l’historique combiné. Au lieu de cela, le git HEAD (avec l’index) est mis à jour pour pointer sur le commit nommé sans créer un commit de fusion supplémentaire.

Le comportement par défaut de la fusion git consiste à effectuer une fusion à avance rapide lorsque cela est possible. Ce comportement par défaut peut être rendu explicite avec l’option -ff, ou ce comportement peut être supprimé avec l’option de fusion sans avance rapide (–no-ff). Lors de la fusion d’une balise annotée, Git crée toujours un commit de fusion même si une fusion rapide est possible.

Lorsque vous utilisez –no-ff, une personne qui examine l’historique git peut clairement voir la branche sur laquelle vous avez extrait pour travailler. Notez également comment la fusion –no-ff a un commit de fusion supplémentaire à la fin.

Ci-dessous, une image qui montre la différence entre une fusion –no-ff et -ff.

git --no-ff rebase

Vous avez donc maintenant la possibilité d’utiliser soit:

1 git merge myfeature

Après cette commande, notre graphique git ressemblerait à ceci:

1 Maître A – B

Ou nous pourrions garder l’historique de la branche en faisant:

1 git merge –no-ff myfeature

Dans ce dernier cas, notre graphique git ressemblerait maintenant à ceci:

1
2
3

  B myfeature

/

Maître A – C

Et si nous exécutons la commande git log suivante:

1 git log –graph –full-history –all –pretty = format: “% h% x09% d% x20% s”

Cela montrera un graphique git similaire:

1
2
3
4
5

* 5368727 (HEAD, master) Fusionner la branche «myfeature»

|

| * 6267227 (myfeature) a ajouté myfeature

| /

* ac54e38 Message de validation

Le type de fusion que vous préférez dépend de la quantité d’informations de branche que vous souhaitez stocker lorsque vous effectuez une fusion.

Comment utiliser: git rebase

La deuxième façon d’intégrer les changements d’une branche dans une autre est de faire un rebase git.

Lorsque la fusion rassemble deux branches tout en préservant le graphique de chaque historique de validation, la nouvelle base unifie les branches en réécrivant les modifications de la branche source afin qu’elles apparaissent comme des enfants de la branche de destination.

Git rebase forward-ports local s’engage sur la tête amont mise à jour. La refondation est le processus de déplacement d’une branche vers un nouveau commit de base.

Voici à quoi cela ressemble dans un graphique git. Supposons que l’historique suivant existe et que la branche actuelle soit «myfeature»:

1
2
3

      A – B – C myfeature

     /

Maître D – E – F – G

Et si nous le faisons maintenant:

1 git rebase master

Le résultat serait:

1
2
3

        Ma fonction A – B ’C

       /

Maître D — E — F — G

La branche «master» contient désormais les modifications de la branche «myfeature» lors de la validation «G» sans créer de validation de fusion. Ainsi, au lieu de rejoindre les branches avec un commit de fusion, le rebasage intègre la branche «myfeature» en s’appuyant sur le maître. Le résultat est un historique linéaire qui peut être plus facile à comprendre pour les développeurs. Le journal git afficherait maintenant l’historique linéaire de “D — E — F — G master”.

En cas de conflit, git rebase s’arrêtera au premier commit problématique et laissera des marqueurs de conflit dans l’arborescence.

Fusionner ou rebaser?

Les deux méthodes d’intégration de code doivent être utilisées lorsqu’elles conviennent le mieux. Il existe différentes opinions sur le moment où une certaine méthode doit être utilisée.

Voici quelques liens qui décrivent des situations dans lesquelles une méthode peut être préférée à l’autre:

  • fusionner ou rebaser?
  • Quand fusionner et quand rebaser
  • Git Team Workflows: fusionner ou rebaser?
Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me