Trunk-Based Development

DevOps 🟡 Mid

Stratégie de branchement où tous les devs commitent sur main (trunk) via des branches courtes (<1 jour). Favorise l'intégration continue.

Un seul cahier partagé où chacun écrit sa partie rapidement plutôt que chacun son cahier fusionné une fois par mois.

git checkout -b feat/login
# ... code pendant quelques heures
git push origin feat/login
# PR review rapide puis merge dans main

Équipes pratiquant le CI/CD avec des déploiements fréquents (plusieurs fois par jour).

Branches vivant des semaines : merge hell et conflits géants.

#devops#git#interview

Explique-moi le trunk-based development.
C'est une stratégie de branchement où tous les devs commitent sur main via des branches courtes de moins d'un jour, ce qui favorise l'intégration continue. C'est comme un seul cahier partagé où chacun écrit sa partie rapidement, plutôt que chacun son cahier fusionné une fois par mois.
Pour quelles équipes ce modèle est-il adapté ?
Pour les équipes qui pratiquent le CI/CD avec des déploiements fréquents, plusieurs fois par jour. Le workflow type est court : git checkout -b feat/login, quelques heures de code, push, puis review rapide et merge dans main.
Quel est le risque si les branches vivent trop longtemps ?
Ça mène à un merge hell avec des conflits géants, à l'opposé de l'esprit trunk-based qui impose des branches courtes. C'est justement l'anti-pattern que ce modèle cherche à éviter.

Fiche mise à jour le 2026-09-27