Git pour les équipes : workflows et bonnes pratiques

Pourquoi un workflow Git structuré ?

Sans conventions claires, Git devient rapidement chaotique en équipe : conflits de merge fréquents, historique illisible, branches abandonnées. Un workflow structuré résout ces problèmes et accélère le développement.

Chez Lueur Externe, nous utilisons des workflows Git rigoureux sur tous nos projets, y compris ce site satellite déployé via GitLab CI/CD.

Git Flow : le classique

Git Flow organise le développement autour de branches à durée de vie longue :

main ─────────────────────────────────────────►
  │                                    ▲
  └── develop ──────────────────────── merge
        │           ▲        │
        └── feature/seo ──── merge
        └── feature/blog ─── merge

Branches principales

main : code en production, toujours stable
develop : intégration des fonctionnalités, base pour les releases

Branches de support

feature/* : développement d’une fonctionnalité
release/* : préparation d’une version
hotfix/* : correction urgente en production

Quand utiliser Git Flow

Projets avec des cycles de release planifiés
Équipes de plus de 5 développeurs
Produits avec plusieurs versions en maintenance

Trunk-based development : l’approche moderne

Le trunk-based development privilégie des branches courtes mergées fréquemment :

main ──●──●──●──●──●──●──●──●──●──►
       │     │        │
       └─●─┘  └──●──┘  └─●─┘
       (1-2 jours max)

Principes

Branches de vie courte (1-2 jours maximum)
Merge fréquent dans main
Feature flags pour les fonctionnalités en cours
CI/CD obligatoire avec tests automatisés

Quand utiliser le trunk-based

Équipes pratiquant le déploiement continu
Projets web avec des releases fréquentes
Équipes expérimentées avec une bonne couverture de tests

Conventional Commits

Les Conventional Commits standardisent les messages de commit :

feat(blog): add article pagination component
fix(seo): correct canonical URL for multilingual pages
docs(readme): update deployment instructions
refactor(lib): simplify interlinking algorithm
test(unit): add slug generation edge cases
chore(deps): update astro to 5.17.2

Format

<type>(<scope>): <description>

[body optionnel]

[footer optionnel]

Types courants

Type	Usage
`feat`	Nouvelle fonctionnalité
`fix`	Correction de bug
`docs`	Documentation
`refactor`	Refactoring sans changement fonctionnel
`test`	Ajout ou modification de tests
`chore`	Maintenance (dépendances, CI, etc.)

Code reviews efficaces

Checklist de review

Le code compile et les tests passent
La logique métier est correcte
Le code est lisible et maintenable
Pas de failles de sécurité évidentes
Les performances sont acceptables
La documentation est à jour

Bonnes pratiques

Petites PR : 200-400 lignes maximum pour une review efficace
Description claire : expliquez le pourquoi, pas juste le quoi
Feedback constructif : suggérez des alternatives, ne critiquez pas
Automatisation : linting et tests en CI avant la review humaine

Intégration avec CI/CD

Sur ce projet, notre pipeline GitLab CI/CD vérifie automatiquement :

stages:
  - lint
  - test
  - build
  - deploy

lint:
  script: npm run lint

test:
  script: npx vitest run

build:
  script: npm run build

Chaque merge request déclenche les vérifications automatiques avant la review humaine. C’est une pratique standard chez Lueur Externe.

Conclusion

Un workflow Git bien défini est un investissement qui paie rapidement : moins de conflits, un historique propre et des déploiements fiables. Lueur Externe met en place ces pratiques sur chaque projet.