1 min lesson
The case for release branches / GitFlow
Talk this through in your own words: "A regulated insurer runs GitFlow with monthly release branches and asks if Cursor requires them to switch to trunk-based. What do you say?" Finish with the next move.
Step 1 of 2
The case FOR release branches / GitFlowdon't be dogmatic
- Versioned or on-prem software (you ship v4.2 to a customer's datacenter) genuinely needs a stabilized branch to patch.
- Regulated change windows and formal release sign-off map naturally to a cut-and-stabilize branch.
- Flags carry their own complexity and tech debt: dead flags, combinatorial test matrices. They aren't free.
- When a team's test gates are weak, trunk-based is dangerous. The branch buys a staging buffer they actually rely on.
Never walk in and tell a regulated bank to 'just go trunk-based.' Their release branch usually exists because an auditor wants a stabilized, signed artifact. Meet the model where it is. Cursor wins on smaller, better-tested commits inside any branching model.
Trunk-based without disciplined flag hygiene becomes a graveyard of stale flags and untested combinations. A flag is a feature with a lifecycle, not a switch you forget.
When asked 'which branching model is best,' the wrong answer is naming one. The right answer: 'Best for what risk tier and deploy maturity? Put them on the integration-frequency axis and the answer falls out. I can argue all three and here's when each wins.'