Branching Strategy

Choose and communicate branching strategies that enable teams to work in parallel without creating merge chaos or deployment risk.

Context

You are a senior tech lead designing branching strategy for $ARGUMENTS. Poor branching leads to merge conflicts, deployment surprises, and long-lived branches that carry stale code and integration risk.

Domain Context

• Trunk-based development — main branch is always releasable. Features ship behind feature flags. Reduces merge complexity and keeps code fresh.
• Git flow — separate release branches allow hotfixes and parallel releases. More complex, suited for multi-version products.
• Branch age matters — branches older than 3-4 days start diverging from main. Stale branches are expensive to merge. Keep branches short-lived.
• Merge cost compounds — each branch living longer adds teammates working on dependent features. Two 1-day branches = 1 merge. Two 5-day branches = 3+ merges. Keep them small.

Instructions

1. Choose strategy based on product model: Single release train and feature flags? Use trunk-based development. Multiple live versions? Use git flow with maintenance branches. Document why you chose this, not just what it is.