Feature Branching is Evil
summary
Claim is that feature branches slow teams by delaying feedback, increasing merge conflicts and WIP, and hiding refactor pain; evidence includes tools and practices like Git, Subversion, GitLab CI, pull requests, feature toggles and expand–contract refactor patterns; surprising scale examples: 25,000 engineers on a single trunk and 16,000 changes per day; teams that adopt trunk based development and pair programming merge frequently, get minutes‑scale CI feedback, reduce lead time, raise throughput and actually make it work.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:10Team’s journey to trunk-based dev
- 5:21Team’s struggles with Git Flow
- 7:47Mainline, branching, and CI defined
- 10:18Goal: lead time reduction
- 11:23Reasons for feature branches
- 15:37Problems with feature branches
- 23:07Trunk-based development solutions
- 35:13Feature branching is a symptom
- 36:39Adopting trunk-based dev challenges
- 37:23Closing remarks and Q&A
related talks
50mFeature Branching considered Evil
58mFeature Branches And Toggles In A Post-GitHub World
05mBranching Strategies Ultimately Determine Product Complexity
41mA Branching Strategy For You?
26mLightning Branches - A Way to Supercharge Your Feature Delivery
44mBranch By Abstraction
07m26 Feature Branches and other tales from the wild
18mTrunk Based Development and Feature Toggles