Git Workflows with AI — Commits, PRs, and Branching Strategies

AI writes code fast. That speed creates a new problem: your git history becomes a mess. You end up with massive commits titled “implement feature,” PRs with 50 changed files, and no way to tell which code a human wrote and which code AI generated.

Good git hygiene matters more in an AI-first workflow, not less. This article covers practical git patterns for AI-assisted development — from commit structure to PR workflows to attribution tracking.

The Problem with AI-Generated Commits

When you code without AI, your commits naturally follow the rhythm of your work. You write a function, commit. Fix a bug, commit. Add a test, commit. Each commit represents one logical change.

When AI generates code, this rhythm breaks. AI can produce 10 files in 30 seconds. If you accept them all and commit, you get one giant commit that mixes schema changes, business logic, tests, and configuration updates.

This matters because:

• Code review becomes harder. Reviewers cannot follow the logic of a 50-file commit.
• Reverting is risky. If one part of a giant commit introduces a bug, reverting it also removes all the good code.
• Bisecting breaks. git bisect only works well when each commit is a single logical change.
• History is unreadable. Six months from now, you cannot understand what happened just by reading commit messages.

Rule 1: Commit After Each AI Step

The simplest rule: treat each AI prompt-response cycle as one commit boundary. You prompt AI, review the output, fix any issues, and then commit. Do not stack multiple AI generations before committing.

Example workflow:

# Step 1: AI generates the database schema
# Review it, fix issues, then:
git add prisma/schema.prisma
git commit -m "Add note and user schemas for notes API

Define Note and User models with relations.
Room for future category support via string field.

Co-authored-by: Claude <noreply@anthropic.com>"

# Step 2: AI generates the repository layer
# Review it, fix issues, then:
git add src/repositories/
git commit -m "Add note repository with CRUD operations

Includes pagination, search by title/content,
and ownership verification on all operations.

Co-authored-by: Claude <noreply@anthropic.com>"

# Step 3: You manually fix a bug AI missed
git add src/repositories/noteRepository.ts
git commit -m "Fix case-insensitive search in note repository

AI-generated search used case-sensitive LIKE query.
Added COLLATE NOCASE for SQLite compatibility."

Notice the third commit does not have a Co-authored-by trailer — because you wrote that fix yourself. This distinction matters for attribution tracking.

Rule 2: Use Conventional Commits

Conventional commits give your history structure. They are especially valuable when AI contributes because they make it easy to scan the log and understand what changed.

Format:

<type>(<scope>): <description>

[optional body]

[optional footer: Co-authored-by]

Types that work well for AI-assisted development:

Example log from an AI-assisted session:

feat(auth): add JWT authentication middleware
fix(auth): handle malformed token format
feat(notes): add CRUD endpoints for notes
test(notes): add integration tests for notes API
fix(notes): correct pagination offset calculation
refactor(notes): extract validation to shared middleware
chore: update Prisma to 6.2.0

Each commit is small, focused, and tells you exactly what changed. Reviewers can skim the log and drill into specific commits.

Rule 3: Track AI Contributions with Co-Authored-By

The Co-authored-by trailer is the standard way to attribute AI contributions in git. Claude Code adds it automatically. You should add it manually when using other AI tools.

Format:

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <noreply@github.com>

Why track AI contributions?

1. Audit trail. You can query your git history to see what percentage of commits involved AI assistance. git log --grep="Co-authored-by: Claude" --oneline | wc -l gives you a count.

2. Review prioritization. AI-assisted commits may need different review attention than human-written commits. Some teams apply stricter review to AI-generated code.

3. Open source transparency. Many open source projects require disclosure of AI-assisted contributions. Being transparent about your tools builds trust with maintainers.

4. Debugging context. When you hit a bug and run git blame, knowing that a line was AI-generated tells you something about the likely failure mode. AI-generated code tends to have different bug patterns than human-written code.

Automating the trailer:

If you want every commit from a Claude Code session to include the trailer automatically, add this to your project’s CLAUDE.md:

When making git commits, always include:
Co-authored-by: Claude <noreply@anthropic.com>

For other tools, you can use a prepare-commit-msg git hook:

#!/bin/sh
# .git/hooks/prepare-commit-msg
# Add Co-authored-by trailer if AI tool is running

if [ -n "$AI_ASSISTED" ]; then
  echo "" >> "$1"
  echo "Co-authored-by: AI Assistant <noreply@example.com>" >> "$1"
fi

Set AI_ASSISTED=1 in your environment when using AI tools.

Rule 4: Structure AI-Generated PRs

When AI generates a large feature, the PR structure matters as much as the code quality.

The multi-commit PR pattern:

Instead of one PR with one massive commit, structure the PR as a series of logical commits that reviewers can follow step by step.

PR: Add notification system

Commits:
1. feat(db): add notification schema and migration
2. feat(notifications): add notification service
3. feat(notifications): add email notification provider
4. feat(notifications): add in-app notification provider
5. feat(api): add notification preference endpoints
6. feat(ui): add notification bell component
7. test(notifications): add integration tests
8. docs: add notification system documentation

Each commit builds on the previous one. A reviewer can follow the progression and understand the design decisions at each step.

PR description template for AI-generated features:

## Summary
One paragraph describing what this PR does and why.

## AI Tools Used
- Claude Code: database schema, service layer, tests
- Cursor: UI components
- Copilot: inline completions

## Changes
- [Commit 1 description]
- [Commit 2 description]
- ...

## Manual Changes
List any code you wrote or fixed manually:
- Fixed pagination offset (commit 5)
- Added error handling for email failures (commit 3)

## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed

## Review Notes
Areas that need extra attention:
- Auth middleware in commit 2 — security-sensitive
- Email template rendering in commit 3 — check edge cases

The “AI Tools Used” and “Manual Changes” sections are optional but valuable. They tell the reviewer where to focus their attention.

Rule 5: Branching Strategy

Your branching strategy does not change much with AI, but there are some useful patterns.

Feature branches remain the standard. One branch per feature, whether the code is AI-generated or not. The branch isolates AI work and gives you a clean rollback point.

The “AI exploration” branch. When you want AI to try a different approach without polluting your feature branch:

# Create an exploration branch
git checkout -b feat/auth-explore
# Let AI try approach A
# Review the result

# If it looks good, cherry-pick into the feature branch
git checkout feat/auth
git cherry-pick abc123

# If it does not work, delete the branch
git branch -D feat/auth-explore

This pattern is useful because AI sometimes generates a complete solution that turns out to be the wrong approach. On an exploration branch, you can discard it without losing any work on your main feature branch.

The stacked commit approach for large features:

For features that take multiple AI sessions:

# Session 1: Set up the data layer
git checkout -b feat/notifications
# AI generates schema + repository
git commit -m "feat(db): add notification schema"

# Session 2 (next day): Add the service layer
# AI generates service + providers
git commit -m "feat(notifications): add notification service"

# Session 3: Add the UI
# AI generates components
git commit -m "feat(ui): add notification components"

# Clean up before PR
git rebase -i main
# Squash fixup commits, keep logical commits

Git Blame in an AI World

git blame shows who wrote each line of code. When AI writes code, blame points to you — because you committed it. But you did not write it in the traditional sense.

Practical approach: Do not try to track line-level AI attribution. It is not practical and not useful. Instead, track at the commit level with Co-authored-by trailers. When you run git blame and see a line that looks suspicious, check the commit — if it has a Co-authored-by trailer, you know AI was involved.

The git log approach:

# See all AI-assisted commits
git log --grep="Co-authored-by: Claude" --oneline

# Count AI-assisted vs human-only commits
echo "AI-assisted: $(git log --grep='Co-authored-by: Claude' --oneline | wc -l)"
echo "Human-only: $(git log --all-match --invert-grep --grep='Co-authored-by: Claude' --oneline | wc -l)"

Code Ownership and Review

When AI generates code, who owns it? In practice, the developer who prompted, reviewed, and committed the code is the owner. They are responsible for its quality, security, and maintenance.

Review assignments:

• AI-generated auth or security code: assign to your security-focused team member
• AI-generated database code: assign to someone familiar with the data model
• AI-generated UI code: assign to a frontend specialist
• AI-generated tests: review the test logic, not just whether they pass

Review checklist for AI-generated PRs:

1. Does every commit represent a single logical change?
2. Are Co-authored-by trailers present on AI-assisted commits?
3. Are there any hardcoded secrets or credentials?
4. Does the code follow project conventions (naming, structure, error handling)?
5. Are there obvious AI patterns (overly verbose comments, unnecessary abstractions)?
6. Have security-sensitive areas been reviewed with extra care?
7. Do the tests actually test meaningful behavior (not just happy paths)?

Real Workflow Example

Here is a real workflow from a recent feature build — from AI generation to a clean, reviewable PR.

# 1. Create feature branch
git checkout -b feat/user-preferences

# 2. AI generates the schema
# Prompt: "Add user preferences table..."
# Review, fix, commit:
git add prisma/schema.prisma prisma/migrations/
git commit -m "feat(db): add user preferences schema

Stores notification, theme, and language preferences.
Defaults to email notifications on, dark theme, English.

Co-authored-by: Claude <noreply@anthropic.com>"

# 3. AI generates the API endpoints
# Prompt: "Create GET and PUT /api/preferences..."
# Review, fix one validation issue, commit:
git add src/routes/preferences.ts src/schemas/preferences.ts
git commit -m "feat(api): add preferences endpoints

GET returns current preferences, PUT updates them.
Zod validation on all fields with sensible defaults.

Co-authored-by: Claude <noreply@anthropic.com>"

# 4. I manually fix a bug AI missed
git add src/routes/preferences.ts
git commit -m "fix(api): handle missing preferences for new users

AI assumed preferences always exist. New users have no
row in the preferences table. Added fallback to defaults."

# 5. AI generates tests
# Prompt: "Write integration tests for preferences..."
# Review, fix test setup, commit:
git add tests/preferences.test.ts
git commit -m "test(api): add preferences integration tests

8 tests covering CRUD, defaults, validation errors.

Co-authored-by: Claude <noreply@anthropic.com>"

# 6. Push and create PR
git push -u origin feat/user-preferences

Four commits. Three AI-assisted, one manual fix. Clean, reviewable, and the history tells a clear story.

Key Takeaways

• Commit after each AI step. Do not stack multiple AI generations into one commit.
• Use conventional commits. They add structure that is especially valuable for AI-assisted work.
• Track AI contributions with Co-authored-by. It is the standard, it is easy, and it provides a useful audit trail.
• Structure PRs as a series of logical commits. Include context about which tools were used and which code was manually written.
• You own the code. Even if AI wrote it, you reviewed and committed it. You are responsible for its quality.
• Branch for exploration. Use throwaway branches when AI tries approaches that might not work.

What’s Next?

In the next article, you will learn how to measure your AI coding productivity with real data — tokens spent, time saved, code quality, and ROI calculations.

Part 23 of the Vibe Coding series.