Git workflow en équipe : les conventions qui évitent les conflits et les catastrophes

Il y a des catastrophes qui forgent le caractère. Pour moi, c'est ce vendredi soir de 2023 : un collègue pousse directement sur main sans branche, sans PR, sans review. 300 lignes de code de prod écrasées. Le site inaccessible pendant 2 heures. Les clients qui appellent. Le CEO qui envoie des messages.

Ce soir-là, j'ai écrit les conventions Git de notre équipe. Je ne les ai jamais regrettées.

Gitflow vs Trunk-Based Development : quel modèle choisir ?

Deux philosophies s'affrontent :

Gitflow (branches longues)

• main — production uniquement
• develop — intégration en continu
• feature/* — nouvelles fonctionnalités
• release/* — préparation des déploiements
• hotfix/* — corrections urgentes de production

Adapté pour : Les projets avec des cycles de release formels, des équipes nombreuses, des versionnages produit explicites.

Trunk-Based Development (branches courtes)

• main — toujours déployable
• Petites branches de feature qui vivent 1 à 3 jours maximum
• Intégration fréquente pour éviter les conflits

Adapté pour : Les petites équipes, les startups, les projets avec déploiements fréquents. C'est ce que j'utilise sur mes projets personnels et la plupart de mes projets clients.

Naming des branches : une convention stricte

Chaque branche doit indiquer son type, son contexte, et optionnellement le numéro de ticket :

# Format
{type}/{ticket}-{description-courte}

# Exemples
feature/DEZ-142-authentication-api
fix/DEZ-234-login-session-expire
refactor/DEZ-301-extract-order-service
chore/DEZ-400-update-dependencies
docs/DEZ-501-api-documentation

# Types autorisés
feature  → nouvelle fonctionnalité
fix      → correction de bug
hotfix   → correction urgente en production
refactor → refactoring sans changement de comportement
chore    → maintenance, dépendances, CI
docs     → documentation
test     → ajout/modification de tests

Commits conventionnels : la lisibilité de l'historique

Un bon historique Git, c'est de la documentation gratuite. La convention Conventional Commits standardise le format :

# Format
{type}({scope}): {description}

# Corps optionnel
[corps — explication détaillée si nécessaire]

# Footer optionnel
[BREAKING CHANGE: description]
[Closes #123]

# Exemples de bons commits
feat(auth): add JWT token refresh endpoint
fix(blog): correct N+1 query in PostController::index
refactor(user): extract UserService from UserController
test(order): add unit tests for OrderService::createOrder
chore(deps): update laravel/sanctum to v3.3

# Exemples de MAUVAIS commits (à bannir)
fix bug
wip
test
asdfgh
correction

Le template de Pull Request

Créez un fichier .github/pull_request_template.md pour forcer une structure :

## Description
<!-- Décrivez les changements apportés -->

## Type de changement
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation

## Comment tester
<!-- Étapes pour reproduire/tester les changements -->

1. ...
2. ...

## Checklist
- [ ] Le code respecte les conventions du projet
- [ ] J'ai ajouté des tests pour mes changements
- [ ] Les tests existants passent
- [ ] J'ai mis à jour la documentation si besoin
- [ ] J'ai testé sur mobile/tablette si pertinent

## Screenshots (si pertinent)

Les Git Hooks : automatiser les vérifications

Avec Husky (Node.js) ou directement en bash, automatisez les vérifications avant chaque commit :

# .git/hooks/pre-commit (bash)
#!/bin/sh

# Vérifier les standards de code PHP
./vendor/bin/php-cs-fixer fix --dry-run --diff
if [ $? -ne 0 ]; then
    echo "❌ Erreurs de style PHP détectées. Lancez php-cs-fixer fix"
    exit 1
fi

# Lancer les tests unitaires
php artisan test --testsuite=Unit
if [ $? -ne 0 ]; then
    echo "❌ Des tests unitaires échouent. Corrigez avant de committer."
    exit 1
fi

echo "✅ Pre-commit checks passed!"

Les règles d'or qui sauvent des nuits

1. Jamais de push direct sur main. Sans exception. Même pour "une petite correction de typo".
2. Au moins une review avant le merge. Les yeux qui ont écrit le code ne voient pas ses erreurs.
3. Des commits atomiques. Un commit = un changement logique. Pas "fix everything".
4. Rebaser avant de merger. Gardez un historique linéaire et lisible.
5. Taggez vos déploiements. git tag v1.2.3 -m "Release 1.2.3" permet de rollback précisément.

Conclusion

Un bon workflow Git ne se construit pas en un jour. Il évolue avec l'équipe, les besoins, les incidents. Mais commencez avec ces bases : conventions de nommage, commits structurés, pull requests systématiques, et hooks de vérification.

Votre futur vous, aux 23h un vendredi de prod en feu, vous remerciera.