Git est un outil que tout le monde « connaît » et que peu maîtrisent vraiment. Même après des années, certaines erreurs reviennent. En voici cinq, avec la bonne façon de s’en sortir.
1. Le git push --force qui écrase le travail des autres
Le grand classique. Vous rebasez votre branche, puis git push --force — et vous écrasez des commits que des collègues avaient poussés entre-temps.
La bonne pratique : utilisez toujours git push --force-with-lease. Cette variante refuse d’écraser si la branche distante a changé depuis votre dernier fetch. Un réflexe qui sauve des heures.
2. Committer des secrets
Une clé API, un mot de passe, un fichier .env qui finit dans l’historique. Le problème : même supprimé dans un commit suivant, le secret reste dans l’historique et reste exploitable.
La solution : un .gitignore rigoureux dès le départ, des hooks de pre-commit (comme gitleaks) et, si le mal est fait, une rotation immédiate du secret compromis — le nettoyer de l’historique ne suffit jamais.
3. Mal comprendre reset vs revert
git reset réécrit l’historique (dangereux sur une branche partagée). git revert crée un nouveau commit qui annule les changements (sûr en équipe).
Règle simple : sur une branche partagée, on revert, jamais on reset --hard.
4. Des messages de commit inutiles
« fix », « wip », « update » : ces messages ne disent rien. Six mois plus tard, ils rendent l’historique illisible et le git bisect inutile.
Adoptez une convention (par exemple Conventional Commits) : fix(auth): corrige l'expiration du token. Le coût est minime, le gain énorme sur la durée.
5. Tout faire sur une seule branche
Travailler directement sur main, ou laisser traîner des branches de plusieurs semaines qui divergent. Les conflits deviennent ingérables.
Choisissez un workflow clair (GitFlow ou, plus moderne, trunk-based development avec des branches courtes) et intégrez souvent.
Le fil rouge
La plupart de ces erreurs ne viennent pas d’un manque de connaissance des commandes, mais d’une mauvaise compréhension du modèle mental de Git : commits, références, historique. C’est exactement ce que nous travaillons dans notre formation Git & GitFlow — comprendre Git, pas seulement le réciter.