Rebase : ce que c'est, en quoi il diffère de Merge et principe de fonctionnement

Qu'est-ce que Rebase ?

Rebase (rebasage) est une opération Git qui déplace les commits de la branche actuelle vers un nouveau point de base. Au lieu de créer un commit de fusion, rebase prend chaque commit de la branche source et l'applique un par un sur la nouvelle base. Le résultat est une séquence linéaire de commits sans bifurcations.

Le nom rebase vient de « re-base » — changer la base. Alors que merge combine deux branches en un seul point, rebase déplace en fait l'intégralité de votre branche vers un nouvel emplacement, donnant l'impression que vous avez commencé le développement à partir de l'état actuel de la branche cible. Cela crée l'illusion d'un travail parfaitement séquentiel.

Selon Atlassian, 2025, les équipes qui utilisent rebase pour les branches de fonctionnalités consacrent 30% moins de temps à analyser l'historique des commits par rapport aux équipes qui utilisent exclusivement merge. L'historique linéaire simplifie git blame, bisect et la visualisation du journal via git log --oneline.

Différence fondamentale avec Merge

Merge fusionne les branches en créant un commit avec deux parents. Rebase réécrit l'historique : de nouveaux commits sont créés avec de nouveaux hachages, bien que leurs modifications soient identiques aux originales. Cela signifie que rebase modifie les identifiants SHA des commits, ce qui est critique pour les branches publiques.

Comment fonctionne Rebase

Le mécanisme de rebase comprend quatre étapes : Git détermine l'ancêtre commun (base de fusion) de la branche actuelle et de la branche cible, puis applique séquentiellement chaque commit de la branche actuelle sur la branche cible. Si un conflit survient à une étape, rebase s'arrête et attend une résolution.

# Situation initiale : la branche feature est en retard de 3 commits sur develop
git checkout feature/new-login
git rebase develop

# Git prend 3 commits de feature et les applique sur develop
# S'il n'y a pas de conflits — rebase se termine automatiquement
# S'il y en a — Git s'arrête sur le commit conflictuel

Après rebase, la branche de fonctionnalité contient tous les commits de develop plus ses propres commits, qui apparaissent comme une continuation de develop. Cela permet de fusionner dans develop via fast-forward sans créer de commit de fusion.

Processus étape par étape

Prenons un exemple détaillé : un développeur a créé une branche de fonctionnalité à partir de develop, a fait deux commits, pendant que d'autres développeurs ajoutaient trois commits à develop. Rebase déplacera les deux commits de fonctionnalité vers une nouvelle position, créant leurs copies avec de nouveaux SHA.

# 1. Créer une branche feature
git checkout -b feature/payment-refactor develop

# 2. Faire des commits dans feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Mettre à jour develop (travail des collègues)
git checkout develop
git pull

# 4. Rebaser feature sur le nouveau develop
git checkout feature/payment-refactor
git rebase develop

# 5. Maintenant feature peut être fusionnée via fast-forward
git checkout develop
git merge feature/payment-refactor

Si un conflit survient à l'étape 4, Git s'arrête sur le commit problématique. Le développeur résout le conflit, exécute git add puis git rebase --continue. Pour sauter un commit — git rebase --skip, pour annuler tout le rebase — git rebase --abort.

Saut automatique des commits vides

Le drapeau --empty contrôle le comportement de rebase avec les commits vides — situations où toutes les modifications d'un commit sont déjà présentes dans la branche cible. Par défaut, rebase s'arrête et demande une décision. Avec --empty=drop, Git saute automatiquement ces commits sans s'arrêter, accélérant le rebase massif avec un grand nombre de commits.

Rebase interactif

Le rebase interactif (git rebase -i) est un outil puissant pour éditer l'historique des commits. Il ouvre un éditeur avec une liste de commits et des commandes clés : pick (conserver), reword (changer le message), edit (changer le contenu), squash (fusionner avec le précédent), fixup (fusionner sans message), drop (supprimer).

# Rebase interactif des 4 derniers commits
git rebase -i HEAD~4

