AI Coding Agents and Git: A Workflow That Won't Wreck Your Branch

Never let it commit directly to a shared branch

The baseline rule is simple: every agent run happens on its own branch, cut from an up-to-date main, never as a direct commit to a branch other people are building on. This turns any mistake into something you discard by deleting a branch, rather than something you have to untangle from shared history.

This matters more with agents than with human contributors because an agent can make dozens of changes in the time it takes a human to make one, and those changes can compound in ways that are hard to unwind after the fact if they land somewhere shared.

Commit granularity and history hygiene

Ask the agent, or configure the harness, to commit in small, logical chunks rather than one giant commit at the end. It makes git bisect useful later and makes review easier, since you can follow the agent's reasoning through the sequence of changes rather than facing one undifferentiated diff.

Before merging, squash or clean up commits that reflect the agent's own trial and error, such as failed attempts or exploratory commits, so the history that lands on main tells a clear story of what changed and why, the same standard you would hold a human contributor to.

• One branch per agent run, cut from an up-to-date main
• Small, logical commits instead of one large commit
• Squash or clean history before merging to main
• Keep the agent's exploratory branches around briefly in case you need to recover something

Recovering when something goes wrong

Because the work lives on a disposable branch, recovery from a bad run is almost always just deleting the branch and starting over with a clearer task description, far cheaper than debugging a confused agent mid-task.

Keep the branch around briefly rather than deleting it immediately, though. Sometimes a failed run contains one useful piece worth cherry-picking even though the overall attempt did not work out.