Rebase : qu’est-ce que c’est, comment fonctionne rebase et travail avec Git

Qu’est-ce que Rebase dans Git

Rebase est une commande Git qui rebase la branche courante sur une branche spécifiée : elle prend tous les commits de la branche courante, les sauvegarde temporairement, déplace le pointeur de branche vers le commit cible et applique séquentiellement les commits sauvegardés par-dessus. Le résultat : l’historique semble comme si le développeur avait travaillé directement depuis le dernier commit de la branche cible.

La syntaxe de base : git rebase main — étant sur une branche de fonctionnalité, cette commande déplace tous les commits de la fonctionnalité vers le sommet de main. Git utilise une stratégie de fusion à trois voix pour chaque commit individuellement. Si le commit A est déjà présent dans la branche cible (déterminé par le hash), Git le saute automatiquement, évitant les modifications en double.

Rebase prend également en charge le mode onto pour déplacer un sous-ensemble de commits : git rebase --onto target start end — cette forme permet d’extraire une plage de commits d’une branche et de les appliquer sur une autre. Par exemple, git rebase --onto main feature~3 feature déplace les trois derniers commits de la branche feature sur main.

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge : Différences Clés

Rebase et merge résolvent la même tâche — combiner des modifications de différentes branches — mais de manières fondamentalement différentes. Merge préserve l’historique complet des fusions en créant un commit de merge avec deux parents. Rebase réécrit l’historique, le rendant linéaire. Le choix entre eux dépend du flux de travail de l’équipe et des règles de gestion du référentiel.

La principale différence est comment le fait de la fusion est enregistré. Merge préserve : « à ce stade nous avons fusionné feature dans main » — c’est informatif pour l’historique du projet mais encombre le journal avec des fusions fréquentes. Rebase montre : « les commits de fonctionnalité ont été faits séquentiellement depuis le dernier état de main » — c’est propre mais cache le fait que le développement a été fait en parallèle.

La deuxième différence est le traitement des conflits. Avec merge, les conflits sont résolus une fois et la solution est enregistrée dans le commit de merge. Avec rebase, des conflits peuvent survenir pour chaque commit déplacé, chacun nécessitant une résolution séparée. C’est plus laborieux mais permet un contrôle plus précis sur les modifications qui aboutissent dans la version finale.

Rebase Interactif : Commandes et Drapeaux

Rebase interactif (git rebase -i) est un mode où Git ouvre un éditeur avec une liste de commits et les actions disponibles pour chacun. Le développeur peut réécrire l’historique avant de pousser vers un dépôt distant. C’est l’outil principal pour maintenir des commits propres dans une branche de fonctionnalité.

Commandes disponibles en mode interactif : pick (garder le commit tel quel), reword (changer le message du commit), edit (s’arrêter pour modifications), squash (combiner avec le commit précédent, en gardant les deux messages), fixup (combiner, en supprimant le message), drop (supprimer le commit). Chaque commande est placée avant le hash du commit dans l’éditeur ouvert.

Squash et fixup sont les commandes les plus fréquemment utilisées pour combiner des commits. Si un développeur a fait 5 petits commits de correction pendant le travail, squash les fusionne en un seul commit logique avec un message significatif. Fixup est utile pour corriger des fautes de frappe : les modifications vont dans le commit précédent sans conserver leur propre message.

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

Le drapeau --autosquash organise automatiquement fixup/squash pour les commits dont les messages commencent par fixup! ou squash!. Cela accélère le travail si le développeur pré-marque les commits pour une combinaison ultérieure. Le drapeau --committer-date-is-author-date conserve la date originale du commit lors du rebasage — utile pour maintenir l’ordre chronologique dans l’historique.

Résolution des Conflits pendant Rebase

Les conflits pendant rebase surviennent lorsque Git ne peut pas appliquer automatiquement un commit déplacé en raison de contradictions avec les modifications dans la branche cible. Contrairement à merge, où le conflit est résolu une fois, avec rebase chaque commit peut provoquer un conflit, et il doit être résolu séquentiellement pour chaque commit du plus ancien au plus récent.

Lorsqu’un conflit survient, Git met en pause le rebase et signale quel commit a causé le problème. Le développeur ouvre le fichier en conflit (Git marque les zones de conflit avec des marqueurs <<<<<<<, =======, >>>>>>>), l’édite, l’ajoute à l’index (git add) et continue le rebase avec git rebase --continue. Si aucune solution n’est trouvée — git rebase --abort annule complètement le rebase.

Conseil : avec des conflits multiples, il est plus efficace d’utiliser git mergetool, qui ouvre un éditeur visuel pour résoudre les conflits. On peut aussi sauter le commit problématique (git rebase --skip), mais cela supprime ses modifications de l’historique final, ce qui est rarement la bonne décision.

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

Quand ne pas faire Rebase

La règle d’or de rebase : ne jamais rebaser des commits qui ont déjà été poussés vers un dépôt distant et sont disponibles pour d’autres développeurs. Comme rebase réécrit les hashs des commits, les collègues rencontreront des conflits en essayant de se synchroniser — leur historique local divergera de l’historique distant réécrit.

Une situation où rebase est catégoriquement interdit : si quelqu’un a déjà créé une branche basée sur vos commits (par exemple, un collègue a créé une branche à partir de votre branche de fonctionnalité), réécrire l’historique brisera son travail. Dans ces cas, utilisez merge. Il n’est pas non plus recommandé de faire rebase juste avant une échéance — une erreur lors de la résolution des conflits peut prendre plus de temps que prévu et bloquer la sortie.

Exception : si la branche est utilisée par un seul développeur (branche de fonctionnalité personnelle, non publiée ou publiée en mode brouillon), rebase avant le push est une pratique standard. Après la publication et le début du travail collaboratif — seulement merge. GitHub et GitLab proposent par défaut squash merge comme compromis : il combine les commits en un seul mais ne réécrit pas l’historique de la branche cible.

• Branches publiques (main, develop, release) — rebase est totalement interdit.
• Commits d’autrui — si la branche contient des commits d’un autre développeur, rebase n’est pas autorisé.
• Avant la sortie — les risques de conflits sont plus élevés : merge est plus sûr un jour avant l’échéance.
• Branches avec tags — déplacer un commit avec un tag viole les conventions de versionnement sémantique.
• CI/CD lié aux hashs — certains systèmes de déploiement identifient les builds par hash de commit ; rebase cassera le suivi.

Flux de Travail Pratique avec Rebase

Les équipes modernes utilisent le plus souvent un flux de travail orienté rebase combiné avec GitHub Flow. Le processus est le suivant : le développeur crée une branche de fonctionnalité à partir de main, y travaille, se synchronise périodiquement via git rebase main, et avant de créer une pull request effectue un rebase interactif pour nettoyer l’historique.

Après la création d’un PR (si de nouvelles modifications de main doivent être tirées), git pull --rebase main est utilisé au lieu d’un git pull normal. Cela tire les modifications sans créer un commit de merge inutile. Git pull avec le drapeau --rebase équivaut à git fetch + git rebase — Git télécharge d’abord les nouveaux commits, puis rebase les modifications locales par-dessus.

Git permet de configurer rebase comme comportement par défaut pour pull : git config --global pull.rebase true. Après ce réglage, git pull effectue toujours rebase au lieu de merge. Si un pull normal est nécessaire — on utilise git pull --no-rebase. De nombreuses équipes activent aussi autostash : git config --global rebase.autoStash true — cela cache automatiquement les modifications non commitées avant rebase et les restaure après.