Comment fusionner vos commits avec le Squash sur GitLab

Guide sur le Squashing de commits pour transformer vos brouillons en modifications professionnelles avant la fusion sur GitLab.

Le Squashing de commits sur GitLab : Nettoyer son historique

C'est quoi le Squashing et pourquoi l'utiliser ?

Au cours du développement d'une fonctionnalité, il est normal de faire plusieurs petits enregistrements (commits). Parfois, ces commits servent juste à corriger une petite faute de frappe ou à faire un test rapide. Si vous envoyez tout cela tel quel sur la plateforme, l'historique du projet GitLab va devenir très long et difficile à lire pour vos collègues.

Le Squashing de commits (ou écrasement) est une technique qui permet de fusionner plusieurs commits en un seul. Imaginez que vous écrivez un rapport : vous faites dix brouillons avec des ratures partout. Avant de le rendre à votre responsable, vous regroupez tout en une seule version propre. Pour Git, c'est la même chose : on transforme une série de petits changements brouillons en une modification propre et professionnelle.

Préparer le terrain pour le Squash

Pour pratiquer, nous allons créer une situation où nous avons plusieurs commits inutiles à regrouper au sein de votre dépôt.

Création d'une branche de travail

Créez une branche nommée squash-chapter pour faire vos tests de fusion :

git switch -c squash-chapter

Faire plusieurs petits commits

Nous allons créer un fichier et effectuer deux modifications séparées pour simuler un historique chargé :

echo "Ligne 1" > mon_code.txt
git add mon_code.txt
git commit -m "Premier ajout"

echo "Ligne 2" >> mon_code.txt
git add mon_code.txt
git commit -m "Deuxième ajout avec une correction"

Si vous regardez votre historique avec la commande git log --oneline, vous verrez deux lignes. L'objectif est de simplifier l'historique Git pour n'en avoir plus qu'une seule.

Réaliser le Squashing avec le Rebase Interactif

Pour fusionner ces commits, nous allons utiliser une variante puissante du rebase : le mode interactif de Git.

Lancer la commande de fusion

Nous voulons regrouper les 2 derniers commits. Tapez la commande suivante dans votre terminal :

git rebase -i HEAD~2

Note technique : Le symbole ~2 indique à Git de remonter de deux crans dans l'historique. Si vous aviez 5 commits à regrouper, vous utiliseriez ~5.

Utiliser l'éditeur de texte (Vim ou Nano)

Un éditeur de texte s'ouvre alors. Vous verrez vos deux commits précédés du mot pick.

Interface de l'éditeur :

pick a1b2c3d Premier ajout
pick e4f5g6h Deuxième ajout avec une correction

# Rebase ...
# Commands:
# p, pick = use commit
# s, squash = use commit, but meld into previous commit

Pour fusionner les commits, vous devez remplacer le mot pick de la deuxième ligne par squash (ou juste la lettre s). Cela signifie littéralement : "Prends ce commit et écrase-le dans le précédent".

Sauvegardez et quittez (sur Vim, appuyez sur Echap, tapez :wq puis Entrée). Git vous demandera ensuite de rédiger un message de commit final pour l'ensemble.

Envoyer le résultat sur GitLab

Puisque vous avez réécrit l'histoire de votre branche, un simple push classique sera systématiquement refusé par le serveur.

Le push forcé (Force Push)

Si le serveur refuse l'envoi, vous devrez utiliser l'option --force. Attention, c'est une commande à utiliser avec prudence et uniquement sur vos propres branches de travail :

git push origin squash-chapter --force

Conclusion

Le Squashing est une excellente habitude à prendre avant de soumettre une Merge Request sur GitLab. Cela prouve que vous êtes un développeur organisé qui accorde de l'importance à la propreté du code source.

Maintenant que vous gérez votre code comme un pro, il est temps d'apprendre à gérer les accès. Dans le chapitre suivant, nous verrons comment ajouter des utilisateurs à un projet GitLab pour collaborer efficacement.

Espace commentaire

Écrire un commentaire

Rejoignez la discussion

Vous devez être connecté pour poster un message.

24 commentaires

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

Si vous avez d'autres galères avec le rebase, postez votre log. N'oubliez pas que l'historique est une ressource partagée, soyez propres.

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

