Coding agents change the unit of work in Git. A human may make a handful of deliberate edits; an agent can touch dozens of files, run migrations and generate a plausible explanation before anyone has reviewed the assumptions.

The answer is not to avoid automation. It is to make Git the containment and approval system around it. This guide assumes you already know basic Git commands and focuses on workflows for AI-generated changes. See the coding agents hub for tool selection.

Give every agent task an isolated branch

Never let an unattended agent work directly on main. Start from an updated base and use a task-specific branch:

git fetch origin
git switch main
git pull --ff-only
git switch -c agent/fix-checkout-timeout

Use a name that describes the outcome, not the agent product. The branch should remain understandable after tools change.

For concurrent tasks, use worktrees so agents do not share an index or overwrite each other’s files:

git worktree add ../work-checkout -b agent/fix-checkout origin/main
git worktree add ../work-evals -b agent/add-evals origin/main

Isolation reduces accidental cross-task changes, but it does not validate correctness. Each worktree still needs scope checks and tests.

Make commits reviewable

Agent-generated commits should be smaller than the context window needed to understand them. Separate concerns such as schema changes, application logic and generated artefacts.

Before accepting a commit, inspect:

git status --short
git diff --stat
git diff --check
git diff -- src/path/in-scope

Require the agent to report:

• files changed and why;
• tests actually executed;
• assumptions it could not verify;
• generated files included or excluded;
• migrations, credentials or external side effects.

Do not accept a large commit merely because its message is confident.

Protect human-owned changes

An agent should treat existing uncommitted changes as user-owned. It must not reset, overwrite or reformat unrelated work to make its patch cleaner.

Before starting:

git status --short
git diff --name-only

If the task overlaps a dirty file, either preserve the existing edits explicitly or stop for a decision. Stashing another person’s changes without a clear recovery plan is not safe automation.

Use pull requests as an approval boundary

A pull request should answer four questions:

1. What user-visible or operational outcome changes?
2. Which assumptions were made by the agent?
3. What evidence proves the change works?
4. How can it be rolled back?

Require review for security rules, billing, data deletion, authentication, infrastructure and production configuration. A green build is necessary but cannot approve product intent.

Use CODEOWNERS or branch rules to require the right reviewer. Agent identity should be visible in commit metadata or PR notes without pretending the agent is the accountable author.

CI checks for generated code

CI should distrust the explanation and evaluate the repository:

• formatting and type checks;
• unit and integration tests;
• migration validation;
• secret scanning;
• dependency and licence checks;
• generated-file drift checks;
• focused evaluations for model-dependent features;
• production build and link checks for content sites.

The GitHub Actions foundation shows how to build these gates. Deployment checks belong in the AI operations layer.

Resolve conflicts without hiding intent

Agents often resolve conflicts syntactically while losing one side’s behaviour. During a rebase or merge, review the original base, both versions and the combined result.

git diff --check
git diff origin/main...HEAD
git range-diff origin/main...agent/old origin/main...agent/rebased

After conflict resolution, rerun the tests relevant to both branches. Do not accept “conflicts resolved” as evidence that semantics survived.

For repetitive conflicts, fix task boundaries or shared ownership instead of teaching agents to force-resolve the same files.

Roll back safely

On shared branches, prefer a revert over rewriting history:

git revert <commit>
git push origin main

Database and infrastructure changes may require a forward repair rather than a code-only revert. Record that limitation in the PR before deployment.

Tag releases or preserve deployment identifiers so the running version maps to a commit. A rollback plan that cannot identify the deployed commit is only a hope.

Recommended workflow

1. Human defines outcome, scope and forbidden changes.
2. Agent works in an isolated branch or worktree.
3. Agent runs focused checks and reports uncertainty.
4. CI independently builds, tests and scans the patch.
5. Human reviews the diff and user-facing behaviour.
6. Protected automation merges and deploys.
7. Monitoring confirms the production result.

Git is not just storage for AI-generated code. It is the audit trail, isolation boundary and recovery mechanism that makes coding agents usable in a real engineering team.