Git Workflows with AI Coding Assistants

Git Workflows with AI Coding Assistants

AI coding assistants generate code fast. Really fast. And that speed changes the dynamics of version control in ways that catch teams off guard.

When a developer can produce hundreds of lines of working code in minutes, traditional git workflows -- long-lived feature branches, infrequent commits, manual PR descriptions -- start to break down. Merge conflicts multiply. Code review becomes overwhelming. And the "undo" problem gets serious: if an AI agent goes sideways on a 200-line change and you haven't committed recently, you're reverting by hand.

This guide covers the git patterns that work best when AI is writing a significant portion of your code. Whether you're using Claude Code, Gemini CLI, Codex CLI, or Aider, these practices will keep your version control sane and your team productive.

Why Git Workflow Matters More with AI

Without AI, a developer might produce 50-200 lines of meaningful code per day. With AI, that number can jump to 500-2,000 or more. This changes three things about your git workflow:

1. Volume of changes per session increases dramatically. More code per hour means more potential for merge conflicts, more to review, and more to revert if something goes wrong.

2. The cost of losing work increases. If an AI agent spends 10 minutes generating a complex implementation and you haven't committed, a crash or a wrong turn destroys that work. Manual recovery from memory isn't an option because you didn't write the code.

3. Review burden shifts. When code is AI-generated, reviewers need to read more carefully, not less. Understanding the "why" behind code you didn't write takes more effort than reviewing code a colleague wrote with clear intent.

Good git practices don't just help -- they become essential.

Worktrees for Parallel Sessions

Git worktrees are the single most underused feature for AI-assisted development. If you're running multiple AI sessions on the same repository (or even one AI session while you work in another branch), worktrees eliminate a whole category of problems.

What Worktrees Give You

A git worktree creates an additional working directory for your repository. Each worktree has its own checked-out branch and working files, but they all share the same .git directory. This means:

• No interference between sessions. One AI agent can be refactoring authentication in one worktree while another is building a new API endpoint in a different worktree. Neither affects the other's working state.
• No stashing required. Without worktrees, switching between tasks means stashing or committing incomplete work. With worktrees, each task lives in its own directory.
• Parallel CI. Each worktree can push to its own branch and trigger independent CI runs.

Practical Setup

# You're in the main working directory
# Create a worktree for an AI task
git worktree add ../project-auth-refactor feature/auth-refactor
git worktree add ../project-api-endpoints feature/new-api-endpoints

# Run AI agents in each worktree
# Terminal 1:
cd ../project-auth-refactor && claude

# Terminal 2:
cd ../project-api-endpoints && claude

When the task is done:

# Clean up
git worktree remove ../project-auth-refactor
git worktree remove ../project-api-endpoints

Worktrees and Agent Teams

Claude Code supports an "agent teams" pattern where a primary agent delegates sub-tasks to secondary agents. Each sub-agent can operate in its own worktree, working on an isolated branch. This enables genuinely parallel AI development -- multiple agents working on different parts of a feature simultaneously, merging their work when complete.

This pattern is especially effective for larger features that can be decomposed into independent pieces: one agent handles the database migration, another handles the API layer, another handles the frontend components. Our best practices guide covers how to configure agents for this kind of parallel work.

The Commit-Early Strategy

With AI-generated code, the optimal commit frequency is much higher than with manual coding. Here's why and how.

Why Frequent Commits Matter More

When you write code yourself, you can usually reconstruct your intent and approach from memory if you need to revert. When AI writes code, you often can't. The implementation might use patterns or approaches you wouldn't have chosen, and recreating the exact prompt-and-response sequence that produced it is impractical.

Frequent commits are restore points. They let you:

• Roll back a specific AI-generated change without losing other work
• Compare the AI's approach at different stages
• Bisect effectively when bugs are introduced
• Maintain a clear history of what the AI produced versus what you modified

The Cadence

A practical rhythm for AI-assisted development:

1. Commit after every successful AI generation that you've reviewed and accepted
2. Commit before asking the AI for the next major change (so you have a clean restore point)
3. Commit after manual refinements to AI-generated code (separating AI output from human edits makes review easier)

