Trunk-Based Development

Le Trunk-Based Development (TBD) est une stratégie de branching Git où tous les développeurs travaillent directement sur une branche unique (trunk = main/master), avec des feature branches très courtes (heures à 1-2 jours max) avant merge. S'oppose à Git Flow / GitHub Flow / Release branches qui maintiennent de longues branches parallèles. Pratique fondamentale pour atteindre haute fréquence de déploiement (CI/CD elite DORA).

Deux variantes : (1) Pure trunk-based (used by Google, Facebook) — commit direct sur main avec pre-commit hooks + CI obligatoire, sans Pull Request (mais code review via tooling spécifique) ; (2) Trunk-based avec short-lived feature branches (most common at companies using GitHub/GitLab) — branches qui vivent <2 jours, PR mergé daily.

Principes clés : (1) commits petits et fréquents (multiple per dev per day) ; (2) integration continue dans trunk (pas de long-lived feature branches accumulant changes) ; (3) feature flags pour découpler deployment de release (code en prod inactive jusqu'à activation flag) ; (4) backward compatibility code (peut être déployé partiellement) ; (5) automation extensive (CI obligatoire, tests forts) ; (6) main toujours en état releasable (any commit could ship to prod).

Avantages : (1) less merge conflicts (small frequent integrations vs big bang merge ressemblant nightmare) ; (2) faster feedback (regression detected en heures vs days/weeks) ; (3) higher deploy frequency facilitating DORA elite metrics ; (4) reduces fear of merging (small surface area per merge) ; (5) better code review (small PRs reviewable in <30min vs hours pour large PRs) ; (6) easier rollback (small commits = git revert simple) ; (7) better collaboration (everyone seeing latest code soon) ; (8) supports Continuous Deployment cleanly.

Inconvénients/Challenges : (1) requires discipline et engineering maturity (devs must split work in small reviewable increments — counter-intuitive pour habitudes "PR énorme avec toute la feature") ; (2) requires feature flags infra (sinon code half-baked en prod) ; (3) requires strong testing (no manual gate via long-lived QA branch) ; (4) requires culture commit small (some devs prefer batch big PR) ; (5) tooling support not all platforms (GitHub PR-centric, some workflows assume Git Flow).

Comparaison branching strategies :
- Git Flow (Vincent Driessen 2010) : main/develop/feature/release/hotfix branches, complex, used quand release cycles long et infrequent. Considered outdated by many in 2024.
- GitHub Flow : main + short feature branches via PR. Simple, deploy from main on merge. Closer to TBD but less strict on branch lifetime.
- GitLab Flow : main + environment branches (staging, production). Useful when can't continuously deploy.
- Trunk-based : minimal branching, max integration speed.
- Release Flow (Microsoft VSTS pattern) : trunk-based + release branches for hotfixes/cherry-picks.

DORA research : trunk-based development is strong predictor of elite team performance (high deploy frequency, low change failure rate, fast MTTR). Recommended in Accelerate book (Forsgren, Humble, Kim).

Implementation tips : (1) use feature flags (LaunchDarkly, Unleash, etc.) ; (2) merge queue (GitHub merge queue, Aviator, Mergify) pour prevent ouverture conflicts at scale ; (3) optional review via pair programming réduisant PR overhead ; (4) automated style/lint enforcement ; (5) limit PR size (e.g. 200 lines max) ; (6) ban long-lived branches via repo policy. Compétences DOP-C02, AZ-400, GH-FOUND.