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.

3 commentaires

zacharie17
Membre
Avatar de zacharie17
zacharie17
Membre

Le 'rapport' analogie est trop douce. En dev, on ne parle pas de brouillons, on parle de commits atomiques. Le but du squash, c'est d'éliminer le bruit des 'fix typo' ou 'wip' qui polluent l'audit trail, point.

16/05/26 à 15:01

Rebase interactif, c'est la vraie clé. On se retrouve souvent à devoir faire un `squash` des 5 derniers commits quand on a travaillé en solo et que le branch était une zone de chaos.

16/05/26 à 15:01
guyon-gregoire
Membre actif
Avatar de guyon-gregoire
guyon-gregoire
Membre actif

J'ai fait un oubli majeur : le message de commit final. Si tu squashe 10 commits et que tu laisses un message du type

16/05/26 à 15:01

Rejoindre la communauté

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

S'inscrire