Git Rebase pour les Débutants : Une Introduction Simple

Si vous avez déjà regardé votre historique Git en pensant « c’est un vrai chaos », vous n’êtes pas seul. Ces lignes de branches emmêlées et ces commits de merge redondants rendent difficile la compréhension de ce qui a réellement changé et quand. C’est là qu’intervient git rebase—un outil puissant qui vous aide à maintenir un historique de commits propre et lisible.

Dans ce guide, vous apprendrez ce que fait le rebase, en quoi il diffère du merge, et quand l’utiliser dans votre flux de travail quotidien. Nous nous concentrerons sur des exemples pratiques que vous pouvez commencer à utiliser dès aujourd’hui, tout en soulignant les principaux pièges à éviter.

Qu’est-ce que Git Rebase ?

Pensez à git rebase comme à la réécriture de l’historique—mais dans le bon sens. Quand vous rebasez, vous prenez des commits d’une branche et les rejouez au-dessus d’une autre branche, comme si vous aviez commencé votre travail à partir d’un point différent.

Imaginez que vous écrivez une histoire. Vous commencez le chapitre 3 pendant que votre collègue édite encore le chapitre 2. Quand il termine, vous pourriez soit :

• Merger : Ajouter une note disant « modifications du chapitre 2 du collègue insérées ici »
• Rebaser : Réécrire votre chapitre 3 comme si vous l’aviez commencé après que le chapitre 2 était déjà terminé

L’approche rebase vous donne une narration plus propre sans le « bruit du merge ».

Pourquoi Utiliser Git Rebase ?

Maintenir un Historique Linéaire et Propre

Un historique linéaire se lit comme un livre—un commit suit l’autre dans une séquence claire. Cela facilite :

• Le suivi du moment où les bugs ont été introduits
• La compréhension de l’évolution des fonctionnalités
• La révision des changements de code dans les pull requests

Sans rebase, votre historique se remplit de commits de merge qui disent « Merged branch ‘main’ into feature-xyz » de manière répétée, obscurcissant le travail réellement effectué.

Quand les Développeurs Choisissent le Rebase

Les développeurs utilisent le rebase dans deux situations principales :

1. Rester à jour : Votre branche de fonctionnalité a besoin des dernières mises à jour de main
2. Peaufiner le travail : Vous voulez nettoyer les commits avant que d’autres les examinent

Ces deux scénarios aident à maintenir cet historique linéaire et propre qui facilite la vie de tout le monde.

Git Rebase vs Merge : Les Différences Clés

Voici la différence fondamentale :

Merge crée un nouveau commit qui combine deux branches :

A---B---C (main)
     \   \
      D---E---M (your-feature)

Rebase rejoue vos commits au-dessus de la branche cible :

A---B---C (main)
         \
          D'---E' (your-feature)

Notez comment rebase crée de nouveaux commits (D’ et E’) tandis que merge ajoute un commit de merge (M). Le résultat du rebase est linéaire et propre, tandis que merge préserve l’historique exact mais ajoute de la complexité.

Cas d’Usage Courants pour Git Rebase

Mettre à Jour Votre Branche de Fonctionnalité

Vous travaillez sur une fonctionnalité pendant que votre équipe pousse des mises à jour vers main. Pour incorporer leurs changements :

git checkout your-feature-branch
git rebase main

Cela rejoue vos commits au-dessus du dernier main, maintenant votre branche à jour sans commits de merge.

Nettoyer les Commits Avant une Pull Request

Avant de partager votre travail, vous pourriez vouloir organiser vos commits. Le rebase interactif vous permet de :

git rebase -i HEAD~3

Cela ouvre un éditeur où vous pouvez :

• Squasher plusieurs commits « work in progress » en un seul
• Réordonner les commits pour un flux logique
• Modifier les messages de commit pour plus de clarté

Par exemple, transformer ceci :

- Fix typo
- WIP: add login
- More login stuff
- Fix tests

En ceci :

- Add user login functionality with tests

Avertissements Importants : Quand NE PAS Rebaser

La Règle d’Or : Ne Rebasez Pas les Branches Partagées

Ne rebasez jamais les branches sur lesquelles d’autres travaillent. Quand vous rebasez, vous créez de nouveaux commits avec des hash SHA-1 différents. Si quelqu’un d’autre a les anciens commits, Git se confond et crée des commits dupliqués.

Sûr de rebaser : Votre branche de fonctionnalité locale
Ne jamais rebaser : main, develop, ou toute branche utilisée par d’autres

Comprendre les Risques du Force Push

Après un rebase, vous devrez souvent faire un force push :

git push --force-with-lease origin your-feature-branch

Le flag --force-with-lease est plus sûr que --force car il vérifie que personne d’autre n’a poussé de changements depuis votre dernier pull. Néanmoins, ne faites de force push que sur les branches que vous possédez.

Commencer avec Git Rebase

Voici un flux de travail simple pour s’entraîner :

1. Créez une branche de fonctionnalité à partir de main
2. Faites quelques commits
3. Entre-temps, main est mise à jour
4. Rebasez votre branche de fonctionnalité :

   git checkout feature-branch
   git rebase main

5. Si des conflits surviennent, résolvez-les et continuez :

   git add .
   git rebase --continue

Commencez avec vos branches locales pour prendre confiance avant de rebaser quoi que ce soit de partagé.

Conclusion

Git rebase est un outil puissant pour maintenir des historiques de commits propres et linéaires. En rejouant les commits au lieu de les merger, vous créez un historique de projet plus lisible qui profite à toute votre équipe. Rappelez-vous la règle d’or—ne rebasez que les branches que vous n’avez pas poussées ou que d’autres n’utilisent pas—et vous éviterez les pièges courants.

Commencez à vous entraîner avec vos branches de fonctionnalités dès aujourd’hui. Une fois que vous aurez expérimenté la clarté d’un historique linéaire, vous vous demanderez comment vous avez pu travailler sans.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.