Git Branching Strategy for Small Teams (and AI Agents)

For most small teams the right git branching strategy is the simplest one: keep main always deployable, do every change on a short-lived branch, merge it through a reviewed pull request within a day or two, and delete the branch. That is GitHub flow, and with branches that live hours rather than days it becomes trunk-based development. Git flow, with its develop, release and hotfix branches, earns its extra weight only when you ship numbered versions or support several releases at once. AI coding agents do not change the answer; they raise the stakes. An agent can open five branches before lunch, so the rules that keep branches short, isolated and reviewed matter more, not less.

The three strategies at a glance

• Trunk-based development. Everyone integrates into one branch, the trunk, at least daily. Branches, if used, last hours. Unfinished features hide behind feature flags rather than on long branches.
• GitHub flow. One long-lived branch, main. Each change gets a descriptive branch, a pull request, a review and a merge, and the branch is deleted afterward.
• Git flow. Two long-lived branches, main for releases and develop for integration, plus feature, release and hotfix branches that each start and end in specific places.

Trunk-based development

The research program behind the DORA metrics defines trunk-based development↗ (opens in a new tab) as developers dividing their work into small batches and merging into trunk at least once a day. Its markers are specific: three or fewer active branches in the repository, branches merged to trunk at least daily, and no code freezes or integration phases. DORA reports that teams following these practices achieve higher software delivery and operational performance.

Pure trunk-based development, where people commit straight to trunk, suits a small team with strong automated tests. Most teams use the variant with short-lived feature branches↗ (opens in a new tab): one developer (or a pair) per branch, a branch that lasts no more than a couple of days, and a review and CI run before it lands. Past two days, that guide warns, it is at risk of becoming a long-lived feature branch.

The cost is discipline. Work has to be sliced small enough to merge daily, and anything half-built needs a flag so that merging it does not ship it.

GitHub flow

GitHub’s own description↗ (opens in a new tab) calls it a lightweight, branch-based workflow and lists six steps:

1. Create a branch with a descriptive name, so collaborators can see ongoing work at a glance.
2. Make changes, committing each isolated, complete change with a descriptive message.
3. Open a pull request that says what the change solves and links related issues.
4. Address review comments by pushing more commits; the pull request updates itself.
5. Merge once approved.
6. Delete the branch, so nobody accidentally keeps using it.

Nothing in GitHub flow sets a time limit, and that is its one weak spot. A branch left open for three weeks is still GitHub flow on paper and a merge problem in practice. Add a limit of your own, such as “merge or close within three working days”, and GitHub flow and trunk-based development with short-lived branches become almost the same thing. The name does not tie you to GitHub; the same flow works on any host with pull or merge requests.

Git flow

Git flow comes from Vincent Driessen’s 2010 post, “A successful Git branching model”↗ (opens in a new tab). Feature branches start from develop and merge back into it. A release branch starts from develop, is stabilized, and merges into both main and develop. A hotfix starts from main and merges into both. Each release merged into main is tagged with its version.

The author added a note to the post in March 2020 that is the best advice on when to use it. He wrote that for “software that is explicitly versioned”, or when you “need to support multiple versions of your software in the wild”, git-flow may still be a good fit. For teams doing continuous delivery, he suggested “a much simpler workflow (like GitHub flow) instead”. A web app or a SaaS product deployed from main falls in the second group. A mobile app waiting on store review, an installable desktop product or a library with maintained major versions can fall in the first.

Choosing for a small team

• You deploy a web app or service whenever main changes: GitHub flow, with a time limit on branches.
• You have good automated tests, a feature-flag habit and want the fewest merge surprises: trunk-based development.
• You ship numbered releases that sit in review or in customers’ hands for weeks, or patch old versions: Git flow, or GitHub flow plus a release branch cut for each version.
• You are one person: commit to main or use short branches, whichever makes review with your tools easier. Add rules when a second contributor, human or AI, arrives.

Whichever you choose, protect the branch you deploy from. GitHub’s protected branches↗ (opens in a new tab) can require a pull request, a number of approving reviews and passing status checks before anything merges; GitLab and Bitbucket have equivalents. A strategy nobody enforces is a suggestion.

What changes when AI agents open branches

Coding agents such as Claude Code, Codex and the GitHub Copilot coding agent all work on branches and hand back a pull request or a diff. They are fast, they never tire of creating branches, and they read your written rules every session. That changes a few things:

• One task, one branch, one session. An agent session should never share a branch or a checkout with another. Parallel sessions need separate worktrees, covered in Claude Code with git worktrees.
• Short by default. An agent branch should be merged or closed within a day or two. Agent branches go stale as fast as human ones, and a queue of old ones is a queue of conflicts.
• Branch from a fresh main. Agents that branch from someone’s half-finished work inherit it. Claude Code worktrees branch from the remote default branch unless you tell them otherwise, which is the right default.
• Never push to main. Agents propose; a person merges. Branch protection makes that a setting rather than a hope.
• Review is the bottleneck. Agents produce branches faster than people can read them. Cap the number of open agent branches at what your reviewers can clear in a day.

Write the rules where agents read them

An agent follows the branching rules it is given, so put them in the file it loads at the start of every session: CLAUDE.md for Claude Code, AGENTS.md for Codex and others. Keep them short and concrete:

## Branching
- Never commit to main. Every change is a branch and a pull request.
- Branch from an up-to-date main. Name it <type>/<task-ref>-<short-name>,
  for example fix/bug-042-cart-total.
- One task per branch. Do not mix unrelated changes.
- Keep it small enough to review in 15 minutes. If it grows, stop and ask.
- Rebase on main before opening the pull request; do not merge main in.
- Never force-push a branch someone else has pushed to.
- After merge, delete the branch.

The branch name carries the task ref for a reason: it links code to the work without any integration. On a fenbs board every task already has one, FET-, ENH- or BUG- plus a number, so fix/bug-042-cart-total points straight at BUG-042. Ask the agent to comment the branch and pull request on the task when it opens one, and the commit and how it was tested when it finishes. The task then carries the record after the branch is deleted, and its history shows which changes came from an assistant, recorded as “Claude via” the person it acts for.

The strategy itself is a decision the team made, and it should outlast any one session. On fenbs you record it on the Decisions and rules page as a rule, which holds from now on and which every connected AI assistant reads before it starts. A person is always the one who decides it. fenbs has no sprints, due dates or settable assignee, so the branch rules stay with your git host, and the board holds what each branch was for.