Module 1 — Git avancé : rebase, stash, cherry-pick, fusion

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 10 minutes

---

Le dépôt de démonstration

Toutes les commandes de ce module ont été exécutées sur un vrai dépôt Git local, construit pour l’occasion : un commit initial, puis une branche feature/panier avec deux commits.

$ git log --oneline
b6a13ee Ajoute version.txt
7caca36 Premier commit

$ git checkout -b feature/panier
$ git commit -m "Ajoute la logique du panier"
$ git commit -m "Corrige un bug du panier"

$ git log --oneline
975fe22 Corrige un bug du panier
641571e Ajoute la logique du panier
b6a13ee Ajoute version.txt
7caca36 Premier commit

Rebase : réécrire l’historique pour qu’il paraisse linéaire

git rebase rejoue les commits d’une branche par-dessus une autre, au lieu de créer un commit de fusion. Sur ce dépôt, master n’avait pas bougé depuis la création de feature/panier — le rebase est donc un cas trivial (« fast-forward ») :

$ git checkout -b feature/panier-rebase feature/panier
$ git rebase master
Current branch feature/panier-rebase is up to date.

Pourquoi rebaser plutôt que fusionner ? Un rebase produit un historique linéaire, sans commit de fusion parasite — utile pour une branche de fonctionnalité personnelle avant de l’intégrer. La règle qu’on ne casse jamais : ne rebasez pas une branche que d’autres personnes ont déjà récupérée — un rebase réécrit les hachages de commit, ce qui casse l’historique de quiconque a déjà basé du travail dessus.

Tag annoté : marquer une version

$ git tag -a v1.0.0 -m "Première version stable"
$ git tag -n
v1.0.0          Première version stable

Un tag annoté (-a) stocke un message, l’auteur et la date du tag lui-même — contrairement à un tag léger (juste un pointeur), c’est la forme recommandée pour marquer une version publiée, exactement ce qu’utilisent les workflows de release de GitHub Actions vus dans le cours CI/CD.

Stash : mettre du travail de côté sans committer

$ echo "travail en cours" >> panier.txt
$ git status --short
 M panier.txt

$ git stash push -m "wip: ajustement panier"
Saved working directory and index state On feature/panier-rebase: wip: ajustement panier
$ git status --short
(rien — l'arbre de travail est propre)

$ git stash list
stash@{0}: On feature/panier-rebase: wip: ajustement panier

$ git stash pop
Dropped refs/stash@{0}
$ git status --short
 M panier.txt

stash range les modifications en cours dans une pile, sans les committer — utile pour changer de branche rapidement (par exemple pour corriger un bug urgent) sans perdre un travail inachevé, puis le récupérer (pop) une fois revenu sur la bonne branche.

Cherry-pick : récupérer un seul commit d’une autre branche

Cas d’usage réel : master a besoin d’un correctif présent sur feature/panier, sans vouloir intégrer toute la branche.

$ git log master..feature/panier --oneline
975fe22 Corrige un bug du panier
641571e Ajoute la logique du panier

$ git cherry-pick 641571e
[master 4ed855c] Ajoute la logique du panier
 1 file changed, 1 insertion(+)
 create mode 100644 panier.txt

$ git log --oneline
4ed855c Ajoute la logique du panier
b6a13ee Ajoute version.txt
7caca36 Premier commit

git log master..feature/panier liste précisément les commits présents sur feature/panier mais absents de master — la façon fiable d’identifier quoi cherry-picker, plutôt que de deviner un hachage de commit à l’œil.

Fusion (merge --no-ff) : préserver la trace de la branche

$ git merge --no-ff -m "Fusionne feature/panier dans master" feature/panier

$ git log --oneline --graph --all
*   d2ec0e8 Fusionne feature/panier dans master
|\
| * 975fe22 Corrige un bug du panier
| * 641571e Ajoute la logique du panier
|/
* b6a13ee Ajoute version.txt
* 7caca36 Premier commit

--no-ff force la création d’un commit de fusion même quand un fast-forward serait possible — le graphe garde une trace visible que ce travail a existé sur sa propre branche, utile pour retrouver plus tard « tout ce qui appartenait à telle fonctionnalité ».

Rebase vs Merge : quand utiliser lequel

Situation	Recommandation
Branche de fonctionnalité personnelle, pas encore partagée	rebase avant de fusionner : historique propre
Branche déjà poussée et récupérée par d’autres	merge uniquement : ne jamais réécrire un historique partagé
Besoin de retrouver facilement « tout ce qui appartient à telle fonctionnalité »	merge --no-ff : préserve la structure de la branche
Un seul correctif à porter sur une autre branche, sans tout fusionner	cherry-pick

Prochaine étape

Module 2 : GitHub, GitLab et Bitbucket — CI native, webhooks et API