Fusionner une branche en master dans Git

1. Conditions préalables
2. Préparation de la fusion dans Git
3. Fusionner une branche dans le maître avec la méthode merge dans Git
4. Fusionner une branche dans le maître avec la méthode rebase
5. Conclusion

L’une des fonctionnalités les plus puissantes de git est la création de branches et l’opération de fusion. Git permet aux utilisateurs de créer une nouvelle branche et de les fusionner dans le code de développement. Cette fonctionnalité améliore le flux de travail du processus de développement pour plusieurs projets en encourageant des tâches plus spécifiques, plus petites et plus granulaires.

Dans cet article de didacticiel, nous aborderons différentes approches pour fusionner la branche de fonctionnalité git avec master.

Le principal avantage de git est son système de branchement. C’est sur ces branches que repose toute la magie de GIT ! La branche master portera toutes les modifications apportées. Le but n’est donc pas de faire les modifications directement sur cette branche mais de les faire sur d’autres branches, et après divers tests, de les intégrer sur la branche master.

Dans notre tutoriel pour simplifier, considérons qu’il existe deux branches, la branche master et la branche feature dite feature-1. La branche principale est la branche principale qui contient le code de production, et la deuxième branche est l’endroit où les modifications seront exécutées ou de nouvelles fonctionnalités seront implémentées. En fin de compte, si une fonctionnalité ou un bogue est approuvé, il sera fusionné avec le master.

Commençons la démonstration de la fusion de deux branches avec un exemple réel. Pour commencer, nous avons besoin des éléments suivants.

Conditions préalables

Créer un dépôt sur GitHub

Un référentiel initial peut être créé comme introduit dans Github

Ensuite, ajoutez deux fichiers sur la branche Master en utilisant le bouton Ajouter un fichier sur la page du référentiel. Les noms des fichiers sont les suivants.

• file1.txt
• file2.txt

Dans cet exemple, le contenu textuel suivant est ajouté respectivement à file1.txt et file 2.txt.

$ cat file1.txt
This is dummy text line 1
This is dummy text line 2
$ cat file2.txt
This is dummy test in 2nd file

Cloner le référentiel

Ensuite, clonez votre référentiel nouvellement créé de GitHub sur votre système pour créer une copie locale du code. L’URL de clonage peut être récupérée à partir du bouton Code comme ci-dessous.

Utilisez la commande suivante pour cloner.

$ git clone git@github.com:project/demorepo.git

Une fois cloné avec succès, utilisez la commande suivante pour afficher et vérifier le contenu des fichiers de la branche principale :

$ cat file1.txt
This is dummy text line 1
This is dummy text line 2
$ cat file2.txt
This is dummy test in 2nd file

Créer une branche d’entité

$ git branch feature-1

Cette commande crée une nouvelle branche et ne crée pas de nouveau commit sur git.

Branche de fonctionnalité de paiement

Auparavant, nous avons créé une nouvelle branche en utilisant git branch feature-1. Mais, la branche active est la branche master. Pour activer la nouvelle branche, utilisez cette commande dans le terminal :

$ git checkout feature-1
Switched to branch 'feature-1'

La commande ci-dessus fera passer la branche active de master à feature-1. Maintenant, cette branche est prête pour le développement individuel.

Modifier les fichiers dans la branche d’entités

Nous allons ajouter des commits ou ajouter de nouvelles lignes dans la branche feature-1. Dans ce cas, file2.txt sera modifié localement et fusionné plus tard dans la branche master.

Pour les changements jusqu’à présent, notre diagramme de validation ressemblera à ci-dessous. A et E représentent les états de branche master et feature-1. Actuellement, les commits A et E sont les mêmes car aucun fichier n’est modifié lors de la vérification.

A  ← master
   \
     E  ← feature-1

Maintenant, file1.txt est mis à jour avec le nouveau texte. Utilisez cette commande pour mettre à jour le contenu.

$ echo "file update in feature branch" > file1.txt

Maintenant, file2.txt a le contenu ci-dessous.

$ cat file2.txt
This is dummy test in 2nd file

La différence entre l’ancien et le nouveau contenu dans file1.txt peut être vérifiée à l’aide de la commande ci-dessous.

$ git diff
diff --git a/file1.txt b/file1.txt
index 11d66d4..48c9378 100644
--- a/file1.txt
+++ b/file1.txt
@@ -1,2 +1 @@
-This is dummy text line 1
-This is dummy text line 2
+file update in feature branch

Maintenant, préparez ce fichier et créez un commit local via la commande ci-dessous.

$ git add file1.txt
$ git commit -am "update file via feature-1"
[feature-1 22b60b8] update file via feature-1
 1 file changed, 1 insertion(+), 2 d

Un instantané actuel de l’arbre de validation ressemblera à ci-dessous. Ici, F est un nouveau commit créé à l’étape précédente.

A  ← master
  \
    E --- F ← feature-1

Pour illustrer un exemple concret, le master distant est également modifié simultanément par d’autres développeurs, et ces modifications sont poussées en tant que commit C et commit D vers master.

A --- B --- C --- D ← master
   \
      E --- F ← feature-1

Vous trouverez ci-dessous le contenu mis à jour de file1.txt dans le référentiel Github de la branche master. Remarquez que la ligne 2 est mise à jour et que les lignes 3 et 4 sont nouvellement créées.

Cela peut également être validé localement en visualisant l’historique de votre branche dans le shell de commande en temps réel à l’aide de la commande ci-dessous.

$ git fetch
$ git log --all --decorate --oneline --graph

Préparation de la fusion dans Git

Avec Git, nous avons deux possibilités pour fusionner nos changements de branche de fonctionnalité avec la branche master distante :

