Conflits Git : la discipline qui les évite (pas qui les résout)

Conflits Git : la discipline qui les évite (pas qui les résout)

90% des conflits Git viennent de 2 causes : branches longues + fichiers monolithiques. La solution n'est pas un meilleur outil de merge, c'est une meilleure discipline.

Les 4 règles anti-conflits

1. Branches courtes : ≤ 2 jours de vie. Au-delà : rebase quotidien obligatoire.
2. Fichiers ≤ 400 lignes : 2 devs sur le même fichier 1200l = conflit garanti. Split = isolation.
3. 1 PR = 1 sujet : éviter le "tant que j'y suis je refactore aussi…". Chaque ajout = surface de conflit.
4. Conventional commits : feat:, fix:, refactor: → review plus rapide → merge plus vite.

Workflow Next Generation

main (toujours déployable)
  ├── feat/newsletter-archive  (1-3 jours max)
  ├── fix/rls-admin-policies   (heures)
  └── refacto/case-studies-split (1 jour)

Pas de develop long-lived. Trunk-based development.

Pattern rebase quotidien

git fetch origin && git rebase origin/main

Résout les conflits 1 par 1 (petits) au lieu de 1 gros en fin de semaine. ROI immédiat.

Anti-pattern : merge commit "fix conflicts"

Un commit "merge conflicts" cache la vraie diff. Reviewer ne peut pas valider. Préférer rebase qui réécrit l'historique proprement.

CodeOwners pour les fichiers critiques

# .github/CODEOWNERS
src/data/services.ts @meymoun
supabase/migrations/* @backend-team

Force une review par le owner = pas de modif silencieuse sur les fichiers sensibles.