Open git branch --all on a repo that’s had a few AI coding agents loose in it for a month and you’ll see the problem immediately: patch-1, fix, agent-run-3847, codex-tmp, claude-branch-final-v2. None of it tells you what the branch does, who or what made it, or whether it’s safe to delete. A naming scheme that was merely “nice to have” for a two-person team becomes load-bearing once branches are being created automatically, several times an hour, by tools that don’t know your team’s conventions unless you tell them.

That’s the shift worth naming directly. Git branch naming conventions stop being a style preference and become an operational necessity once AI agents are creating branches alongside you, because you can no longer rely on memory or a Slack thread to know what a given branch was for. This post lays out a naming scheme that works whether the branch was created by a person, a script, or an autonomous coding agent, and explains why the old habits (feature branches with your initials, ad hoc names) stop scaling.

Why the Old Conventions Break Down

Most teams settle into an informal pattern over time: feature/login, bugfix/header, maybe a Jira number if they’re disciplined. That works when a handful of humans create a handful of branches a week, because context lives in people’s heads and in commit messages they wrote themselves.

AI agents remove that shared context. An agent doesn’t remember yesterday’s conversation unless you feed it back in, and a teammate glancing at the branch list has no idea an agent, not a person, produced add-retry-logic. Once you’re running multiple agents against the same repository, you need the branch name itself to answer three questions at a glance: who or what made this, what is it for, and is it still live.

A Naming Scheme That Scales to Agents

A simple, durable pattern is <origin>/<type>/<short-description>, where origin identifies the actor:

• agent/ — created by an autonomous coding agent
• me/ or your initials — created by a human, manually
• ci/ — created by an automated pipeline

Followed by a type segment (feat, fix, chore, refactor, spike) and a short, hyphenated description. A few real examples:

# A human fixing a bug by hand
git checkout -b me/fix/null-check-checkout

# An agent asked to add a feature
git checkout -b agent/feat/csv-export-button

# An agent exploring a refactor that may get thrown away
git checkout -b agent/spike/switch-to-zustand

# A CI-generated branch for a scheduled dependency bump
git checkout -b ci/chore/bump-deps-weekly

The agent/ prefix is the important addition. It means anyone scanning git branch --all instantly knows which branches came from an unattended process and can apply different review scrutiny — agent-authored branches generally deserve a closer diff read before merging, since no human watched every line get written.

Adding Task Identifiers for Traceability

Once you’re running several agents in parallel, plain descriptions aren’t quite enough — you also want to trace a branch back to the specific prompt or task that produced it. Appending a short task ID solves this without making names unreadable:

Pattern	Example	When to use it
agent/feat/<desc>	agent/feat/dark-mode	One-off agent task, no ticket
agent/feat/<desc>-<id>	agent/feat/dark-mode-task42	Task tracked in a backlog or issue tracker
agent/fix/<desc>-<date>	agent/fix/flaky-test-0330	Recurring or scheduled agent runs
me/<type>/<desc>	me/refactor/extract-auth-hook	Manual work, same scheme for consistency

Keeping humans on the same <type>/<description> shape as agents — just swapping the origin prefix — means the whole team reads one convention instead of two. It also makes it trivial to write a script that finds and prunes all merged agent/ branches older than a week, which matters once agents are producing branches faster than any human would clean them up by hand.

Conventions That Prevent Collisions

Naming discipline also has a very practical side effect: it prevents merge conflicts between agents that never should have happened. If two agents are both given branch names derived from the same task description, they can accidentally target the same branch and overwrite each other’s work. Including a timestamp or short random suffix for anything created without human review removes that risk:

git checkout -b agent/feat/rate-limiter-$(date +%H%M)

It’s a small addition, but it guarantees uniqueness without you having to think about it every time an agent kicks off a new task.

Enforcing the Convention Automatically

A written convention only holds up if something checks it, because both humans and agents drift back to old habits under deadline pressure. A lightweight pre-push hook can reject branch names that don’t match the pattern before they ever reach a shared remote:

#!/bin/sh
# .git/hooks/pre-push — reject branches that don't match the naming scheme
branch=$(git symbolic-ref --short HEAD)
if ! echo "$branch" | grep -qE '^(agent|me|ci)/(feat|fix|chore|refactor|spike)/[a-z0-9-]+$'; then
  echo "Branch '$branch' doesn't match <origin>/<type>/<description>"
  exit 1
fi

This won’t stop someone from working locally on a badly named branch, but it does stop badly named branches from ever reaching origin, which is usually the point where naming chaos becomes everyone’s problem instead of just yours. If you’re coordinating a whole team plus several agents, a shared hook like this in the repo (versioned, not just local) keeps the convention consistent without relying on everyone remembering it.

Migrating an Existing Repo to the New Scheme

Adopting a convention on a repo that already has months of inconsistently named branches doesn’t require a big-bang rename. Handle it incrementally: apply the new scheme to every new branch going forward, and only rename an old branch when you next touch it.

# Rename a branch locally and update the remote to match
git branch -m old-messy-name agent/feat/csv-export
git push origin :old-messy-name agent/feat/csv-export
git push origin -u agent/feat/csv-export

Branches that are already merged don’t need renaming at all — just delete them. The goal isn’t a perfectly tidy branch list on day one, it’s making sure every new branch, whether created by a person or an agent, follows a scheme that tells you something useful at a glance.

Getting Started

1. Pick one origin prefix scheme (agent/, me/, ci/) and write it down somewhere the whole team — and every agent’s system prompt — can reference it.
2. Update any agent instructions or CLAUDE.md-style config files to include the naming rule explicitly, since agents will follow written conventions if you state them.
3. Run git branch --all today and rename or delete anything that doesn’t fit, so the convention starts clean rather than half-applied.
4. If you want branch-per-agent enforced automatically instead of by convention, Agents creates an isolated git worktree and branch for every session by default — see the Agents product page for how the workflow fits together.

A naming convention is one of the cheapest fixes available for the chaos multiple agents can introduce into a repo, and it costs nothing more than agreeing on a prefix and writing it down. See the official git branch documentation for the underlying mechanics, then let your naming scheme do the organizing work your memory used to do.

Share this post

C

Choscor

The Choscor team. We build thoughtful Apple apps with creativity and heart.