Ask ten teams about their Git strategy and you will get ten answers - and usually ten exceptions to each answer. With agents in the picture the problem gets worse: an agent can open a branch, commit ten times, abandon another one, all within a few minutes. Without a framework your Git graph becomes unreadable and you lose the only thing that matters: knowing where each feature stands.
Survol's conviction is simple: splitting work into branches is a technical view, not a product view. You should not have to think about it. The tool applies a clear strategy on your behalf and shows it to you as readable lanes.
You steer features and versions. Branches are the tool's business.
The model: one lane per feature
Every feature has its lane. Inside it, each version (v1.0, v1.1, v2.0…) lives on its own branch and produces one merge request. The rule fits in one line:
- One branch per feature to isolate the work;
- One merge request per version to keep every increment reviewable and deployable;
- One preview per merge request so you can validate before you promote.
# The lane of the "Promo codes" feature feature/promo-codes ├─ v1.0 → PR #41 → preview → ✅ production ├─ v1.1 → PR #58 → preview → ✅ production └─ v2.0 → PR #72 → preview → ⏳ in test
Humans and agents, side by side
The key point is that this strategy makes no difference between a version built by an agent and one written by hand. In Survol's domain model, the origin of a version is neutral: agent, manual or mixed. A manual branch follows exactly the same lifecycle as an agent branch - same lane, same merge request, same preview.
Reconciliation, not surveillance. A developer opens a branch outside Survol? Webhooks detect it and the tool offers to attach it to the right feature. Never an informer's tone: we reconcile the work, we do not police anyone.
What about multiple repositories?
A feature can spread across several repositories (front end, back end, shared library). That technical split stays invisible at the product level: a multi-repository version means one branch per repository but a single "Approve" button. You think in features; Survol coordinates the lanes under the hood.
What you gain
- A readable Git graph, even when an agent is committing at full speed.
- A permanent answer to "which version is that feature in, and on which branch?".
- Developers and agents coexisting without friction or double bookkeeping.
We talk a lot about how fast agents are. We talk far too little about the readability they destroy if you let them run without a framework. One branch per feature, one merge request per version: it is boring, it is disciplined, and it is exactly what lets you keep the map of your product while the code is being written at machine speed.
