Référence des commandes Git indispensables pour les développeurs
Du clonage au rebase en passant par le rétablissement après un force-push raté — les commandes Git que vous utilisez vraiment, avec invocations copier-coller et explications en une ligne.
D’autres utilitaires qui complètent bien ce guide :
Pourquoi c’est important
Un nouvel arrivant git push --force par erreur sur la branche principale et efface les commits d’hier. La récupération tient en trente secondes avec git reflog — à condition de savoir que ça existe. Git est exigeant en syntaxe mais riche en filets de sécurité, et beaucoup de développeurs n’utilisent que 10 % de ses possibilités faute de vocabulaire au-delà de clone, commit, push. Une antisèche classée est parmi les références les plus rentables qu’une équipe peut garder sous la main.
Trois scénarios réels
git rebase -i main puis pick / squash. La référence rappelle les verbes du rebase interactif.
Historique main propre
git bisect start good bad, marquez chaque test bon ou mauvais, Git isole le coupable.
Cause en ~log₂(n) commits
git reflog liste chaque mouvement de HEAD ; git reset --hard <reflog-id> restaure.
Crise évitée
Parcours — utiliser la référence
Ouvrez la référence des commandes Git.
Parcourir par étape du flux
Setup, commits quotidiens, gestion de branches, synchro avec les remotes, réécriture d’historique, débogage, récupération.
Chercher un verbe
Tapez « rebase », « stash » ou « cherry-pick » ; les commandes correspondantes remontent avec explications.
Copier l’invocation canonique
Chaque entrée a une ligne « ce que vous tapez vraiment » et une variante multi-ligne avec options.
Lire la note piège
Beaucoup d’entrées alertent sur la sémantique de
--force,pull --rebasevs merge par défaut, etc.Épingler les commandes fréquentes
Ajoutez en favori des catégories (ex. « réécriture d’historique ») pour les retrouver vite sous stress.
Objectif
Start a feature, save WIP, sync with main,
finish, push for PR.Commandes
git checkout -b feature/payment-retry
# work, work, work
git add . && git commit -m "WIP retry logic"
git fetch origin
git rebase origin/main
# fix any conflicts, then:
git push -u origin feature/payment-retrySymptôme
You ran `git reset --hard HEAD~5`
and now the last 5 commits seem gone.Correctif
git reflog # find the SHA before the reset
git reset --hard <SHA> # restore HEAD to it
Conseils avancés
- Préférez
git switchetgit restoreplutôt que de surchargercheckout.switchpour les branches ;restorepour les fichiers. Moins d’ambiguïté, moins d’erreurs. --first-parentdansgit logaplatis le bruit des fusions et montre l’historique de la ligne principale seulement.- Réglez
pull.rebase = truepour quegit pullrebase par défaut — fini les commits de merge « merge merge merge » sur les branches de feature. git commit --amendpour corriger le dernier commit ;git rebase -ipour les plus anciens. N’amendez pas après push sur une branche partagée.
Pièges courants
Piège courant
Le force-push efface le travail d’un collègue
Utilisez git push --force-with-lease plutôt que --force : ça échoue si le remote a bougé depuis votre dernier fetch. Gardez --force pour des branches dont vous êtes sûr d’être seul propriétaire.
Piège courant
Commit accidentel de secrets
git filter-repo (ou BFG Repo-Cleaner) réécrit l’historique pour retirer le fichier. Faites tourner le secret fuité immédiatement après.
Piège courant
`git rebase main` au lieu de `git rebase origin/main`
Vous pouvez rebaser sur un main local périmé. Faites toujours git fetch d’abord ou rebasez sur la ref explicite origin/main.
Quand ce n’est pas l’outil adapté
- Visualiser des graphes de branches — une GUI (Lazygit, GitKraken, extension Git Graph VS Code) bat largement
git log --graph. - Revue de code —
git diffmontre le diff, mais GitHub / GitLab / Gerrit gèrent commentaires et approbations. - Gros fichiers binaires — Git LFS ou
git annex, pas Git vanilla.
FAQ
Qu’est-ce qu’un fast-forward ?
Une fusion fast-forward avance le pointeur de branche le long d’une ligne de commits sans rupture — pas de commit de fusion. Courant quand la branche cible n’a pas bougé depuis le début de votre branche.
Quand utiliser `git stash` ?
Pour du WIP vraiment jetable. Pour du travail sérieux, préférez un commit wip sur une branche temporaire — les stash sont vite oubliés et perdus.
Les entrées reflog durent-elles toujours ?
Non. Elles expirent après 90 jours par défaut pour les entrées normales, 30 jours pour les inaccessibles. Ensuite seul git fsck --lost-found peut parfois récupérer.
Étapes suivantes
- Couplez Git aux utilitaires shell de la référence Linux (grep, find, awk).
- Inspectez URLs et ports distants avec l’analyseur d’URL.
- Vérifiez les codes HTTP de
git push(401, 403, 502) sur la référence des statuts HTTP.