This might mean 10-20 commits per feature instead of 3-5. That's fine. You can squash before merging if your team prefers clean history on the main branch.

Let AI Draft Commit Messages

One nice side benefit: AI coding CLIs are excellent at generating commit messages. Claude Code can read the diff and produce a descriptive message. This removes the friction of frequent commits -- you don't need to manually write a message for each one.

# Claude Code can create commits with descriptive messages
# Just ask: "commit these changes with a descriptive message"

Aider takes this further by automatically committing every change it makes, with descriptive messages generated from the diff. This means you get a granular history of every AI-generated modification without any manual effort.

Branch Management

AI-assisted development favors a specific branching pattern: short-lived feature branches, one per AI task.

One Branch Per AI Task

When you ask an AI agent to implement a feature, refactor a module, or fix a bug, do it on a dedicated branch. This provides:

• Isolation: If the AI produces something unusable, you discard the branch. No cleanup needed on your main working branch.
• Clean diffs: The PR for that branch shows exactly what the AI produced (plus your refinements), making review straightforward.
• Parallel work: Multiple branches can be in flight simultaneously (especially with worktrees).

Keep Branches Short-Lived

Long-lived branches and AI-generated code are a particularly bad combination. Here's why:

• AI doesn't know about changes on other branches. The longer your branch lives, the more it diverges from main, and the more likely the AI's code will conflict with work merged by others.
• Large, long-lived branches with AI-generated code are exhausting to review. Reviewers lose context and start rubber-stamping.
• Merge conflicts in AI-generated code are harder to resolve because you may not fully understand the AI's implementation choices.

Target: branches should live for hours to days, not weeks. If a task is too large for a short-lived branch, decompose it into smaller AI tasks, each on its own branch, merged sequentially.

Automated CI/CD on AI-Generated Branches

Every branch with AI-generated code should trigger your full CI/CD pipeline. Don't wait until the PR is opened. Configure your CI to run on all pushes to feature branches, so you get fast feedback on whether the AI's code passes your test suite, linter, and security checks.

This is especially important because AI-generated code often passes a superficial "does it look right?" check but fails on edge cases that your test suite catches. The earlier you know, the less rework is needed.

Pull Request Best Practices

The PR review process needs specific adjustments for AI-generated code.

Tag AI-Generated PRs

Use a consistent label or tag (ai-generated, ai-assisted, or similar) on PRs that contain AI-generated code. This serves multiple purposes:

• Reviewers know to apply additional scrutiny
• You can track metrics on AI-generated PRs separately (merge time, defect rate, revert rate)
• Compliance and audit teams can identify AI-generated changes

Require Extra Approvals

Some teams require an additional reviewer for AI-generated PRs. This isn't bureaucracy for its own sake -- it reflects the reality that AI-generated code needs more careful review. A common pattern:

• Human-written PRs: 1 approval required
• AI-assisted PRs: 2 approvals required, at least one from a senior developer

Higher Test Coverage Thresholds

If your standard coverage threshold is 80%, consider requiring 90% for AI-generated code. The rationale:

1. AI can generate tests quickly, so higher coverage isn't a burden
2. AI-generated code is more likely to have subtle bugs in edge cases
3. Tests serve as documentation for code that the human reviewer may not fully understand

AI-on-AI Code Review as First Pass

Before a human reviews an AI-generated PR, run another AI model over it. This "AI-on-AI review" pattern catches a surprising number of issues:

• Security vulnerabilities the generating model missed
• Performance problems (unnecessary database queries, N+1 patterns)
• Convention violations specific to your codebase
• Logic errors that a different model's perspective can catch

Tools like Graphite offer automated AI code review. Or you can build this into your pipeline by having Claude Code or Gemini CLI review diffs as a CI step. The cross-model approach we described in our best practices article applies directly here.

Human Oversight Remains Critical

AI-on-AI review is a supplement, not a replacement. Human reviewers should still focus on:

• Business logic correctness: Does this actually solve the right problem?
• Architectural fit: Does this change fit within the system's design?
• Security implications: Are there attack vectors the AI didn't consider?
• Maintainability: Will someone understand this code in six months?

