Git pour développeurs web : workflow et bonnes pratiques (2026)

Git est le couteau suisse du développeur web — indispensable, mais souvent mal utilisé. Un bon workflow Git évite les conflits, facilite la collaboration et rend le code reviewable et traçable. Voici les pratiques qui font la différence.

Workflow Gitflow vs Trunk-Based Development

Gitflow utilise deux branches permanentes (main et develop) et des branches feature, release et hotfix. C’est structuré mais lourd pour les petites équipes. Trunk-Based Development : tout le monde travaille sur main, avec des branches feature très courtes (< 2 jours). C'est l'approche recommandée pour les équipes qui font du CI/CD sérieux.

Pour la plupart des projets web en 2026 : créez une branche par feature ou fix, ouvrez une Pull Request, mergez sur main après review. Simple et efficace.

Commits conventionnels

Le format Conventional Commits standardise les messages de commit et permet de générer automatiquement des changelogs :

feat: add user authentication with JWT
fix: correct product price calculation for discounts
docs: update API documentation
refactor: extract payment logic into PaymentService
perf: add Redis cache for product queries
chore: update dependencies to latest versions
test: add unit tests for CartService

# Avec scope
feat(auth): add OAuth2 Google login
fix(checkout): prevent double-submit on order form

Installez Commitlint + Husky pour forcer ce format dans votre équipe : les commits non conformes sont rejetés avant le push.

Branches : nommage et durée de vie

Nommez vos branches de façon descriptive et préfixée :

feature/user-authentication
fix/checkout-double-submit
hotfix/security-xss-article-title
chore/update-node-18-to-20
refactor/extract-payment-service

Règle d’or : une branche = une fonctionnalité ou un fix. Pas de branches fourre-tout. Durée de vie idéale : moins de 5 jours. Plus longtemps, le merge devient douloureux.

Pull Requests : l’art de la code review

Une bonne PR est petite (< 400 lignes de diff), focalisée, et accompagnée d'une description qui explique pourquoi plutôt que quoi (le code explique le quoi). Description type :

## Pourquoi
Les utilisateurs pouvaient soumettre le formulaire de commande deux fois si
la connexion était lente, créant des doublons de commandes.

## Changements
- Ajout d'un état de chargement sur le bouton submit
- Désactivation du formulaire pendant la soumission
- Ajout d'un test E2E pour couvrir ce cas

## Comment tester
1. Aller sur /checkout
2. Soumettre avec une connexion throttlée (DevTools)
3. Vérifier qu'une seule commande est créée

Git aliases qui font gagner du temps

# ~/.gitconfig
[alias]
    st = status
    co = checkout
    br = branch
    lg = log --oneline --graph --decorate --all
    undo = reset HEAD~1 --mixed        # Annuler le dernier commit sans perdre les changements
    aliases = config --get-regexp alias

Sécurité Git : ce qu’il ne faut jamais committer

Un fichier .gitignore bien configuré est essentiel. Ajoutez systématiquement :

.env
.env.local
.env.production
*.pem
*.key
node_modules/
vendor/
.DS_Store

Si vous avez commité un secret par erreur, traitez-le comme compromis : révoquez-le immédiatement et changez-le. L’historique Git est public — même après un revert, le secret est visible dans l’historique. Utilisez BFG Repo Cleaner pour purger l’historique si nécessaire, mais changez le secret avant tout.

Git bisect : trouver le commit qui a introduit un bug

Git bisect effectue une recherche binaire dans l’historique pour trouver le commit fautif :

git bisect start
git bisect bad                    # Le commit actuel a le bug
git bisect good v2.1.0            # Cette version n'avait pas le bug
# Git checkout le commit du milieu
# Testez → dites à Git si c'est bon ou mauvais
git bisect good  # ou git bisect bad
# Répétez jusqu'à trouver le commit fautif
git bisect reset                  # Retour à HEAD

Sur 1000 commits, bisect trouve le commit fautif en 10 étapes.