Rebaser la branche sur la branche principale

Votre branche de fonctionnalité peut avoir pris du retard pendant que d’autres personnes travaillaient sur la branche principale. Avant la revue, vous voulez replacer vos commits au-dessus de la version actuelle de cette branche, sans créer de commit de fusion inutile. Cette opération modifie l’historique de votre branche : vous devez donc vérifier son état et publier la mise à jour avec précaution.

Actualiser les références distantes

Dans la leçon « Lire l’historique avant de le modifier », vous avez repéré l’ordre des commits et leur dernier ancêtre commun. Avant de rebaser, récupérez l’état publié du dépôt distant avec git fetch. Cette commande met à jour vos références locales, notamment origin/main, sans modifier vos fichiers ni déplacer les commits de votre branche courante.

git switch feature/nouveaux-guides
git status --short
git fetch origin
git log --oneline --graph --decorate --all -12

Le dépôt récupère les références distantes. Le journal affiche les commits de `feature/nouveaux-guides` et de `origin/main`, ce qui vous permet de vérifier que la branche principale distante a avancé et que votre branche contient les commits de la fonctionnalité.

Assurez-vous que le résultat de git status --short est vide avant de commencer : un arbre de travail avec des modifications locales non enregistrées complique le suivi de l’opération. Dans cet exemple, origin/main est la référence à jour de la branche principale publiée sur origin. Si votre équipe utilise un autre nom de branche principale ou de dépôt distant, adaptez cette référence à la configuration réelle du projet.

Rejouer les commits de la fonctionnalité

La commande git rebase origin/main prend les commits propres à votre branche et les rejoue au-dessus du sommet actuel de origin/main. Le contenu de la fonctionnalité reste le même, mais les commits rejoués reçoivent de nouveaux identifiants : leur parent a changé. C’est pourquoi un rebase est une réécriture de l’historique, et non un simple déplacement de fichiers.

git rebase origin/main

Si l’opération se termine sans incident, Git indique que la branche a été rebasée avec succès. Les commits de `feature/nouveaux-guides` se trouvent alors après le dernier commit récupéré sur `origin/main`.

Un rebase peut s’interrompre si les changements ne peuvent pas être rejoués directement. Ne forcez pas la suite et ne publiez pas une branche dans cet état : la leçon « Repérer l’origine d’un conflit » vous apprendra à examiner cette situation, puis les leçons suivantes détailleront la résolution. Une fois le rebase terminé, vérifiez que les commits attendus apparaissent dans le journal et que vos fichiers n’affichent pas de modification inattendue.

git status
git log --oneline --graph --decorate -12
git diff origin/main...HEAD

`git status` confirme que l’arbre de travail est propre. Le journal montre les commits de la fonctionnalité au-dessus de `origin/main`. Le dernier contrôle affiche les changements de la branche par rapport à sa base actualisée.

Publier l’historique réécrit

Avant le rebase, les commits de votre branche ont déjà été publiés sur origin et la demande de fusion est en attente de vérification. Comme le rebase a remplacé leurs identifiants, un envoi ordinaire peut être refusé : l’historique distant ne correspond plus à celui de votre branche locale. --force-with-lease autorise la mise à jour forcée uniquement si la référence distante est encore celle que votre dépôt connaissait lors de la dernière récupération.

git push --force-with-lease origin feature/nouveaux-guides

La branche `feature/nouveaux-guides` sur `origin` est mise à jour avec les commits rebasés. Si une autre personne a publié de nouveaux commits entre-temps, la protection peut refuser l’envoi : récupérez alors la situation et coordonnez-vous avant toute nouvelle tentative.

Après l’envoi, vérifiez le statut et le journal, puis actualisez la demande de fusion : la plateforme doit afficher les nouveaux commits et le diff mis à jour. Prévenez les personnes qui travaillent éventuellement sur cette branche, car leur copie locale peut encore pointer vers les anciens identifiants. Dans ce projet, cette opération ne change ni index.html ni style.css ; elle remet en ordre les commits déjà consacrés à la section « Nouveaux guides » et à la correction de « La boucle du lac ».

À retenir

• Récupérez les références distantes avec `git fetch` avant de choisir la base du rebase.
• Sur votre branche de fonctionnalité, utilisez `git rebase origin/main` pour rejouer ses commits au-dessus de la branche principale actualisée.
• Contrôlez le statut, le graphe et le diff après le rebase ; traitez tout arrêt avant de publier.
• Publiez l’historique réécrit avec `git push --force-with-lease`, puis vérifiez la demande de fusion.

Dans la prochaine leçon, vous choisirez entre rebase et fusion selon le contexte du travail collaboratif.