How to Use Git With an AI Coding Agent Safely

Use a branch per task, commit before every agent run, and review the diff rather than the agent's summary. That is the whole workflow, and it is worth the four minutes it costs, because an AI coding agent will touch files it never mentioned and its own account of what it did is a description written from memory rather than a record.

Git is not a nice-to-have here the way it is with hand-written code. It is the agent's undo button, the audit log, and the only place you can see what actually happened.

Why the agent's summary is not enough

When an agent finishes, it tells you something like "updated the auth handler and added a test." That is usually true and usually incomplete. Agents reformat files they open, adjust imports, rename a variable in three places for consistency, and occasionally revert something a previous run did. None of that reliably makes the summary.

The diff has no such problem. `git diff` shows every byte that changed, in every file, whether or not the agent thought it worth mentioning. Reading it takes about as long as reading the summary and tells you the truth. If you take one habit from this piece, take that one.

The workflow

Start clean

Never launch an agent on a dirty working tree. If you have uncommitted changes of your own and the agent edits the same files, you cannot separate your work from its work afterwards.

git status                    # must be clean
git switch -c feat/booking-emails

One branch per task, named for the task. This matters more with agents than with people, because agent sessions drift. You ask for one thing, notice a second thing, ask for that too, and forty minutes later the branch contains three unrelated changes that have to ship or be reverted together.

Commit before every run, not just after

The commit before the agent runs is the one that saves you.

git commit -am "checkpoint: before adding email confirmations"

Use commits as save points during the session, freely and with unglamorous messages. You are going to squash them later. A branch with fifteen checkpoint commits is not messy, it is a session you can rewind to any point in.

Review the diff, file by file

After each run, before you accept anything:

git diff --stat               # what got touched, and how much
git diff                      # what actually changed

`--stat` first is the fast tell. If you asked for a change to one route handler and the stat shows nine files, something happened that you did not ask for. Sometimes that is legitimate, a shared type genuinely needed updating. Sometimes it is the agent tidying as it goes, which is how features quietly break. This is the same problem as stopping an agent changing code you did not ask about, and the diff is where you catch it.

For anything non-trivial, review the diff on its merits rather than skimming for obvious breakage. The code review checklist for AI-generated code applies unchanged here.

Accept selectively

You do not have to take the whole diff. If the agent did three things and two are right:

git add -p                    # stage hunks individually
git checkout -- path/to/file  # discard changes to a file entirely

`git add -p` walks you through each hunk and asks. It is slow the first few times and then becomes the fastest way to keep the good half of an agent's work.

Squash before merging

git rebase -i main            # squash checkpoints into real commits

Ship a readable history. Your future self reading `git log` wants to see "add email confirmations to booking flow," not fifteen entries saying "checkpoint."

The recovery drill

Learn this before you need it, because you will need it during the run where you are already frustrated.

The agent broke something and you have not committed. Discard everything since the last commit:

git checkout .                # discard all unstaged changes
git clean -fd                 # remove files the agent created

The `clean` step is the one people forget. Agents create files, and `checkout` does not remove untracked ones.

The agent broke something and you committed it. Go back one commit, keeping the changes visible so you can see what went wrong:

git reset --soft HEAD~1

Use `--hard` instead if you want the changes gone entirely.

You reset too far and lost work. This is the command worth memorising:

git reflog                    # every position HEAD has held
git reset --hard <hash>

`reflog` records every commit HEAD has pointed at, including ones no branch references any more. Work that feels permanently lost is almost always sitting in there. Nothing committed to a Git repository is really gone for about 90 days.

The whole session went sideways. Abandon the branch:

git switch main
git branch -D feat/booking-emails

This is why the branch-per-task rule earns its keep. Throwing away an hour is annoying. Throwing away an hour without disturbing anything else is just a decision.

Two settings worth changing

Turn on rerere so Git remembers how you resolved a conflict and replays it if the same conflict reappears, which happens constantly when an agent regenerates similar code:

git config --global rerere.enabled true

And make `git log` readable at a glance, since you will be scanning session history often:

git config --global alias.lg "log --oneline --graph --decorate -20"

What about agents that commit for themselves

Some agents can run Git commands directly. Whether to allow that comes down to one question: do you review before or after the commit lands?

Letting the agent commit its own checkpoints is fine and genuinely useful, since it gets save points at natural boundaries you would not have thought to create. Letting it commit to a shared branch, merge, force-push, or rewrite history is a different proposition, and there is no upside that justifies it. Scope its Git access to the branch it is working on.

The same reasoning applies to the broader question of how much autonomy to hand an agent. Reversible actions on an isolated branch are cheap to get wrong. Anything touching shared state is not.

If you are still choosing what to run this workflow on, the wider landscape of AI coding tools covers which agents handle branching and commits natively and which need the discipline imposed from outside.

FAQ

Should I commit code I have not read?

For a throwaway prototype, sure. For anything with users, no, and the branch structure exists precisely so that "I have not read it yet" is a safe state rather than a risky one. Commit it to the branch, read it before you merge.

How often should I commit during an agent session?

Before every prompt that will change code, and after any run whose output you want to keep. That feels excessive for about a day and then feels normal. Squashing at the end means the frequency costs you nothing in the final history.

What if the agent rewrites my commit history?

Recover with `git reflog` to find the pre-rewrite state and `git reset --hard` to return to it, then remove the agent's ability to run history-rewriting commands. On a shared branch, this is the one agent mistake that affects other people, which is why it belongs outside the permission boundary rather than inside it.

Do I need a different branch strategy for agent work?

No. Ordinary trunk-based development with short-lived feature branches works well, and the only adjustment is that branches get shorter and more numerous because sessions are shorter and more numerous. If your team already squash-merges pull requests, nothing changes at all.

How does this fit with debugging?

Cleanly, and it makes debugging much faster. When something breaks after several agent runs, `git bisect` or simply checking out earlier checkpoints tells you which run introduced the problem, which is most of the diagnosis. The rest is covered in debugging AI-generated code.