Git Workflow & Commits

Aider's git integration is not a feature bolted on after the fact. It is the foundation. Every edit Aider makes is committed immediately with a descriptive message. Every commit is reversible with one command. You can review the diff, undo the last change, run raw git commands, and manage branches while Aider is running. If you understand Aider's git model, you understand Aider.

What you'll learn

• Aider auto-commits every change with a descriptive message generated from the diffs and chat history
• /undo reverts the last Aider commit instantly. The change is gone, the file is back to its previous state
• /diff shows what changed since your last message. Review before you commit to the next step
• /commit generates a commit message for any dirty changes you made outside of Aider
• /git <cmd> runs raw git commands without adding the output to the chat context
• Aider marks its commits with "(aider)" in the author metadata so you always know who wrote what

The problem

AI-generated code changes are fast. Too fast to track manually. If you make five prompts across three files and one of the changes breaks something, you need to know exactly which prompt introduced it. Without systematic version control, you are guessing. Aider solves this by making commits non-optional: every edit is a commit, every commit has a message, and every message tells you what the prompt was. The question is not "should I commit this?" but "how do I navigate the history Aider is building for me?"

Options & when to use each

Git feature	Aider command	When to use it
Auto-commit on edit	Automatic (default)	Every time Aider edits a file. No action required from you
Undo last change	/undo	You do not like the last edit. Instantly reverts the commit
Review current diff	/diff	You want to see what Aider changed before continuing
Commit external changes	/commit	You edited files yourself while Aider was running and want a commit message
Run any git command	/git <cmd>	You need to branch, merge, rebase, or check status without leaving Aider
Disable auto-commits	--no-auto-commits	You want to manage commits yourself. Changes are still made to files but not committed
Disable dirty commits	--no-dirty-commits	You do not want Aider to commit your uncommitted changes before it starts editing
Disable all git usage	--no-git	You are working outside git or have your own backup strategy. Not recommended

Auto-commits are the default because they are the right default. Disable them only when you have a specific workflow that conflicts.

Build it

Step 1: Understand the auto-commit lifecycle

When you send a prompt, Aider's lifecycle is:

1. Aider reads the current state of all files in the chat session
2. The LLM proposes edits as search/replace blocks
3. Aider applies the edits to the files on disk
4. Aider sends the diffs and chat history to a "weak model" to generate a commit message
5. Aider commits the changes

The commit message follows Conventional Commits format and includes the essence of your prompt. Example messages you will see:

aider: Write a Flask web app with greeting endpoint and server time
aider: Add pytest tests for the greeting endpoint
aider: Fix the greeting endpoint to handle missing timezone

Each message is a one-line summary of what changed and why. You can always see the full diff in the commit itself.

Step 2: Practice the undo loop

The most important git command in Aider is /undo. Create a file and make a change you want to revert:

cd ~/aider-practice
aider app.py

Instruct the agent to add a new endpoint. Aider will make the change and automatically commit it to the repository.

> Add a /health endpoint that returns {"status": "ok"}

Aider edits app.py, adds the endpoint, and commits. Now undo it:

> /undo

Aider reverts the last commit. The /health endpoint is gone, the file is back to its previous state. The undo is itself a git commit (a revert), so you can even undo the undo:

> /undo

Now the /health endpoint is back. This is the safety net that makes Aider safe to use: you can always go back.

Step 3: Review changes with /diff

Before you continue to the next prompt, review what just changed:

> /diff

Aider prints a unified diff of every file that changed since your last message. This is the same output you would see from git diff. Use it to verify that the change matches your intent before issuing the next prompt.

If the diff shows something unexpected, /undo and rephrase your prompt. You never have to accept a change you did not intend.

Step 4: Commit external changes with /commit

You can edit files yourself while Aider is running. Aider reads the latest version from disk before every prompt, so your changes are always visible. When you want to commit those external changes:

# In another terminal, edit app.py directly
echo "# Manual edit" >> app.py

Back in Aider, tell the agent to commit the dirty files. It will evaluate the diff and generate an appropriate commit message.

> /commit

Aider detects the dirty file, generates a commit message, and commits your changes. This is useful when you want to make a quick fix yourself but still want it tracked in the same git history.

If you prefer that Aider not commit your changes before it starts editing, use --no-dirty-commits. Aider will ask you to commit them yourself first.

Step 5: Run raw git commands with /git