Si, c'est pour ça qu'on privilégie git push --force-with-lease. Ça vérifie que personne n'a poussé de nouveaux commits avant de forcer. C'est beaucoup plus safe.

06/05/2026 à 09:47
patrick47
Membre
Avatar de patrick47
patrick47
Membre

Le git push --force, c'est pas risqué pour les collègues ?

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

Pas de panique, Git garde tout. Tape git reflog, trouve le hash de ton commit avant le rebase, et fais un git reset --hard [hash] pour tout récupérer.

05/05/2026 à 20:01
louis-alex
Membre
Avatar de louis-alex
louis-alex
Membre

J'ai perdu un commit en faisant une fausse manip pendant le rebase, je suis dégoûté.

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

Oui, utilise fixup au lieu de squash dans l'éditeur interactif si tu veux jeter les messages, ou reste sur squash pour les garder et les éditer.

05/05/2026 à 07:11
sebastien01
Membre
Avatar de sebastien01
sebastien01
Membre

Est-ce que je peux squasher en gardant les messages des commits fusionnés ?

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

Ça arrive si ton HEAD n'est pas bien défini ou si t'es en état de detached HEAD. Vérifie sur quelle branche tu es avec git branch.

04/05/2026 à 19:25

J'ai une erreur 'invalid upstream' quand je lance la commande. C'est quoi ce délire ?

04/05/2026 à 12:32
mpetit
Membre Actif
Avatar de mpetit
mpetit
Membre Actif

Merci pour le guide. J'ai enfin une MR propre sur GitLab, ça fait plaisir de ne plus voir mes 15 commits 'wip'.

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

À ne jamais faire si d'autres gens travaillent sur la même branche. Tu vas casser l'historique de tout le monde. Réservé aux branches de feature perso uniquement.

03/05/2026 à 23:13
julien-laurence
Membre Actif
Avatar de julien-laurence
julien-laurence
Membre Actif

Est-ce qu'on peut squasher des commits qui ont déjà été poussés sur la branche distante commune ?

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

Surtout pas. Git te donne la main pour résoudre. Une fois le fichier corrigé, fais :

git add .git rebase --continue
03/05/2026 à 09:56
franck24
Membre
Avatar de franck24
franck24
Membre

J'ai un conflit de fusion pendant mon rebase. Je fais quoi ? Je panique ?

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

Le merge --squash c'est pour l'intégration finale. Le rebase interactif, c'est pour nettoyer ton propre historique avant de montrer ton code. C'est deux usages différents.

02/05/2026 à 22:19
pierre-pelletier
Membre Actif
Avatar de pierre-pelletier
pierre-pelletier
Membre Actif

Question bête : pourquoi on ne fait pas juste un git merge --squash à la fin plutôt que de faire un rebase interactif sur la branche ?

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

Oui, utilise git reset --soft HEAD@{1} pour annuler le dernier commit tout en gardant tes modifs en staging. Tu pourras recommencer ton commit propre.

02/05/2026 à 11:21

Le squash, c'est bien, mais si je me plante dans le message de commit final, je peux revenir en arrière ?

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

C'est normal. Si ta branche est protégée, le force push est bloqué par défaut dans les réglages du projet. Va dans Paramètres > Dépôt > Branches protégées pour autoriser le force push sur ta branche.

01/05/2026 à 23:28
theophile34
Membre Actif
Avatar de theophile34
theophile34
Membre Actif

J'ai fait un git push --force mais GitLab me jette toujours. Il me dit que la branche est protégée. Une idée ?

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

Carrément. Passe cette commande dans ton terminal : git config --global core.editor nano. Plus besoin de galérer avec les modes de Vim.

01/05/2026 à 12:32
gilbert46
Membre
Avatar de gilbert46
gilbert46
Membre

Perso, Vim me rend fou. Je peux changer l'éditeur par défaut pour utiliser Nano avec le rebase ?

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

T'as sûrement mal compté. Si t'as fait 3 commits, faut taper git rebase -i HEAD~3. Vérifie toujours ton log avant avec git log --oneline.

01/05/2026 à 01:32
rmarques
Membre
Avatar de rmarques
rmarques
Membre

Tuto utile mais j'ai une erreur au moment du git rebase -i HEAD~2. Git me dit qu'il ne trouve pas de commits à éditer alors que j'en ai bien fait trois.

30/04/2026 à 18:04

Rejoindre la communauté

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

S'inscrire