Git : passer au niveau supérieur

Une fois qu'on maîtrise le cycle add / commit / push, la première vraie décision d'équipe n'est pas technique mais organisationnelle : comment structure-t-on les branches ?. Ce choix, qu'on appelle un workflow, conditionne tout le reste — la façon de collaborer, de livrer, de corriger un bug urgent. Il n'existe pas de workflow universellement meilleur : chacun est un compromis adapté à un contexte, et savoir lequel choisir fait partie de la maturité d'un·e dev.

Trois grandes familles dominent. Git Flow est le plus structuré, avec ses branches main, develop, release/* et hotfix/* : adapté aux logiciels livrés par versions (mobile, desktop, secteurs réglementés), il est en revanche lourd pour du web à déploiement fréquent. GitHub Flow est minimaliste : une seule branche longue, main, et des branches de fonctionnalité courtes fusionnées via pull request puis déployées en continu. Trunk-Based Development pousse la logique à l'extrême : tout le monde intègre très souvent sur main, en masquant le code inachevé derrière des feature flags.

Pour trancher, pose-toi quelques questions concrètes : quelle est la taille de l'équipe, à quelle fréquence déploies-tu, es-tu soumis·e à des contraintes réglementaires, et surtout, ta CI/CD est-elle assez solide ? Le trunk-based, par exemple, exige une chaîne de tests automatisés irréprochable pour être viable. Pour l'immense majorité des équipes web qui déploient plusieurs fois par jour, GitHub Flow est le bon point de départ : simple, parfaitement compatible avec pull requests, CI et déploiement automatique. Dans tous les cas, adopte une convention de nommage de branches qui exprime l'intention (feat/, fix/, hotfix/, refactor/) pour que l'historique se lise d'un coup d'œil.

Les 3 workflows principaux

• Git Flow : main, develop, release/*, hotfix/*, feature/*. Adapté aux releases versionnées (mobile, desktop, banking)
• GitHub Flow : une seule branche longue main, feature branches courtes, déploiement continu
• Trunk-Based Development : tout le monde commit fréquemment sur main, feature flags pour le code en cours, release every commit

Critères de choix

• Taille de l'équipe
• Fréquence des déploiements (par jour ? par mois ?)
• Contraintes réglementaires (banking, santé : Git Flow souvent imposé)
• Maturité de la CI/CD (le trunk-based exige une CI solide)

Conventions de nommage

git switch -c feat/auth-oauth          # nouvelle fonctionnalité
git switch -c fix/null-on-signup       # correction de bug
git switch -c chore/upgrade-deps       # tâche annexe (upgrade, doc)
git switch -c hotfix/payment-broken    # correction critique de prod
git switch -c refactor/extract-auth    # refactor sans changement de comportement

Le débat rebase contre merge est celui qui distingue le plus nettement les utilisateur·ices basiques de Git des autres. Les deux commandes réunissent le travail de deux branches, mais elles racontent l'histoire différemment. Merge préserve l'historique réel : les deux branches restent visibles et un commit de fusion matérialise leur point de rencontre. C'est honnête et fidèle à ce qui s'est passé, au prix d'un historique parfois touffu quand les fusions se multiplient.

Rebase, à l'inverse, rejoue tes commits au sommet de la branche cible, comme si tu avais codé après coup, sur une base à jour. Le résultat est un historique linéaire, bien plus agréable à lire. Mais il faut comprendre ce qui se passe réellement : rebaser ne déplace pas les commits, il en crée de nouveaux, avec de nouvelles empreintes SHA. Autrement dit, le rebase réécrit l'histoire. C'est puissant et propre, mais ça a une conséquence directe sur la sécurité du travail collectif.

D'où la règle d'or à ne jamais transgresser : on ne rebase jamais une branche partagée publiquement. Si tu rebases main alors que des collègues sont basés dessus, leurs historiques divergent du tien et la synchronisation devient un cauchemar. Le bon usage est donc : rebase tes branches de fonctionnalité privées pour les garder propres et à jour, mais jamais après qu'elles aient été tirées par d'autres. En pratique, beaucoup d'équipes évitent complètement le dilemme grâce au bouton Squash and merge de GitHub, qui condense tous tes commits en un seul, propre, sur main — le meilleur des deux mondes sans rebase manuel.

Merge : préserver l'historique

git merge garde l'historique réel : les deux branches restent visibles, un commit de merge matérialise leur réunion. Honnête, lisible si l'équipe est petite.

Rebase : linéariser l'historique

git rebase rejoue tes commits au sommet de la branche cible. Le résultat est un historique linéaire, comme si tu avais codé après l'autre. Plus propre à lire, mais réécrit l'histoire.

# Récupérer les derniers changements de main et rebaser ma feature dessus
git fetch origin
git rebase origin/main

# En cas de conflit
# 1) Résoudre les conflits dans les fichiers
git add fichier-resolu.ts
git rebase --continue

# Pour abandonner et revenir à l'état initial
git rebase --abort

Squash and merge sur GitHub

Le bouton Squash and merge sur GitHub combine les deux : il squashe tous tes commits de feature en un seul, puis le merge sur main. Historique main propre (un commit par PR), pas besoin de rebase manuel.

Pendant que tu développes, ton historique se remplit de commits en désordre : un « wip », une correction de typo, un « fix lint », des messages écrits à la va-vite. C'est parfaitement normal — on ne code pas d'un seul jet parfait. Mais avant de soumettre ton travail en revue, tu peux nettoyer cet historique pour qu'il raconte une histoire claire. C'est le rôle du rebase interactif : il te laisse réorganiser, fusionner, renommer ou supprimer tes commits avant de les partager. Un·e reviewer préférera toujours relire deux commits propres que douze commits brouillons.

Concrètement, git rebase -i ouvre un éditeur listant tes commits, chacun précédé d'une commande que tu peux changer. pick garde le commit tel quel. reword modifie son message. squash le fusionne avec le précédent en conservant les deux messages, tandis que fixup le fusionne en jetant son message (idéal pour absorber une correction de typo). drop le supprime, et edit met le rebase en pause pour retoucher le commit. Tu peux même réordonner les lignes : Git applique les commits dans l'ordre que tu choisis.

Un combo rend ce nettoyage quasi automatique. Au moment où tu repères une coquille dans un commit passé, fais git commit --fixup=<sha> : Git crée un commit spécial marqué fixup!. Puis, à la fin, git rebase -i --autosquash replace tout seul chaque fixup juste après son commit cible — tu n'as plus qu'à valider. Attention en revanche : puisque tu as réécrit l'historique, un git push normal sera refusé. Utilise git push --force-with-lease, et surtout pas --force : la variante with-lease refuse de pousser si quelqu'un a poussé entre-temps, ce qui protège le travail des autres.

Lancer un rebase interactif

# Sur les 5 derniers commits
git rebase -i HEAD~5

# Ou jusqu'à la branche main
git rebase -i main

Git ouvre un éditeur avec la liste des commits, et tu peux changer la commande devant chacun :

• pick : garder le commit tel quel
• reword : modifier le message (le contenu reste)
• squash (ou s) : fusionner avec le commit précédent, garder les messages
• fixup (ou f) : fusionner avec le précédent, jeter le message (le plus courant)
• drop (ou d) : supprimer le commit
• edit : s'arrêter sur le commit pour le modifier

Le combo magique : --fixup + --autosquash

# Tu fais ton commit normal
git commit -m "feat: ajout du formulaire de login"

# Tu vois un typo plus tard, tu corriges et tu fais un fixup
git add .
git commit --fixup=<sha-du-commit-cible>

# Ton historique : ...[feat: login]...[fixup! feat: login]...
# Lance interactive rebase avec --autosquash
git rebase -i --autosquash main

# Git positionne automatiquement le fixup au bon endroit. Tu valides.

Ce chapitre regroupe trois outils qui, ensemble, te donnent une aisance nouvelle avec Git : déplacer un commit précis, mettre du travail de côté, et récupérer ce qu'on croyait perdu. Le premier, cherry-pick, applique un commit donné sur ta branche courante, où qu'il vienne. Le cas typique : tu as corrigé un bug urgent sur main, et tu veux exactement ce correctif — ni plus, ni moins — sur une branche de release en cours. L'option -x ajoute au message une référence au commit d'origine, précieuse pour tracer d'où vient un correctif reporté sur plusieurs branches.

Le deuxième, stash, répond à une situation quotidienne : tu es en plein travail non commité et tu dois changer de branche en urgence. git stash met tes modifications de côté dans une pile, te rend un espace de travail propre, et te permet de les réappliquer plus tard avec git stash pop. Tu peux nommer tes stashes, en garder plusieurs, et inclure les fichiers non suivis avec l'option -u. C'est un tiroir temporaire, pratique pour les interruptions — même si, pour un contexte durable comme un hotfix, les worktrees du dernier chapitre sont souvent préférables.

Le troisième est le plus rassurant de tous : le reflog. Beaucoup de débutant·es croient qu'un git reset --hard malheureux détruit définitivement leur travail. C'est presque toujours faux. git reflog est le journal de toutes les positions par lesquelles ta référence HEAD est passée : chaque commit, reset, rebase y laisse une trace, conservée environ trente jours. Il te suffit d'y repérer la position d'avant l'accident et d'y revenir avec git reset --hard HEAD@{n}, ou d'en faire une nouvelle branche. Retiens la formule qui sauve : quand tu paniques, lance git reflog. Le scénario ci-dessous te fait justement dérouler ce sauvetage après un rebase raté.

Cherry-pick : appliquer un commit ailleurs

# Récupérer un commit précis d'une autre branche
git cherry-pick abc1234

# Avec une référence au commit original dans le message (recommandé)
git cherry-pick -x abc1234

# Cherry-pick d'une plage de commits
git cherry-pick abc1234..def5678

Cas typique : tu as fait un hotfix sur main, tu veux l'appliquer aussi sur une branche release en cours.

Stash : mettre du travail de côté

# Tu as des modifs non commitées et tu dois changer de branche d'urgence
git stash push -m "wip: refacto navigation"

# Plus tard, retour à ton travail
git stash list                 # voir tous les stashes
git stash pop                  # appliquer le plus récent et le supprimer du stash
git stash apply stash@{1}      # appliquer un stash précis sans le supprimer
git stash drop stash@{1}       # supprimer un stash

# Inclure les fichiers non suivis (untracked)
git stash push -u -m "wip avec nouveaux fichiers"

Reflog : ton filet de sécurité

git reflog est le journal de toutes les positions de HEAD. Même un git reset --hard ne supprime pas vraiment tes commits : ils restent retrouvables via reflog pendant ~30 jours.

# Voir tous les déplacements de HEAD
git reflog

# Output exemple :
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: feat: ajout du dashboard
# ...

# Récupérer un commit "perdu"
git reset --hard HEAD@{1}      # revient à la position d'avant le reset

# Ou créer une branche à partir de ce commit
git switch -c recup HEAD@{1}

Deux besoins reviennent dès qu'un projet vit dans la durée : marquer des versions officielles, et retrouver le commit qui a introduit un bug. Pour le premier, Git propose les tags, des étiquettes posées sur un commit précis. Il en existe deux sortes : le tag léger, simple pointeur, et le tag annoté (git tag -a), qui enregistre en plus l'auteur, la date et un message. Pour une release, on utilise toujours un tag annoté : il documente qui a publié quoi et quand. Détail à ne pas oublier : les tags ne partent pas avec un git push classique, il faut les pousser explicitement.

Les versions se nomment le plus souvent selon la convention SemVer (MAJOR.MINOR.PATCH) : on incrémente le patch pour une correction, le minor pour un ajout compatible, le major pour un changement cassant. Cette grammaire simple communique instantanément la nature d'une mise à jour à qui l'installe, et des outils comme semantic-release peuvent l'automatiser à partir de messages de commit structurés. Bien versionner, ce n'est pas de la bureaucratie : c'est un contrat de confiance avec celles et ceux qui dépendent de ton logiciel.

Pour le second besoin — traquer une régression — Git offre une arme redoutable : git bisect. Le principe est une recherche dichotomique : tu indiques un commit où tout marchait (good) et un où c'est cassé (bad), et Git te propose le commit du milieu à tester. Selon ta réponse, il élimine la moitié restante et recommence, convergeant en quelques étapes même sur des milliers de commits. Encore mieux, git bisect run automatise entièrement le processus : tu lui donnes un script de test (par exemple npm test), et Git enchaîne seul les essais jusqu'à désigner le commit fautif. Là où une recherche manuelle prendrait des heures, bisect règle l'affaire en minutes.

Tags annotés vs légers

• Tag léger : juste un nom qui pointe sur un commit. git tag v1.0.0
• Tag annoté : avec auteur, date, message. Recommandé pour les releases. git tag -a v1.0.0 -m "release initiale"

# Créer un tag annoté
git tag -a v1.4.0 -m "release auth oauth"

# Pousser les tags (pas inclus dans un push classique)
git push origin v1.4.0
git push origin --tags    # tous les tags

# Décrire un commit par rapport au dernier tag
git describe              # "v1.4.0-12-gabc1234"
                          # = 12 commits après v1.4.0, sha=abc1234

Bisect : recherche dichotomique du commit fautif

Une régression apparaît, mais entre quel commit ? git bisect fait une recherche dichotomique : tu marques un commit qui marchait et un qui casse, Git te propose le milieu, tu testes, tu réponds good ou bad, et il converge.

git bisect start
git bisect bad                     # le commit actuel a un bug
git bisect good v1.3.0             # à v1.3.0 ça marchait

# Git checkout un commit au milieu
# Tu testes ton app
# Puis tu réponds :
git bisect bad                     # ou good selon le résultat

# Quand tu trouves : Git affiche le commit fautif
git bisect reset                   # revenir à la position de départ

git bisect start HEAD v1.3.0
git bisect run npm test
# Git enchaîne automatiquement les checkouts et les tests
# jusqu'à trouver le commit qui casse les tests

Les meilleures équipes ne comptent pas sur la discipline individuelle pour maintenir la qualité : elles l'automatisent au plus près du développeur. Les hooks Git sont des scripts que Git exécute automatiquement à des moments clés du cycle de vie d'un commit. Les trois plus utiles côté client : pre-commit, qui se déclenche avant la création du commit (idéal pour lancer le lint et formater le code), commit-msg, qui valide le format du message (par exemple imposer les Conventional Commits), et pre-push, qui vérifie une dernière fois avant l'envoi.

Point important : on ne touche pas au dossier .git/hooks/ à la main. Ce dossier n'est pas versionné, donc tes hooks ne suivraient pas le dépôt et tes collègues ne les auraient pas. On passe par des outils dédiés — Husky et lint-staged dans l'écosystème Node, lefthook en multi-langage — qui versionnent la configuration des hooks dans le projet et les installent automatiquement à l'npm install. Combiné à lint-staged, qui n'analyse que les fichiers réellement modifiés, tu obtiens un pre-commit rapide qui empêche le code mal formé d'entrer, pour toute l'équipe, sans effort de chacun.

Deux autres leviers polissent ton confort au quotidien. Les alias raccourcissent les commandes que tu tapes cent fois : git lg pour un joli graphe d'historique, git unstage pour retirer un fichier du staging, git amend pour amender sans rouvrir l'éditeur. Et quelques réglages globaux bien choisis changent le comportement par défaut de Git : pull.rebase true pour un historique linéaire, rerere.enabled true pour que Git mémorise comment tu as résolu un conflit et le rejoue automatiquement s'il réapparaît. Ces petits ajustements, posés une fois, te suivent sur tous tes projets et font gagner un temps considérable.

Hooks client

• pre-commit : lance avant la création du commit (lint, tests rapides)
• commit-msg : valide le format du message (Conventional Commits)
• pre-push : avant un push (tests complets, vérifications)

En pratique, on ne touche pas .git/hooks/ à la main. On utilise des outils : Husky (Node), lefthook (multi-langage), pre-commit (Python). Ces outils versionnent les hooks dans le repo et les installent à npm install.

// package.json
{
  "scripts": {
    "prepare": "husky"
  },
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"]
  }
}

// .husky/pre-commit
npx lint-staged

Aliases Git utiles

git config --global alias.co "checkout"
git config --global alias.sw "switch"
git config --global alias.br "branch"
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global alias.unstage "reset HEAD --"
git config --global alias.last "log -1 HEAD"
git config --global alias.amend "commit --amend --no-edit"

Configs à mettre en place

# Pull rebase par défaut (historique linéaire)
git config --global pull.rebase true

# Mémoriser la résolution de conflits
git config --global rerere.enabled true

# Push uniquement la branche courante
git config --global push.default current

# Couleur partout
git config --global color.ui auto

Par défaut, l'auteur d'un commit repose sur le nom et l'email configurés localement — des informations que n'importe qui peut mettre aux tiennes. Rien n'empêche donc quelqu'un de fabriquer un commit qui semble venir de toi. La signature de commits résout ce problème en apposant une preuve cryptographique que c'est bien toi. C'est particulièrement important dans l'open source, où l'on ne connaît pas les contributeur·ices, et dans les équipes qui protègent leurs branches critiques.

La méthode la plus simple aujourd'hui est la signature SSH (disponible depuis Git 2.34) : tu réutilises la clé SSH que tu as déjà pour te connecter à GitHub, sans rien installer de plus. Il suffit de configurer Git pour signer avec cette clé, puis d'ajouter la clé publique sur GitHub en tant que Signing key (et non Authentication key). Une fois en place, tu peux activer la signature automatique de tous tes commits, et GitHub affichera le badge Verified à côté des tiens. L'ancienne méthode par GPG reste valide, mais impose d'installer et de gérer des clés GPG dédiées — plus de friction pour le même résultat.

La signature prend tout son sens couplée aux branches protégées. Dans les réglages GitHub, tu peux exiger que tous les commits fusionnés sur main soient signés et vérifiés. Combinée à l'obligation de passer par une pull request relue et à une CI verte, cette règle offre une garantie forte sur ce qui entre en production : chaque changement est authentifié, revu et testé. C'est le genre de dispositif attendu sur les projets sensibles, et un excellent argument à mettre en avant si tu prépares un titre professionnel ou un entretien.

Signature SSH (Git 2.34+, le plus simple)

Tu réutilises la clé SSH que tu as déjà pour GitHub. Pas de GPG à installer.

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Signer un commit
git commit -S -m "feat: secure login"

# Vérifier
git log --show-signature

Pour que GitHub affiche le badge Verified, ajoute ta clé SSH comme Signing key dans Settings → SSH and GPG keys → New SSH key (en mode Signing key, pas Authentication key).

Signature GPG (historique)

Méthode plus ancienne, mais toujours valide. Demande d'installer GPG, de générer une clé GPG, et de l'uploader sur GitHub. Plus de friction, mais standard de l'open source historique.

Voici une situation que tu vivras souvent : tu es en plein milieu d'une grosse fonctionnalité, avec des fichiers modifiés partout, et un hotfix urgent tombe sur main. La méthode classique impose une gymnastique pénible : stasher ton travail, changer de branche, coder le correctif, revenir, dépiler le stash — en espérant ne rien casser au passage. Les worktrees offrent une bien meilleure réponse : ils te permettent d'avoir plusieurs branches ouvertes simultanément, chacune dans son propre dossier.

Un worktree est un dossier supplémentaire qui partage le même dépôt .git que ton dossier principal. Concrètement, git worktree add ../mon-app-hotfix hotfix/paiement crée un second dossier positionné sur la branche du hotfix, à côté de ton travail en cours. Tu t'y déplaces, tu corriges, tu commites, tu pousses — sans jamais toucher à ta fonctionnalité en chantier, qui t'attend intacte dans l'autre dossier. Une fois le hotfix fusionné, git worktree remove nettoie tout. Une seule contrainte logique : une même branche ne peut être active que dans un seul worktree à la fois, pour éviter les conflits internes.

Au-delà du hotfix, les worktrees brillent dès qu'il faut travailler sur deux états du code en parallèle : reproduire un bug signalé sur une vieille version taguée pendant que tu développes la suivante, comparer deux implémentations, ou lancer une longue suite de tests sur une branche pendant que tu continues sur une autre. C'est l'outil qui remplace avantageusement le va-et-vient de stashes pour tout contexte qui dure plus de quelques minutes. Avec les workflows du premier chapitre, le rebase interactif, le reflog comme filet et les worktrees pour le parallélisme, tu disposes désormais de tout ce qui fait passer Git de « je m'en sors » à « je maîtrise ».

Le concept

Un worktree est un dossier supplémentaire qui partage le même .git. Tu peux avoir 2 versions du repo en parallèle, sur 2 branches différentes, sans cloner deux fois ni stasher.

# Tu es dans ~/projets/mon-app sur la branche feat/dashboard
# Hotfix urgent demandé sur main

# Crée un nouveau worktree pour le hotfix
git worktree add ../mon-app-hotfix hotfix/payment-broken

# Bascule dans le dossier
cd ../mon-app-hotfix

# Tu codes, tu commits, tu pushes
git add . && git commit -m "fix: payment provider URL"
git push -u origin hotfix/payment-broken

# Une fois le hotfix mergé : supprimer le worktree
cd ../mon-app
git worktree remove ../mon-app-hotfix

# Lister les worktrees
git worktree list

# Nettoyer les worktrees obsolètes
git worktree prune

Les worktrees servent aussi à tester un bug rapporté sur une vieille version sans toucher à ton travail courant. Tu sors un worktree sur le tag v1.2.0, tu reproduis, tu fermes.