The /git command lets you run any git command without leaving Aider. The output is displayed but not added to the chat context, so it does not consume tokens:

> /git branch
* main

> /git log --oneline -5
a1b2c3d aider: Add /health endpoint
e4f5g6h aider: Add pytest tests for the greeting endpoint
i7j8k9l aider: Write a Flask web app with greeting endpoint and server time
m0n1o2p Initial commit

Common /git workflows allow you to manage branches, check status, and review diffs without interrupting your session. Use these to maintain control over your repository state.

# Create a feature branch before a big change
> /git checkout -b feature/auth-endpoint

# Check what files are modified
> /git status

# Review the full diff of the last commit
> /git diff HEAD~1

# Stash changes if you want to switch contexts
> /git stash

You can also use /run instead of /git if you want the command output added to the chat context. This is useful for feeding git diffs into the conversation:

> /run git diff HEAD~3

Aider asks if you want to add the output to the chat. Say yes, and the LLM can see the last three commits of changes as context for your next prompt.

Step 6: Manage git history across a session

A long Aider session can produce dozens of commits. Use git outside of Aider to manage them:

# In another terminal, review the session's commits
git log --oneline --author="aider"

# Squash related commits if you want a cleaner history
git rebase -i HEAD~10

# Or just keep them. Aider's granular commits are useful for bisecting bugs
git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>

Aider does not squash commits for you. It produces one commit per prompt. This is intentional: granular commits make it easy to identify exactly which prompt introduced a regression.

Step 7: Customize commit behavior

Aider's git behavior is fully configurable. The most common options:

# Disable auto-commits (you commit manually)
aider --no-auto-commits

# Disable all git integration
aider --no-git

# Don't attribute commits to aider
aider --no-attribute-author --no-attribute-committer

# Prefix all commit messages with 'aider: '
aider --attribute-commit-message-committer

# Use a custom commit prompt template
aider --commit-prompt "Summarize this change in under 50 characters using imperative mood"

These can also be set in .aider.conf.yml for persistence.

What goes wrong

Mistake	How you notice it	The fix
/undo does not revert the change you expected	The file still has the unwanted edit after /undo	/undo only reverts the last Aider commit. If you made multiple changes, use /undo once per change, or use git log outside Aider to find the specific commit and git revert it
Aider refuses to edit a dirty file	Aider prints a warning about uncommitted changes	Aider will first commit your dirty changes, then make its own edit. If you disabled dirty commits (--no-dirty-commits), commit them yourself first, or re-enable dirty commits
Git history is cluttered with too many small commits	git log shows dozens of "aider:" commits from one session	This is normal and often useful. To clean up, use git rebase -i outside of Aider. Or use fewer, larger prompts to get fewer, larger commits
/git output is not visible in the chat history	You ran /git and the LLM cannot reference the output	/git output is intentionally excluded from chat context. Use /run git <cmd> instead if you want the output in the chat
Pre-commit hooks fail on Aider's commits	Aider commits fail with hook errors	By default, Aider skips pre-commit hooks with --no-verify. To run them, use --git-commit-verify
Accidentally committed sensitive data with /commit	API keys or secrets appear in git history	Aider commits whatever is in your files. Review diffs with /diff before /commit. If already committed, use git filter-branch or BFG Repo-Cleaner to remove the data

Confirm it worked

Run this sequence. If every step succeeds, you have mastered Aider's git integration:

# 1. Create a fresh repo
mkdir -p /tmp/aider-git-test && cd /tmp/aider-git-test && git init

# 2. Make an initial commit yourself
echo "# Git test" > README.md && git add README.md && git commit -m "Initial commit"

# 3. Launch Aider and make a change
aider --model sonnet --yes-always README.md -p "Add a line: '## Aider was here'"

# 4. Verify the auto-commit
git log --oneline -2
# Should show your initial commit and an "aider:" commit

# 5. Check that the commit has aider attribution
git log -1 --format="%an %cn"
# Should show "(aider)" in the author or committer name

# 6. Launch Aider again and test /undo
aider --model sonnet --yes-always README.md -p "Add a line: '## This will be undone'"

# 7. Undo that last change
aider --model sonnet --yes-always README.md -p "/undo"

# 8. Verify the line is gone
grep -c "This will be undone" README.md
# Should return 0

If the file has the correct content at each step and the git history shows clear, descriptive commits with aider attribution, you are ready to pair on real projects with full version control.

Next: Repository Map & Codebase Context