Maîtriser l'opération de Rebase sur GitLab pour un historique linéaire

Apprenez à utiliser le Rebase Git pour mettre à jour vos branches et maintenir un historique de commit GitLab propre.

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

Vous devez être connecté pour poster un message !

3 commentaires

16/05/26

Oui, mais attention au piège du Force Push. Si ton équipe n'est pas habituée au fait que `rebase` réécrit l'histoire, ça va créer un champ de bataille de comms. Préférez un merge avec un squash des derniers commits si le contexte n'est pas 100% Git-savvy.

16/05/26

L'analogie de la maison repeinte est parfaite, ça démystifie bien le concept pour les juniors. Le point sur `git rebase main` est le nerf de la guerre. Par contre, faut bien rappeler que si on oublie de faire un `git checkout --ours` ou `git checkout --theirs` au bon moment, ça peut partir en vrille vite fait.

16/05/26

J'ai l'habitude d'utiliser `git pull --rebase` par défaut dans mon workflow CI. C'est beaucoup plus propre que le `git merge` par défaut, moins de merge commits inutiles.

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire