Vous connaissez déjà git add, git commit et git push. Mais après plus de 10 ans d'utilisation quotidienne de Git, je peux vous dire que ce n'est pas ça qui fait la différence entre un développeur qui subit Git et un développeur qui le maîtrise. Voici plutôt les concepts, patterns et techniques qui transformeront réellement votre workflow.

Votre historique Git est une histoire, pas un journal intime

La plus grande erreur que font les développeurs : traiter Git comme un journal où on note tout ce qu'on fait, dans l'ordre chronologique.

Votre historique Git doit raconter une histoire logique, pas documenter votre tâtonnement. Quand quelqu'un lira vos commits dans 6 mois (ou vous-même), il ne veut pas voir :

• "fix typo"
• "actually fix typo"
• "WIP"
• "debugging... almost there"

Le secret : git rebase -i. Cette commande est votre meilleure alliée pour réécrire l'histoire AVANT de la partager. Vous pouvez :

• Fusionner (squash) plusieurs commits en un seul logique
• Réorganiser l'ordre des commits pour qu'ils suivent une logique
• Modifier les messages de commit
• Supprimer les commits de debug temporaires

Ne rebasez JAMAIS des commits déjà poussés sur une branche partagée par plusieurs développeurs (comme main ou develop). En revanche, sur votre branche de feature personnelle, le rebase + push --force est acceptable car vous êtes le seul à y travailler.

Le staging area n'est pas une zone d'attente

Beaucoup de développeurs font : git add . puis git commit. C'est gâcher le potentiel du staging area. Le staging area vous permet de créer des commits atomiques parfaits. Voici comment :

• git add -p : mon petit poney
• git add -p (ou --patch) vous permet d'ajouter des morceaux de fichiers, pas des fichiers entiers. Imaginez : vous avez modifié un fichier pour deux raisons différentes (fix d'un bug + nouvelle feature). Avec git add -p, vous pouvez créer deux commits séparés depuis le même fichier.

Commande bonus : git add -N fichier.js pour traquer un nouveau fichier sans l'ajouter, puis utiliser git add -p dessus.

• git commit --fixup : le workflow des poneys

Vous venez de remarquer une typo dans un commit d'il y a 3 commits ? Ne créez pas un commit "fix typo". Utilisez :

git commit --fixup=<hash-du-commit>

Puis, avant de pusher :

git rebase -i --autosquash origin/develop

Git fusionnera automatiquement votre fixup avec le commit original. Historique propre, effort minimal.

Astuce : Configurez git config --global rebase.autosquash true pour activer automatiquement --autosquash lors de vos rebase interactifs.

Les branches ne sont pas des dossiers

Un antipattern classique c’est de créer trop de branches longue durée. Les branches Git sont légères, éphémères, et doivent servir un but précis.

Le pattern feature branch + rebase

Voici le pattern que j'utilise au quotidien pour travailler :

1. Créer une branche pour UNE fonctionnalité spécifique (git checkout -b feature/ma-fonctionnalité)
2. Travailler et committer librement (même du WIP si nécessaire)
3. Pousser et créer la PR via l'interface GitHub
4. En cas de conflit ou avant le merge :
   • git pull --rebase origin/develop pour récupérer et intégrer les derniers changements
   • git rebase -i origin/develop pour nettoyer l'historique si nécessaire
   • Résoudre les conflits éventuels
   • git push --force pour mettre à jour la PR
5. Merger vers develop via l'interface GitHub une fois la PR approuvée

Pourquoi rebase avant le merge ? Cela garantit que votre branche est à jour et sans conflit. Pour l'historique linéaire, privilégier "Squash and merge" ou "Rebase and merge" sur GitHub plutôt que "Merge commit ».

Attention : N'utilisez git push --force que sur vos branches de feature personnelles. Sur une branche partagée par plusieurs développeurs, préférez git push --force-with-lease qui vérifie que personne n'a poussé entre temps.

git worktree

Besoin de travailler sur deux branches simultanément ? Au lieu de stasher/unstasher constamment, utilisez git worktree.

git worktree add ../mon-projet-feature2 feature2

Vous avez maintenant deux répertoires séparés pointant sur le même dépôt Git, mais sur des branches différentes. Changez de contexte instantanément en changeant de dossier.

Bon à savoir : Les worktrees partagent le même .git, donc tous vos commits, branches et stash sont communs entre les différents worktrees.

git reflog : votre machine à remonter le temps

Vous avez fait une bêtise comme j'en fais de temps à autre ? Ne paniquez pas car Git garde tout pendant un certain temps.

