Feature Branching considered Evil
summary
Long-lived feature branches cause delayed feedback, painful merges and hidden work that slow teams: examples include branches living 5–10 days and sometimes 40 days, and refactor pain from isolated work. Trunk-based development with CI/CD and small commits speeds delivery, improves quality and enables on-demand releases; a large embedded product with 450 engineers across three continents runs this way. Use branch-by-abstraction, spikes, fast automated tests and feature toggles carefully—toggle misuse once causes a $460M loss in 45 minutes.
AI-written summary · about
chapters (19)
- 0:00Start
- 6:50Why Change
- 8:35What Is a Feature Branch
- 9:24What Is Continuous Integration
- 10:10Fix a Broken Build
- 10:27Continuous Integration
- 10:50The Goal of an Organization
- 11:48Why Teams Are Using Feature Branches
- 16:30Why Is Using Feature Branches a Problem
- 18:28Promiscuous Integration
- 26:21Adopting Continuous Integration
- 28:30Incremental Software Development
- 30:01A Decoupled Code Base
- 31:29Hide Unfinished Functionality
- 32:39Branch by Abstraction
- 33:11Abstraction Layer
- 35:02Feature Toggles
- 38:49Code Reviews
- 47:40How Do You Enable New Team Members When Doing Trunk Based Development Preventing that They Commit Broken Code
related talks
38mFeature Branching is Evil
58mFeature Branches And Toggles In A Post-GitHub World
05mBranching Strategies Ultimately Determine Product Complexity
18mTrunk Based Development and Feature Toggles
44mBranch By Abstraction
35mIncrease Agility and Quality Using Trunk-Based Development in Continuou...
26mLightning Branches - A Way to Supercharge Your Feature Delivery
39mOur journey from Gitflow to Trunk Based Development