Long-Lived Feature Branches
Branches that live for weeks or months, turning merging into a project in itself. The longer the branch, the bigger the risk.
11 minute read
Branches that live for weeks or months, turning merging into a project in itself. The longer the branch, the bigger the risk.
11 minute read
The build has been red for weeks and nobody cares. “CI” means a build server exists, not that anyone actually integrates continuously.
11 minute read
Hand-selecting specific commits for release instead of deploying trunk, indicating trunk is never trusted to be deployable.
10 minute read
Maintaining multiple release branches and manually backporting fixes creates exponential overhead as branches multiply.
11 minute read
Only specific individuals can work on or review certain parts of the codebase. The team’s capacity is constrained by who knows what.
5 minute read
Code reviews wait overnight. Questions block for 12+ hours. Async handoffs replace collaboration.
3 minute read
Developers announce merge freezes because the integration process is fragile. Deploying requires coordination in chat.
3 minute read
The time from making a change to knowing whether it works is measured in hours, not minutes. Developers batch changes to avoid waiting.
4 minute read
No explicit agreements on branch lifetime, review turnaround, WIP limits, or coding standards. Everyone does their own thing.
3 minute read
Integration is a dreaded, multi-day event. Teams delay merging because it is painful, which makes the next merge even worse.
3 minute read
Pull requests queue up and wait. Authors have moved on by the time feedback arrives.
3 minute read
Something that worked before the release is broken after it. The team spends time after every release chasing down what changed and why.
4 minute read
Developers feel unsafe committing to trunk. Feature branches persist for days or weeks before merge.
4 minute read