Git Rebase vs. Merge : Comprendre les différences et quand les utiliser

git merge et git rebase rassemblent tous deux le travail d'une branche avec une autre branche, mais ils laissent des historiques très différents derrière eux. Choisir le mauvais sur une branche partagée peut compliquer la vie de tous ceux qui ont déjà récupéré vos commits.

Ce guide explique ce que fait chaque commande, comment elle modifie l'historique des commits, et quand vous devriez utiliser merge ou rebase dans un flux de travail d'équipe.

Qu'est-ce que git merge ?

git merge est la manière la plus courante et la plus simple d'intégrer des changements d'une branche à une autre. Lorsque vous fusionnez la branche B dans la branche A, Git recherche un commit ancêtre commun entre A et B. Il crée ensuite un nouveau commit (un commit de fusion) sur la branche A qui a deux parents : le sommet de A et le sommet de B. Ce commit de fusion encapsule tous les changements introduits dans B depuis l'ancêtre commun.

Caractéristiques clés de git merge :

• Préserve l'historique : git merge crée un commit de fusion, qui enregistre explicitement quand et où deux branches ont été jointes. Cela préserve le contexte historique de votre développement, montrant les points de bifurcation et de fusion.
• Non destructif : Il ne réécrit pas les commits existants. Les commits originaux sur les deux branches restent intacts.
• Crée des commits de fusion : Chaque fusion entraîne un nouveau commit, ce qui peut conduire à un historique de commits plus complexe et non linéaire, souvent visualisé comme un graphe avec plusieurs branches qui divergent et convergent.

Exemple de git merge :

Supposons que vous ayez une branche main et que vous créiez une branche feature à partir de celle-ci. Vous faites quelques commits sur feature, et pendant ce temps, de nouveaux commits sont ajoutés à main.

# État initial :
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Passer à la branche main
git checkout main

# Fusionner la branche feature dans main
git merge feature

# État résultant :
# A -- B -- C -- F (main)
#      \       /
#       D -- E (feature)
# Où F est le commit de fusion avec les parents C et E

Dans ce scénario, le commit F est un commit de fusion qui apporte les changements de E dans main. La branche feature existe toujours indépendamment.

Qu'est-ce que git rebase ?

git rebase, quant à lui, est une façon d'intégrer des changements d'une branche à une autre en réécrivant votre historique de commits. Lorsque vous rebasez la branche B sur la branche A, Git prend les commits qui sont uniques à B, les stocke temporairement, réinitialise B au sommet de A, puis réapplique les commits stockés un par un au-dessus de A.

Caractéristiques clés de git rebase :

• Réécrit l'historique : git rebase crée de nouveaux commits avec le même contenu que les originaux, mais avec de nouveaux identifiants de commit. Cela rend l'historique des commits linéaire, comme si la branche de fonctionnalité avait été développée séquentiellement après les derniers changements sur la branche cible.
• Évite les commits de fusion : Il évite généralement de créer des commits de fusion, ce qui donne un historique plus propre et linéaire.
• Peut être destructeur : Comme il réécrit l'historique, git rebase doit être utilisé avec prudence, surtout sur les branches qui ont été partagées avec d'autres.

Exemple de git rebase :

En utilisant le même scénario que ci-dessus :

# État initial :
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Passer à la branche feature
git checkout feature

# Rebaser la branche feature sur main
git rebase main

# État résultant :
# A -- B -- C (main)
#           \
#            D' -- E' (feature)
# Où D' et E' sont de nouveaux commits avec le même contenu que D et E

Après avoir rebasé feature sur main, les commits D et E sont rejoués au-dessus du commit C. La branche feature commence maintenant à partir du dernier commit de main, et l'historique est linéaire. Les commits originaux D et E sont effectivement abandonnés (mais récupérables pendant un certain temps).

Rebase vs. Merge : Principales différences résumées

Fonctionnalité	git merge	git rebase
Historique	Préserve l'historique original ; crée des commits de fusion	Réécrit l'historique ; crée un historique linéaire
Identifiants de commit	Les commits originaux restent inchangés	De nouveaux commits sont créés ; les anciens sont abandonnés
Collaboration	Sûr pour les branches partagées	Risqué pour les branches partagées ; à utiliser sur les branches locales/privées
Complexité	Peut conduire à un historique complexe et non linéaire	Crée un historique plus simple et linéaire
Objectif	Intègre les changements tout en conservant le contexte	Intègre les changements en les réappliquant séquentiellement

Quand utiliser git merge

git merge est généralement le choix le plus sûr et le plus courant, surtout pour intégrer des changements dans des branches à longue durée de vie ou lors d'une collaboration en équipe sur une branche partagée.

