Feature Branches And Toggles In A Post-GitHub World
summary
Long-lived feature branches cause large merge pain: an 18‑month rollout with ~60 developers created r3→r4 merges that take days to compile and introduce regressions. Git and GitHub make branches cheap but cannot merge semantic refactorings; semantic merges still fail. Alternatives that work: trunk-based development with small daily merges, hiding half-finished work with feature toggles or using branch by abstraction (GoCD migrated iBatis→Hibernate gradually). Puppet Labs / State of DevOps finds <1‑day branches and <3 active branches correlate with higher throughput.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:30Building Market Services
- 1:47ThoughtWorks
- 4:16R3 branch
- 15:10Release branches
- 20:46Refactoring
- 25:31Hiding Functionality
- 29:54Branch By Abstraction
- 30:20Flags
- 31:30Reuse
- 32:14Continuous Delivery
- 43:23GitHub
- 48:13Git Flow
- 50:26Feature Toggles
- 53:03State of DevOps Report
related talks
50mFeature Branching considered Evil
38mFeature Branching is Evil
39mOur journey from Gitflow to Trunk Based Development
18mTrunk Based Development and Feature Toggles
27mDevOps Days MTL 2019 - Christian Couder
41mA Branching Strategy For You?
05mBranching Strategies Ultimately Determine Product Complexity
26mLightning Branches - A Way to Supercharge Your Feature Delivery