L'opération de Rebase sur GitLab : Maintenir un historique propre
Pourquoi utiliser le Rebase ?
Dans le cadre d'un projet collaboratif, il arrive souvent que vous travailliez sur une branche pendant plusieurs jours. Pendant ce temps, la branche principale nommée main continue d'évoluer car vos collègues y ajoutent d'autres fonctionnalités ou des corrections de bugs.
Le problème est que votre branche de travail devient "décalée" par rapport à la réalité du projet. Si vous tentez de fusionner votre travail à la fin, vous risquez de rencontrer de nombreux conflits Git difficiles à gérer.
L'opération de Rebase Git permet de remettre votre travail "à jour" par rapport au main. Imaginez que vous construisez une extension à une maison. Pendant vos travaux, le propriétaire décide de repeindre toute la maison d'origine. Faire un rebase, c'est comme si vous déplaciez votre extension pour qu'elle s'appuie proprement sur la maison fraîchement repeinte plutôt que sur l'ancienne version. Cela permet de garder un historique Git linéaire et lisible.
Préparation du scénario de Rebase
Pour bien comprendre comment cela fonctionne, nous allons simuler une situation réelle où deux branches évoluent en même temps au sein de votre dépôt GitLab.
Création de la branche de test
Commencez par créer une nouvelle branche nommée rebase-example pour simuler un nouveau développement :
git switch -c rebase-example
Résultat :
Switched to a new branch 'rebase-example'
Ajout de contenu sur la branche
Créez un nouveau fichier et ajoutez du texte à l'intérieur pour simuler votre travail :
echo "Welcome to Devopssec" > rebase_file.md
git add rebase_file.md
git commit -m "Ajout du fichier de rebase sur la branche"
Changement sur la branche principale
Pendant que vous travailliez sur votre fichier, le main a reçu une mise à jour importante d'un autre membre de l'équipe.
Retour sur le main
Basculez sur la branche principale pour simuler l'évolution du projet :
git switch main
Ajout d'une modification prioritaire
Créez un autre fichier directement sur le main et validez le changement :
echo "Mise à jour importante" > master_update.md
git add master_update.md
git commit -m "Mise à jour urgente sur main"
Exécution de l'opération de Rebase
C'est ici que la magie opère. Nous allons dire à notre branche rebase-example de se placer après le dernier commit du main.
Lancer le rebase
Retournez sur votre branche de travail puis lancez la commande git rebase :
git switch rebase-example
git rebase main
Résultat :
First, rewinding head to replay your work on top of it...
Applying: Ajout du fichier de rebase sur la branche
Successfully rebased and updated refs/heads/rebase-example.
Information technique
Le Rebase réécrit l'histoire des commits. Il prend vos modifications, les met de côté, applique les nouveaux changements du main, puis repose vos modifications par-dessus. Cela donne l'impression que vous avez commencé à travailler sur la toute dernière version disponible.
Attention : Le Force Push
Si vous avez déjà envoyé votre branche sur GitLab avant le rebase, un simple git push sera refusé. Vous devrez utiliser git push --force car l'historique a été modifié.
Conclusion
L'opération de Rebase sur GitLab est un outil puissant pour maintenir un projet propre, surtout quand vous travaillez sur des fonctionnalités qui prennent du temps. Elle permet d'éviter les nœuds complexes dans l'historique de votre forge logicielle.
Toutefois, il arrive que l'on fasse trop de petits commits inutiles pendant le développement. Pour éviter de polluer le projet avec des messages comme "oubli d'une virgule", nous allons apprendre à fusionner ces commits en un seul. C'est ce qu'on appelle le Squashing de commits, et c'est le sujet du prochain chapitre.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
21 commentaires
D'ailleurs, si tu veux automatiser ça, check les hooks git pour vérifier que personne ne push sans avoir rebasé avant.
Exactement. C'est le sujet du prochain chapitre. Fais
git rebase -i mainpour voir la magie.Super article. Est-ce que le rebase interactif permet de faire du squashing en même temps ?
Si t'en as marre, tape
git rebase --abort. Ça remet ta branche exactement comme avant le rebase.J'ai une erreur
could not apply. Je fais quoi ?Visuellement oui, t'as une ligne droite. Mais en cas de gros conflits, le merge est parfois plus simple car tu gères tout en une fois.
Ça m'est arrivé d'avoir des tonnes de conflits. Le rebase est vraiment plus propre que le merge ?
Carrément. Tu peux rebaser sur n'importe quelle branche, genre
developou une branche de feature parente.Est-ce qu'on peut rebaser sur autre chose que
main?Oui, le hash change car le parent du commit change. C'est pour ça que tu dois forcer le push.
Merci pour l'article. J'ai une question : est-ce que le rebase change l'ID de mes commits ?
Ne jamais rebaser une branche publique. Ça réécrit l'histoire. Si tu bosses à plusieurs dessus, fais un
git merge main.Le rebase sur une branche partagée par 3 personnes, c'est vraiment une bonne idée ? J'ai peur de foutre le bordel.
Utilise
git reflogpour trouver le hash avant le rebase, puis fais un reset :J'ai fait une boulette avec
git rebase mainet maintenant je veux revenir en arrière. Je fais comment ?Oui, GitLab mettra à jour la MR automatiquement après ton push. Par contre tes anciens commits disparaissent au profit des nouveaux.
Sympa le flow. Ça marche aussi si j'ai déjà ouvert une Merge Request sur GitLab avant de rebaser ?
Utilise
git push --force-with-lease. Ça bloque le push si quelqu'un a poussé des modifs que t'as pas encore en local. À utiliser par défaut.J'ai testé le
git push --forceaprès un rebase et mon collègue a hurlé. C'est quoi la alternative moins risquée ?C'est normal si t'as modifié la même ligne que sur
main. Git met le rebase en pause. Règle le conflit dans ton éditeur puis :Tuto utile. Par contre, j'ai eu une erreur de conflit sur
rebase_file.mdlors du rebase, comment je m'en sors proprement sans tout casser ?