1. La méthode merge
   Git merge est une commande qui valide les modifications dans une autre branche. Il permet aux développeurs de prendre leurs lignes de code indépendantes de la branche de fonctionnalité et de les intégrer dans une seule branche sur master via l’outil git merge.

2. La méthode rebase
   Git rebase est encore une autre commande utilisée essentiellement dans le même but, sauf qu’elle le fait très différemment.

Comprenons les deux sens en détail :

Fusionner une branche dans le maître avec la méthode merge dans Git

Le merge vise à consolider les branches feature et master au commit qui conserve le contenu de toutes les branches impliquées. Git réalise ce que l’on appelle un commit de fusion. Cela signifie également que merge manipule plusieurs branches.

Lorsque les branches ont divergé, c’est-à-dire que l’une n’est pas l’ancêtre de l’autre. Git peut réaliser la fusion en créant un nouveau commit supplémentaire qui a plusieurs parents. Dans l’illustration suivante, si vous avez un commit D et un commit F dans différentes branches et que vous mélangez les branches ( via git merge) le résultat est un commit G dont les parents sont B et E.

A --- B --- C --- D ---	
  \				         \  
    \					  G  ← master
      E --- F --------- /	

Dans le diagramme ci-dessus, G est un commit nouvellement créé et créé entièrement par git. Ce commit a deux parents ! et ils ont un ordre :

• Le premier parent est D, qui était master précédemment.
• Le second parent est F, qui était feature-1 auparavant.

Ce type de commit est appelé un commit de fusion.

Revenez maintenant à notre exemple de référentiel et fusionnez la branche feature-1 nouvellement créée en master

Tout d’abord, vérifiez la branche master.

$ git checkout master

Maintenant, tirez les modifications du maître distant vers le master local.

$ git pull origin master

From github.com:repo/demorepo

 * branch            master     -> FETCH_HEAD
   Updating 17cc6b4..a802b6b
   Fast-forward
    file1.txt | 5 ++++-
    1 file changed, 4 insertions(+), 1 deletion(-)

Ensuite, utilisez la commande ci-dessous pour fusionner la branche de fonctionnalité, c’est-à-dire feature-1, avec la branche actuellement active.

$ git merge feature-1

La branche feature-1 sera entièrement fusionnée avec la branche master si cette étape est complétée avec succès. Cependant, si git ne peut pas résoudre ces conflits de fusion automatiquement, il échouera avec une erreur de conflits de fusion.

C’est un scénario très typique ; cela peut arriver lorsque deux branches modifient la même partie du fichier et que git ne peut pas déterminer quelle partie utiliser. C’est exactement ce qui se passe avec notre exemple. Ce cas est montré ci-dessous via git.

Auto-merging file1.txt
CONFLICT (content): Merge conflict in file1.txt
Automatic merge failed; fix conflicts and then commit the result.

Chaque fois que git rencontre un conflit, il ajoute <<<<<<< & ======= pour mettre en évidence la section qui a causé le conflit et cela doit être résolu manuellement.

Une fois qu’il a été décidé quelle partie conserver dans la version principale finale du fichier, une personne doit supprimer le code non pertinent (y compris les indicateurs de conflit). Finalement, appliquez les modifications à la branche distante comme ci-dessous.

$ git add .
$ git commit -am "resolving the mergeconflict"
[master 1acce69] resolving the mergeconflict
$ git push

De cette façon, la branche feature-1 est fusionnée avec succès avec le master distant.

Ensuite, nous vérifierons à nouveau l’historique de la branche avec la commande ci-dessous.

git log --all --decorate --oneline --graph

Nous pouvons vérifier que git merge a créé un Merge Commit avec commit-id comme 1acce69 pour fusionner la branche feature-1 avec origin/master .

Fusionner une branche dans le maître avec la méthode rebase

Encore une fois, considérez la situation dans laquelle nos branches de fonctionnalité et principale ne sont pas synchronisées et doivent être fusionnées. Rappelons également l’illustration qui montre cette situation précédemment.

A --- B --- C --- D ← master
   \
      E --- F ← feature-1

Comme alternative à la fusion, vous pouvez fusionner la branche feature-1 dans la branche master avec l’option rebase. Le rebase unifie les branches impliquées en mettant simplement les commits de la branche de fonctionnalité devant la branche master.

Ceci sera réalisé via les commandes ci-dessous,

git checkout master
git pull
git checkout feature-1
git rebase master

Nous pouvons avoir l’illustration ci-dessous après avoir exécuté le rebase.

A --- B --- C --- D----(operation rebase)----- E--------F   ← master

D’après l’illustration ci-dessus, il est visible que quelque chose de bien que rebase fait est de produire un historique de commit linéaire, plus propre et plus facile à lire. En fusionnant, il ne génère pas non plus cet étrange merge commit supplémentaire.

L’inconvénient de cette approche est que rebase modifie toute la structure des branches impliquées, y compris la réécriture de l’historique de validation de ces branches. Comme rebase ne crée pas de merge commit, vous n’obtenez pas la traçabilité du moment où deux branches fusionnent puisque rebase génère une branche linéaire à la fin du processus.

Conclusion

Les deux commandes sont très utiles ; cependant, dans des situations différentes, chaque côté a des avantages comme ci-dessous.

Git rebase

• Rationaliser une histoire complexe.
• Évitez de fusionner le bruit de commit dans des référentiels avec des branches occupées.
• Risqué s’il n’est pas utilisé correctement car il ne préserve pas l’histoire.

Git merge

• Simple à utiliser.
• Comme un commit de fusion supplémentaire est créé à chaque fois, l’historique des commits semble confus et sale.
• Préserve l’historique complet et l’ordre chronologique.