These are judgment calls that require understanding of context beyond what's in the codebase.

Tool-Specific Git Integration

Different AI coding CLIs handle git differently. Understanding these differences helps you choose the right workflow for each tool.

Aider

Aider is the most git-native of the major CLI tools. It:

• Automatically commits every change it makes
• Generates descriptive commit messages from the diff
• Can be configured to work on specific branches
• Maintains a clean, granular git history by default

If you're using Aider, you largely don't need to think about commit discipline -- it handles it for you. The tradeoff is less control over when and how commits are made.

Claude Code

Claude Code has deep built-in git awareness. It can:

• Create commits with descriptive messages
• Create and switch branches
• Create pull requests (including GitHub PR creation via gh)
• Read git history and diffs as context for its work
• Understand the current branch, staging state, and recent changes

Claude Code's git integration is flexible -- it can handle git operations when you ask, but doesn't force automatic commits. This makes it adaptable to different team workflows. You can choose between asking Claude to commit frequently or managing commits yourself.

For pricing on the different Claude Code plans that support these features, see our Claude Code pricing breakdown.

Codex CLI

Codex CLI operates in a sandboxed environment where git operations are available but contained. Key characteristics:

• Changes are made in a sandbox and applied to your working directory when accepted
• Git operations are available within the sandbox
• The sandboxed approach provides a natural "review before apply" gate
• Network access is restricted by default, so remote git operations (push, fetch) require configuration

Codex CLI's sandbox model aligns well with a cautious git workflow -- you review and commit manually after accepting the AI's changes. Our Codex subscription guide covers which plans support the full sandbox capabilities.

The Pre-Commit Safety Net

Pre-commit hooks are your last line of defense before AI-generated code enters your git history. They should be non-negotiable for any team using AI coding tools.

Essential Pre-Commit Checks

Configuration

Use a framework like pre-commit or husky to manage hooks consistently across the team:

# .pre-commit-config.yaml example
repos:
  - repo: local
    hooks:
      - id: lint
        name: lint
        entry: npm run lint
        language: system
        pass_filenames: false
      - id: typecheck
        name: typecheck
        entry: npm run typecheck
        language: system
        pass_filenames: false
      - id: secrets
        name: detect secrets
        entry: gitleaks protect --staged
        language: system
        pass_filenames: false

What to Store in Version Control

• Store your CLAUDE.md, AGENTS.md, and project configuration files. These are essential context for anyone (or any AI) working on the project.
• Store your pre-commit hook configuration.
• Do not store files that contain secrets, API keys, or personal configuration. Add these to .gitignore.

A typical .gitignore addition for AI coding tools:

# AI tool local config (may contain secrets or personal preferences)
.claude/settings.local.json
.aider.env

But do commit:

# AI tool project config (shared team conventions)
CLAUDE.md
.claude/skills/
AGENTS.md

Putting It Together

Here's a complete workflow that incorporates all the practices above:

1. Start a task: Create a feature branch and (optionally) a worktree
2. Configure the agent: Ensure CLAUDE.md and skill files are up to date
3. Generate code: Run your AI CLI tool in the worktree
4. Commit frequently: After each meaningful generation or refinement
5. Run local checks: Pre-commit hooks catch issues before they enter history
6. Push and trigger CI: Automated pipeline validates the AI's output
7. AI-on-AI review: Another model reviews the diff as a CI step
8. Open a tagged PR: Label it as AI-generated, add appropriate reviewers
9. Human review: Focus on logic, security, and architectural fit
10. Merge and clean up: Squash if desired, remove the worktree

This workflow adds minimal overhead to the AI-assisted development process while providing the safety nets that keep AI-generated code from becoming a maintenance burden.

The speed of AI-generated code is only an advantage if your version control practices can keep up. Invest the time to set up these workflows once, and they'll pay dividends on every AI-assisted task your team takes on.

For a broader view of how these git practices fit into a complete AI coding CLI strategy, see our Best Practices for AI Coding CLIs in Production guide. And if you're still evaluating which CLI tool to adopt, our comparison of Gemini CLI, Claude Code, and Codex covers the differences that matter for day-to-day development.