Installation
Vérifiez que Git est installé sur votre machine :
git --versionSinon, installez Git selon votre système d’exploitation.
Profitez de -40 % sur tous nos abonnements avec le code EAZY40
Jour(s)
:
Heure(s)
:
Minute(s)
:
Seconde(s)
Git rebase
TP : Git rebase vs merge pour un historique linéaire
Description
Ce TP vous guide pour utiliser git rebase afin de rejouer vos commits sur la dernière version de main, nettoyer l’historique et préparer vos Pull Requests. Vous verrez la gestion des conflits, le rebase interactif (--squash, --reword, --fixup), et comment pousser de manière sécurisée avec --force-with-lease. Vous comparerez également les différences avec git merge.
Objectifs pédagogiques
- Mettre une branche de travail à jour sur main via git rebase
- Résoudre les conflits pendant un rebase
- Utiliser le rebase interactif pour squasher et renommer des commits
- Pousser en toute sécurité après réécriture (
--force-with-lease) - Comprendre le choix entre merge et rebase dans un workflow collaboratif
Contexte
Dans un workflow de Pull Request, il est souvent préférable de garder un historique linéaire et propre. Le rebase permet de rejouer vos commits au-dessus de la dernière version de main et d’utiliser des outils comme git log pour inspecter l’historique avant publication.
Prérequis
- Dépôt Git avec une branche feature (ex.
feature/x) - Branche main à jour sur le dépôt distant (GitHub)
Étapes et commandes
A) Mettre votre branche à jour sur main
git checkout feature/xgit fetch origingit rebase origin/main- Résolution des conflits :
git status, éditez les fichiers,git add,git rebase --continue - Autres commandes utiles :
git rebase --skip,git rebase --abort - Push sécurisé après rebase :
git push --force-with-lease origin feature/x
B) Nettoyer l’historique (rebase interactif)
git rebase -i HEAD~5 pour les 5 derniers commits, puis :
- pick : conserver le commit
- squash / s : fusionner avec le précédent
- fixup / f : fusionner sans message
- reword / r : modifier le message
- edit / e : modifier le contenu du commit
Finalisez avec git add, git commit --amend, puis git rebase --continue.
C) Workflow autosquash
Créer un commit correctif : git commit --fixup <SHA> et lancer git rebase -i --autosquash origin/main pour ranger automatiquement les commits fixup! ou squash!.
D) Comparatif rapide : merge vs rebase
- merge : ajoute un commit de merge, historique non réécrit, simple à partager
- rebase : historique linéaire, propre, à éviter sur branches partagées sans coordination
Dépannage rapide
- Abandonner le rebase :
git rebase --abort - Conflits répétés : rebase par petits lots (
HEAD~3) - Refus de push après rebase :
git push --force-with-lease - Rebase sur mauvaise base :
git rebase origin/main
Résumé
Le rebase permet de mettre à jour votre branche sur main, résoudre les conflits, puis pousser avec --force-with-lease. Le rebase interactif aide à squasher et renommer les commits pour un historique propre. Préférez merge si la branche est déjà partagée et que vous ne pouvez pas réécrire l’historique.
4 Commentaires
Poster le commentaire
Vous devez vous connecter pour publier un commentaire.
Il y a quelque chose que je ne comprend pas :
– j’ai essayé de faire un merge de feature1 depuis feature2, puis de merge feature2 vers master et je vois bien le commit de feature1 contrairement à ce qui est dit dans la vidéo. Par contre, ça m’a créé un nouveau commit « Merge branch ‘feature1’ into ‘feature2′ » en plus dans l’historique final.
– et deuxièmement, pourquoi ne pas faire un git rebase de feature2 depuis master si ça garde un historique propre ? J’ai l’impression qu’il y a une histoire de « fast-forward » mais je ne comprends pas car votre historique semble propre même avec un merge …
hello
pour repondre à tes questions:
1- en fait le merge normal crée un commit automatiquement de l’ensemble des modifications ce qui devrait faire perdre l’historique des modifications
2- attention, le merge ne garde pas mon historique mais crée un merge pour toutes mes modificaitons, en réalité quand je fais le base pour que les commit de ma branches features soient exactement repris à identique (comme sur la branche feature 2) afin de savoir exactement ce qui s’est passé.
En réalité le merge cache les commits faits sur le branche feature, dans certains cas c’est souhaitable mais dans d’autres cas on souhaite avoir l’historique.
Regardes un peu cette PR : https://github.com/diranetafen/cursus-devops/pull/12
Tu verras que la seule chose que s’a m’affiche c’est que le commit c’est la résultante d’un merge alors que plein de commits ont été fait par le contributeur qui ici est sami.
Donc si j’avais voulu garder l’historique des ces modifications j’aurai fait un rebase mais dans mon cas comme je suis le mainteneur du code je m’en fou un peu et c’est le resultat final qui m’intéresse
N’hésites pas si je n’ai pas été clair, merci pour tes questions
En fait, ce que je comprend pas c’est que dans la vidéo vous dites que si on « merge » la branche « feature1 » dans « feature2 », alors le commit « add mobile phone in form » ne sera plus dans l’historique.
-> Hors si je fais ce merge, je vois toujours ce commit « add mobile phone in form » dans mon historique suivi de mon commit de merge…
-> Pourquoi ? il ne devrait pas y avoir que le commit de merge ?
Du coup, je suis encore plus perdu entre git merge, git merge (avec fast-forward) et rebase.
En fait on utilise que le merge et des fois le rebase
vous avez une bonne doc ici qui explique le mécanisme
https://www.google.com/url?sa=i&url=https%3A%2F%2Ffr.sawakinome.com%2Farticles%2Fsoftware%2Funassigned-2334.html&psig=AOvVaw0oGtZ1xqRREfYyJz6zF5nV&ust=1594853811138000&source=images&cd=vfe&ved=0CA0QjhxqFwoTCLCyzobtzeoCFQAAAAAdAAAAABAb