Les erreurs Git que font encore les développeurs seniors

Git est un outil que tout le monde utilise et que peu maîtrisent vraiment. Voici les erreurs qui persistent même chez des développeurs avec plusieurs années d’expérience.

1. Réécrire l’historique sur des branches partagées

git rebase et git commit --amend réécrivent l’historique. Utilisés sur une branche locale, c’est parfait. Utilisés sur une branche que d’autres ont déjà clonée — main, develop, ou une feature branch partagée — c’est un désastre.

# ❌ Jamais sur une branche partagée
git push --force origin main

# ✅ Force push uniquement sur ses propres branches de travail
git push --force-with-lease origin feature/my-branch
# --force-with-lease refuse si quelqu'un a pushé entre temps

La règle : ne jamais réécrire l’historique d’un commit qui a déjà été poussé et que d’autres pourraient avoir récupéré.

2. Commits trop gros ou trop petits

Un commit de 2000 lignes qui touche au frontend, au backend, à la DB et à la configuration est quasi inutile pour un git bisect ou une review.

À l’opposé, un commit par ligne modifiée rend l’historique illisible.

# Commiter par unité logique, pas par session de travail
git add src/api/orders.py
git commit -m "feat(orders): add pagination to order listing"

git add src/api/users.py
git commit -m "fix(users): prevent duplicate email on registration"

# git add -p pour commiter parties d'un fichier
git add -p src/api/orders.py  # choisir interactivement les hunks à commiter

3. Messages de commit vagues

# ❌ Messages inutiles
git commit -m "fix"
git commit -m "wip"
git commit -m "changements"
git commit -m "update"

# ✅ Convention Conventional Commits
git commit -m "feat(auth): add JWT token refresh endpoint"
git commit -m "fix(orders): prevent negative quantities in cart"
git commit -m "refactor(db): extract connection pooling to module"
git commit -m "docs(api): add OpenAPI spec for /orders endpoint"

Un bon message de commit répond à la question : “Pourquoi ce changement ?” — pas “Qu’est-ce qui a changé ?” (le diff le dit déjà).

4. .gitignore incomplet ou mal placé

# .gitignore à la racine du repo
node_modules/
*.env
*.env.local
dist/
build/
.DS_Store
*.log
coverage/
.idea/
.vscode/
__pycache__/
*.pyc

# Pour les secrets déjà commités par erreur (URGENT)
git rm -r --cached .env           # retirer du tracking sans supprimer
git commit -m "remove .env from tracking"
# ⚠️ L'historique contient encore le secret — changer la valeur immédiatement

5. Ne jamais utiliser git bisect

git bisect est l’une des fonctionnalités les plus puissantes de Git et la moins utilisée. Elle permet de trouver le commit qui a introduit un bug par dichotomie.

# Trouver le commit qui a cassé les tests
git bisect start
git bisect bad HEAD            # la version actuelle est cassée
git bisect good v1.2.0         # cette version fonctionnait

# Git va checkout des commits intermédiaires
# Pour chaque commit, on indique good ou bad
git bisect good  # ou git bisect bad
# Après ~log2(N) itérations, git trouve le commit coupable

6. Ignorer les hooks Git

Les hooks Git s’exécutent automatiquement lors de certaines opérations. Pre-commit hooks pour valider le code avant de commiter — économise du temps en détectant les problèmes tôt.

# .git/hooks/pre-commit (ou avec husky en Node.js)
#!/bin/bash
# Vérifier la syntaxe Python avant chaque commit
python -m py_compile $(git diff --cached --name-only --diff-filter=ACM | grep '.py$')

# Refuser les commits avec des clés AWS hardcodées
if git diff --cached | grep -E 'AKIA[0-9A-Z]{16}'; then
    echo "❌ Clé AWS détectée dans le diff"
    exit 1
fi

Notre formation Git couvre ces bonnes pratiques et les workflows avancés en équipe.