Git rebase vs merge : quand utiliser lequel

Deux façons d'intégrer des changements

Lorsque vous travaillez avec des branches Git, il arrive un moment où vous devez intégrer les changements d'une branch dans une autre. Git vous offre deux stratégies principales pour cela : merge et rebase. Les deux aboutissent au même résultat -- votre branch contient tous les derniers changements -- mais ils le font de manières fondamentalement différentes, et choisir le bon a son importance pour l'historique de votre projet et le workflow de votre équipe.

Comment fonctionne Merge

Un merge prend deux branches et les combine en créant un nouveau merge commit. Ce merge commit a deux parents : la pointe de votre branch actuelle et la pointe de la branch que vous intégrez.

git checkout feature/login
git merge main

Après cela, votre branch de fonctionnalité contient tous les changements de main, reliés par un merge commit. L'historique des deux branches est préservé exactement tel qu'il s'est déroulé. Si vous regardez le graphe de commits, vous verrez les deux lignes de développement converger au point de merge.

Les caractéristiques clés du merge :

• Non destructif. Aucun commit existant n'est modifié. L'historique reflète exactement ce qui s'est passé.
• Crée un merge commit. Ce commit supplémentaire lie les deux historiques ensemble.
• Préserve le contexte. Vous pouvez toujours voir quand une branch a été créée et quand elle a été fusionnée.

Merge fast-forward

Si votre branch n'a pas divergé de la cible (c'est-à-dire qu'il n'y a pas de nouveaux commits sur la cible depuis que vous avez créé votre branch), Git effectue un merge fast-forward par défaut. Il déplace simplement le pointeur de branch en avant. Aucun merge commit n'est créé car il n'est pas nécessaire. Vous pouvez forcer un merge commit même dans ce cas avec :

git merge --no-ff feature/login

C'est utile lorsque vous voulez conserver le fait que le travail a été effectué sur une branch séparée, même si le merge était trivial.

Comment fonctionne Rebase

Rebase adopte une approche différente. Au lieu de créer un merge commit, il rejoue vos commits par-dessus une autre branch. Le résultat est un historique linéaire qui donne l'impression que vous avez commencé votre travail à partir du dernier point de la branch cible.

git checkout feature/login
git rebase main

Ce qui se passe en coulisses :

• Git trouve l'ancêtre commun des deux branches.
• Il retire temporairement les commits de votre branch.
• Il déplace le pointeur de votre branch à la pointe de main.
• Il rejoue vos commits un par un par-dessus.

L'historique résultant est parfaitement linéaire. Pas de merge commit, pas de lignes qui se séparent et convergent dans le graphe. On dirait que vous avez écrit tout votre code après les derniers changements sur main, même si ce n'est pas ce qui s'est réellement passé.

Les caractéristiques clés du rebase :

• Crée un historique linéaire. Le graphe de commits est propre et facile à lire.
• Réécrit les hash des commits. Les commits rejoués obtiennent de nouveaux hash SHA, même si leur contenu est identique.
• Pas de merge commit. La branch s'intègre proprement sans commits supplémentaires.

Quand utiliser Merge

Merge est le choix le plus sûr et le plus simple dans plusieurs situations :

• Branches partagées. Lorsque plusieurs personnes travaillent sur la même branch, merge préserve l'historique de chacun sans réécrire les commits dont les autres dépendent.
• Préserver l'historique est important. Dans les projets où vous devez tracer exactement quand et comment les changements ont été intégrés, merge fournit un enregistrement complet et inaltéré.
• Intégration de branches longue durée. Lors du merge d'une branch de release dans main, ou de la combinaison de deux branches qui ont significativement divergé, un merge commit marque clairement le point d'intégration.
• Vous voulez de la simplicité. Merge est conceptuellement plus facile. Il y a moins de risques d'erreur, surtout pour les développeurs qui débutent avec Git.

Quand utiliser Rebase

Rebase excelle quand vous voulez un historique de projet propre et linéaire :

• Mettre à jour une branch de fonctionnalité. Avant de merge votre fonctionnalité dans main, faire un rebase par-dessus le dernier main vous donne un ensemble propre de commits qui s'appliquent directement sans merge commit.
• Garder un historique propre. Un historique linéaire est plus facile à naviguer avec git log, plus facile à bissecter lors de la chasse aux bugs, et plus facile à relire lors des pull requests.
• Nettoyage local. Si vous avez fait de petits commits incrémentaux en travaillant, vous pouvez utiliser rebase pour tout nettoyer avant de partager votre branch.

La règle d'or du Rebase

Ne jamais faire un rebase de commits qui ont été pushés sur une branch partagée.

C'est la règle la plus importante à retenir. Comme rebase réécrit les hash des commits, toute personne ayant basé son travail sur les commits originaux aura des problèmes. Son historique ne correspond plus à l'historique rebasé, ce qui entraîne des commits dupliqués, des conflits et de la confusion.

La règle est simple : si d'autres personnes ont pu pull vos commits, ne faites pas de rebase. Utilisez rebase uniquement sur vos branches locales, ou sur des branches où vous êtes le seul contributeur.

Si vous faites accidentellement un rebase d'une branch partagée, les autres développeurs de l'équipe devront gérer l'historique divergent. Cela implique généralement un force-push (qui écrase le dépôt distant) et demande à tout le monde de reset leurs copies locales. C'est perturbant et évitable.

Rebase interactif : réécrire l'historique avec précision

Le rebase interactif (git rebase -i) va au-delà du simple déplacement de commits. Il vous permet de modifier l'historique des commits lui-même :

git rebase -i HEAD~5

Cela ouvre une liste des 5 derniers commits, où vous pouvez :

• pick -- garder le commit tel quel
• reword -- modifier le message du commit
• edit -- faire une pause pour modifier le commit
• squash -- combiner avec le commit précédent
• fixup -- comme squash, mais en supprimant le message du commit
• drop -- supprimer entièrement le commit
• reorder -- changer l'ordre en réarrangeant les lignes

Le rebase interactif est puissant pour nettoyer une branch désordonnée avant le merge. Vous pouvez squash les commits "correction typo" dans leur parent, reformuler les messages peu clairs et réorganiser les commits pour qu'ils racontent une histoire logique.

Un workflow pratique

Beaucoup d'équipes utilisent une approche combinée qui tire le meilleur des deux stratégies :

1. Créer une branch de fonctionnalité depuis main.
2. Pendant le travail, faire périodiquement un rebase de votre branch de fonctionnalité sur main pour rester à jour.
3. Avant d'ouvrir une pull request, utiliser le rebase interactif pour nettoyer vos commits.
4. Merge la branch de fonctionnalité dans main (souvent avec un merge commit pour marquer le point d'intégration).

Cela vous donne un historique propre et linéaire sur la branch de fonctionnalité et un point de merge clair sur main. C'est un compromis pragmatique qui fonctionne bien pour la plupart des équipes.

Rebase et Merge dans GitSquid

GitSquid prend en charge merge et rebase directement depuis l'interface. Vous pouvez merge des branches depuis le menu contextuel sur n'importe quel label de branch dans le graphe de commits. Pour le rebase, GitSquid inclut un éditeur visuel de rebase interactif qui vous permet de réorganiser, squash, fixup, reword et drop des commits en glissant-déposant et en cliquant plutôt qu'en éditant un fichier texte dans votre terminal. Cela rend le rebase interactif accessible même si vous trouvez la version en ligne de commande intimidante.

Résumé

Ni merge ni rebase n'est universellement meilleur. Ce sont des outils pour des situations différentes. Comprenez ce que chacun fait à votre historique, suivez la règle d'or du rebase, et choisissez celui qui correspond au contexte. Votre futur vous lisant git log vous en remerciera.