git reflog vous montre tous les mouvements de HEAD, même ceux qui ne sont plus dans l'historique. Trouvez l'état avant votre catastrophe, puis :

git reset --hard HEAD@{5}

Vous voilà revenu 5 mouvements en arrière.

Dans Git, presque rien n'est vraiment perdu car même les commits supprimés restent accessibles via reflog (par défaut 30 jours pour les refs normales, 90 jours pour les commits non référencés).

Les messages de commit sont du code

Un bon message de commit a autant de valeur que le code lui-même. Voici le format que j'utilise depuis des années, inspiré des Conventional Commits :

<type>(scope): résumé court du changement

    - Verbe à l'infinitif décrivant le changement principal
    - Verbe à l'infinitif décrivant un autre changement
    - Verbe à l'infinitif décrivant un dernier changement

Règles :

• Type : feat, fix, chore, docs, refactor, test, perf, ci, build, style
• Scope : module ou composant concerné (ex: auth, api, ui)
• Résumé : clair et concis (max 70 caractères), sans point final
• Corps : liste à puces (markdown -) avec verbes à l'infinitif
• Pas de footer ni de signature

Exemple :

feat(auth): ajouter le formulaire de connexion

    - Valider les données utilisateur avec les contraintes Symfony
    - Afficher les erreurs flash en cas d'échec de connexion
    - Rediriger vers le tableau de bord après connexion réussie

git bisect : le debugger temporel

Un bug est apparu, mais vous ne savez pas quand ? git bisect fait une recherche binaire dans l'historique pour trouver le commit coupable.

git bisect start
git bisect bad                    # Le commit actuel est mauvais
git bisect good v1.2.3            # Cette version était bonne

Git va checkout différents commits. À chaque fois, testez et dites git bisect good ou git bisect bad. Git identifiera automatiquement le commit fautif.

Automatisation : Vous pouvez même automatiser le processus avec un script de test :

git bisect run npm test

git cherry-pick : appliquer un commit spécifique

Besoin d'appliquer un commit d'une branche à une autre sans tout merger ? git cherry-pick est votre ami.

git checkout develop
git cherry-pick abc1234

Cela applique le commit abc1234 sur votre branche actuelle. Pratique pour les hotfixes qui doivent être appliqués sur plusieurs branches.

Les alias Git qui changent la vie

Ne tapez plus les mêmes commandes longues. Voici mes alias essentiels :

[alias]
st = status -sb
co = checkout
br = branch
last = log -1 HEAD --stat
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
unstage = reset HEAD --
uncommit = reset --soft HEAD~1
amend = commit --amend --no-edit
fixup = commit --fixup

git restore : la commande moderne

Depuis Git 2.23 (2019), git restore remplace git checkout pour restaurer des fichiers. C'est plus clair et moins ambiguë :

git restore fichier.js           # Annule les modifs non stagées
git restore --staged fichier.js  # Unstage un fichier
git restore --source=HEAD~2 fichier.js  # Restaure depuis un commit spécifique

git stash : au-delà du « save temporaire »

Tout le monde connaît git stash pour sauvegarder temporairement, mais très peu connaissent :

• git stash -p : stash interactif, choisissez quoi stasher
• git stash --keep-index : stash tout sauf ce qui est stagé
• git stash branch nouvelle-branche : crée une branche depuis le stash
• git stash show -p stash@{0} : voir le diff d'un stash

Donnez des noms à vos stash ! git stash push -m "WIP: nouvelle feature login" est bien plus clair que stash@{0}.

git blame : trouver le responsable (intelligemment)

git blame est utile pour savoir qui a écrit quelle ligne, mais ces options le rendent encore plus puissant :

git blame -w fichier.js          # Ignore les changements de whitespace
git blame -C fichier.js          # Détecte les copier-coller entre fichiers
git blame -L 10,20 fichier.js    # Blame uniquement les lignes 10 à 20

Le mot de la fin

La vraie maîtrise de Git ne vient pas de connaître 100 commandes obscures. Elle vient de comprendre quelques principes fondamentaux :

1. L'historique est une histoire – racontez-la bien
2. Les commits doivent être atomiques – une idée = un commit
3. Rien n'est jamais vraiment perdu – merci reflog
4. Le staging area est votre ami – utilisez-le intelligemment
5. Rebase sur vos branches, merge sur les branches partagées – chacun son usage

Ces techniques ne se maîtrisent pas en un jour. Intégrez-les progressivement dans votre workflow. Commencez par git add -p et git rebase -i. Une fois à l'aise, explorez git bisect et git worktree. Dans 6 mois, vous ne pourrez plus vous en passer.