The Branch Strategy That Survived 50 Agent Sessions
Short-lived, flow-scoped branches beat long-running feature branches when the agent is writing the code. Here's the pattern I landed on, and the one rule that makes it work.
Table of Contents
After fifty flows through DevFlow, one thing became unambiguous: every flow gets its own branch, and the branch dies with the flow. No long-running feature branches, no stacked PRs, no “I’ll keep working on this one” carry-overs. The discipline is what makes AI-assisted development trustworthy.
The rule: one flow, one branch, one PR
Every time DevFlow transitions a flow to in_progress, it cuts a fresh branch off main named after the display ID — un-42-checkout-refactor, for example. The agent works on that branch and only that branch for the lifetime of the flow. When the flow ships, the branch merges and is deleted.
No exceptions. Not “while I was there I fixed the unrelated bug.” Not “let me keep this branch open for follow-ups.” The branch is coupled 1:1 to a reviewed plan. The moment you loosen that, you stop being able to answer “why did this line change?”
What this buys you
Three things, all concrete:
- Surface area for review. A flow-scoped PR is small by construction — it touches only the files in the plan. Reviewing 40 lines of agent-written code is tractable. Reviewing 800 is theater.
- Rollback granularity. When a shipped flow regresses something in prod, reverting its merge commit is the whole fix. No hunting through a 20-file feature branch for the one bad change.
- Honest conflicts. Short branches conflict rarely, and when they do, the conflict is local to the plan. Long branches accumulate friction that has nothing to do with the work — you spend an afternoon rebasing because main moved under you while you dithered.
The one rule that makes it work
Never scope two flows to the same branch. The instinct is to think “these two flows are related, let me do them together.” Resist. If they’re related, they should be one flow with one plan, not two flows sharing a branch. Sharing a branch across flows means you lose the 1:1 link between “reviewed plan” and “shipped code.”
This is also why the strictness setting in DevFlow forbids branch sharing at level 5. The server actively checks for a branch already owned by a different flow and refuses the operation.
What the demo shows
In the clip above, I run three flows in rapid succession. Each cuts its own branch, each merges clean, each gets its own PR number. Zero conflicts across the three. If I’d tried the same three as shared work on a single branch, I’d have spent the evening untangling whose change broke which test.
Short branches, tight scope, one flow per branch. That’s the whole thing.