• Intégration dans main/master : Lorsque vous souhaitez intégrer une branche de fonctionnalité terminée dans votre ligne de développement principale (main ou master), la fusion est souvent préférée. Cela préserve le contexte du développement de la branche de fonctionnalité et marque explicitement son point d'intégration.
• Branches partagées : Si vous travaillez sur une branche partagée avec d'autres membres de l'équipe, git merge est presque toujours le bon choix. Rebaser une branche partagée peut causer des problèmes importants à vos collaborateurs car cela réécrit un historique sur lequel ils ont peut-être déjà basé leur travail.
• Préservation de l'historique des versions : Pour les branches importantes comme les branches de version, le maintien d'un historique clair et immuable avec des commits de fusion peut être bénéfique pour l'audit et la compréhension des versions passées.

Scénario : Fusionner une fonctionnalité terminée dans main

# Supposons que vous soyez sur la branche 'main' et que votre branche de fonctionnalité soit à jour
git checkout main
git merge feature-branch-name

Cela créera un commit de fusion sur main incorporant tous les changements de feature-branch-name.

Quand utiliser git rebase

git rebase est puissant pour maintenir vos branches locales à jour avec une branche principale et pour nettoyer votre propre historique de commits avant de le partager.

• Mise à jour des branches de fonctionnalités locales : Si vous avez créé une branche de fonctionnalité et que la branche main a avancé, rebaser votre branche de fonctionnalité sur main vous permet d'incorporer ces changements en amont sans créer un commit de fusion immédiat. Cela maintient les commits de votre branche de fonctionnalité logiquement séquentiels.
• Nettoyage de l'historique local (Rebase interactif) : git rebase -i (rebase interactif) est inestimable pour ranger vos propres commits avant de les pousser. Vous pouvez écraser plusieurs petits commits en un seul, réorganiser les commits, modifier les messages de commit, ou même supprimer des commits.
• Maintien d'un historique de projet linéaire : Si votre équipe adopte un flux de travail qui privilégie un historique propre et linéaire, rebaser les branches de fonctionnalités sur main avant de les fusionner peut y parvenir. Cependant, cela nécessite une adhésion stricte à la règle de ne pas rebaser les branches partagées.

Scénario : Mettre à jour votre branche de fonctionnalité avec les changements en amont

# Supposons que vous soyez sur votre branche 'feature' et que 'main' ait de nouveaux commits
git checkout main             # Passer à main
git pull origin main        # S'assurer que main est à jour
git checkout feature        # Revenir à votre branche feature
git rebase main             # Rejouer vos commits feature au-dessus du dernier main

Maintenant, votre branche feature est basée sur le dernier main, et lorsque vous fusionnerez éventuellement feature dans main, ce sera une fusion fast-forward (aucun commit de fusion nécessaire si aucun nouveau commit n'a été fait sur main depuis votre rebase).

Scénario : Nettoyer vos commits locaux (Rebase interactif)

# Supposons que vous ayez fait plusieurs petits commits sur votre branche feature
git checkout feature-branch-name
git rebase -i HEAD~3      # Rebaser les 3 derniers commits de manière interactive

Cela ouvrira un éditeur où vous pourrez choisir de pick, reword, edit, squash, fixup, ou drop vos commits, vous permettant de les consolider en un ensemble plus significatif.

Bonnes pratiques et avertissements

• Ne rebasez pas les branches partagées/publiques : Rebaser des branches que d'autres ont déjà récupérées et sur lesquelles ils ont basé leur travail fera diverger leur historique du vôtre. Utilisez git merge pour les branches publiques ou partagées, sauf si votre équipe a un flux de travail explicite de force-push.
• Rebasez sur vos propres branches : Le rebase est excellent pour vos branches de fonctionnalités locales et privées afin de les garder propres et à jour. Une fois que vous êtes satisfait de vos modifications locales, vous pouvez ensuite les fusionner dans une branche partagée.
• Comprenez l'impact : Avant d'exécuter git rebase, assurez-vous de comprendre qu'il réécrit l'historique. Si vous n'êtes pas sûr, git merge est toujours l'option la plus sûre.
• Tenez compte du flux de travail de votre équipe : Discutez avec votre équipe de la stratégie (merge vs. rebase) qu'elle préfère ou de ce que dicte votre flux de travail défini.
• Un historique propre est important : Bien que git merge préserve l'historique, un historique rempli de nombreux petits commits de fusion insignifiants peut devenir bruyant. git rebase peut aider à créer un historique plus propre et plus lisible, surtout pour les branches de fonctionnalités avant qu'elles ne soient fusionnées.

À retenir

Utilisez git merge lorsque la préservation de l'historique partagé est importante. Utilisez git rebase pour mettre à jour ou nettoyer votre propre branche locale avant que d'autres personnes n'en dépendent. Lorsque vous n'êtes pas sûr que quelqu'un d'autre a basé son travail sur votre branche, fusionnez plutôt que de rebaser.