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

Rejoignez la discussion

Vous devez être connecté pour poster un message.

21 commentaires

ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

D'ailleurs, si tu veux automatiser ça, check les hooks git pour vérifier que personne ne push sans avoir rebasé avant.

04/05/2026 à 14:15
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Exactement. C'est le sujet du prochain chapitre. Fais git rebase -i main pour voir la magie.

04/05/2026 à 07:28
audrey03
Membre
Avatar de audrey03
audrey03
Membre

Super article. Est-ce que le rebase interactif permet de faire du squashing en même temps ?

04/05/2026 à 01:31
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Si t'en as marre, tape git rebase --abort. Ça remet ta branche exactement comme avant le rebase.

03/05/2026 à 20:19
bguyot
Membre
Avatar de bguyot
bguyot
Membre

J'ai une erreur could not apply. Je fais quoi ?

03/05/2026 à 16:17
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

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.

03/05/2026 à 08:33

Ça m'est arrivé d'avoir des tonnes de conflits. Le rebase est vraiment plus propre que le merge ?

03/05/2026 à 04:07
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Carrément. Tu peux rebaser sur n'importe quelle branche, genre develop ou une branche de feature parente.

02/05/2026 à 21:06
zfabre
Membre Actif Secouriste
Avatar de zfabre
zfabre
Membre Actif Secouriste

Est-ce qu'on peut rebaser sur autre chose que main ?

02/05/2026 à 17:00
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Oui, le hash change car le parent du commit change. C'est pour ça que tu dois forcer le push.

02/05/2026 à 12:59
roger-paul
Membre Actif
Avatar de roger-paul
roger-paul
Membre Actif

Merci pour l'article. J'ai une question : est-ce que le rebase change l'ID de mes commits ?

02/05/2026 à 06:16
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Ne jamais rebaser une branche publique. Ça réécrit l'histoire. Si tu bosses à plusieurs dessus, fais un git merge main.

02/05/2026 à 01:06
maury-leon
Membre Rédacteur
Avatar de maury-leon
maury-leon
Membre Rédacteur

Le rebase sur une branche partagée par 3 personnes, c'est vraiment une bonne idée ? J'ai peur de foutre le bordel.

01/05/2026 à 17:52
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Utilise git reflog pour trouver le hash avant le rebase, puis fais un reset :

git reset --hard HEAD@{n}
01/05/2026 à 12:35
qcordier
Membre
Avatar de qcordier
qcordier
Membre

J'ai fait une boulette avec git rebase main et maintenant je veux revenir en arrière. Je fais comment ?

01/05/2026 à 04:44
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

Oui, GitLab mettra à jour la MR automatiquement après ton push. Par contre tes anciens commits disparaissent au profit des nouveaux.

30/04/2026 à 23:57
bgonzalez
Membre
Avatar de bgonzalez
bgonzalez
Membre

Sympa le flow. Ça marche aussi si j'ai déjà ouvert une Merge Request sur GitLab avant de rebaser ?

30/04/2026 à 19:33
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

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.

30/04/2026 à 14:55

J'ai testé le git push --force après un rebase et mon collègue a hurlé. C'est quoi la alternative moins risquée ?

30/04/2026 à 07:47
ajdaini-hatim
Auteur Rédacteur Secouriste Actif
Avatar de ajdaini-hatim
ajdaini-hatim
Auteur Rédacteur Secouriste Actif

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 :

git add rebase_file.md
git rebase --continue
30/04/2026 à 01:04
renee58
Membre
Avatar de renee58
renee58
Membre

Tuto utile. Par contre, j'ai eu une erreur de conflit sur rebase_file.md lors du rebase, comment je m'en sors proprement sans tout casser ?

29/04/2026 à 18:25

Rejoindre la communauté

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

S'inscrire