# L'éditeur ouvrira un plan de rebase :
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Nous changeons en :
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Résultat : trois commits (écran de connexion, validation, mise en page) sont fusionnés en un seul, et le commit avec les commentaires est supprimé. Cela permet de soumettre un historique propre pour la révision du code sans brouillons ni corrections. Le rebase interactif est un outil standard pour préparer une branche de fonctionnalité avant une Pull Request.

Rebase vs Merge : comparaison

Rebase et Merge résolvent le même problème — intégrer les modifications — mais de manières fondamentalement différentes. Le choix entre eux dépend du type d'historique que vous souhaitez voir dans git log et de qui d'autre travaille avec votre branche.

Règle pratique : utilisez merge pour l'intégration dans les branches partagées (develop, main) et rebase pour mettre à jour les branches de fonctionnalités personnelles. De nombreuses équipes combinent les deux : rebase de la fonctionnalité sur develop, puis --no-ff merge dans develop.

Impact sur git bisect

Git bisect est un outil pour trouver le commit qui a introduit une régression. En utilisant merge, git bisect traverse correctement les commits de fusion en considérant les deux parents. Avec rebase, bisect fonctionne plus rapidement car l'historique est linéaire et ne nécessite pas de bifurcations. Cependant, si rebase a été effectué après que les commits sont devenus connus de l'équipe, les SHA originaux sont perdus et bisect peut ne pas trouver le commit problématique.

Quand utiliser Rebase

Rebase est optimal dans trois scénarios : préparer une branche de fonctionnalité pour une Pull Request, mettre à jour une branche personnelle vers l'état actuel de main/develop, et nettoyer l'historique avant la fusion. Dans chaque cas, rebase améliore la lisibilité de l'historique sans risque pour le travail d'équipe.

Avant une Pull Request, il est recommandé d'effectuer un rebase interactif pour combiner les commits de brouillon (WIP, corrections post-révision) en unités logiques significatives. Cela facilite la révision de code : le relecteur voit non pas 15 petits commits mais 3-5 modifications structurées avec des messages clairs.

Pour la mise à jour d'une branche de fonctionnalité, rebase est préférable à merge car il ne crée pas de commits de fusion inutiles. Si vous faites périodiquement git rebase develop dans la branche de fonctionnalité, la fusion finale n'aura pas une cascade de 10 commits de fusion — seulement des commits propres de la fonctionnalité sur develop.

Le nettoyage de l'historique via rebase interactif avant la fusion permet de masquer les corrections mineures (fautes de frappe, formatage) et de regrouper les commits par fonctionnalité. Les messages Git doivent suivre la convention Conventional Commits (fix:, feat:, refactor:, docs:), qui génère un changelog automatique.

Risques et règles de Rebase

Rebase est une opération dangereuse si elle est appliquée incorrectement. Le principal risque est la réécriture de l'historique publié. Si un développeur rebase une branche que d'autres ont déjà poussée et utilisent, leurs copies locales se désynchroniseront et ils devront effectuer un force-pull avec risque de perte de données.

• Règle d'or : ne faites jamais rebase de commits qui existent déjà dans le dépôt partagé. Cela s'applique à toutes les branches accessibles aux autres membres de l'équipe
• Force push : après rebase d'une branche de fonctionnalité locale, un push avec le drapeau --force-with-lease est nécessaire, plus sûr que --force car il vérifie si quelqu'un d'autre a mis à jour la branche sur le serveur
• Perte de contexte : rebase détruit les informations sur quand et à partir de quelle branche la branche de fonctionnalité a été créée. Si la préservation des dates de création de la branche est importante, utilisez merge
• Conflits : pendant rebase, les conflits doivent être résolus pour chaque commit individuellement, ce qui peut être fastidieux avec un grand nombre de commits

Pour minimiser les risques, suivez cette règle : rebase uniquement pour les branches personnelles qui n'ont pas été publiées. Si une branche est déjà dans le dépôt partagé, utilisez merge avec --no-ff. Si vous devez rebaser une branche publiée, prévenez l'équipe et coordonnez le force push à l'avance.

La protection automatique contre le rebase dangereux est implémentée via des hooks côté serveur : un hook pre-receive sur le serveur Git peut vérifier si le push réécrit des commits publiés. GitHub et GitLab fournissent une protection intégrée pour les branches protégées — le force push est bloqué sauf si la protection est levée par un administrateur.