Aider during a git rebase: managing AI commits when history is in flux

Published 2026-03-28 by Owner

Aider auto-commits after every successful edit. During an interactive rebase, you’re editing commits already in flight. Combine the two and aider can produce orphan commits, duplicate work, or worse, accidentally amend a commit you’re trying to preserve.

The three patterns below cover the cases I’ve hit.

Pattern 1: turn auto-commits off during rebase

The simplest fix: disable auto-commits while rebasing.

git rebase -i HEAD~5
# git opens the rebase editor; mark commits as 'edit' as needed
# in another terminal:
aider --no-auto-commits

Aider produces edits but doesn’t commit. You commit manually with git commit --amend or by continuing the rebase. This avoids any conflict with the rebase’s commit ordering.

The downside: you lose the per-edit commit log that aider produces. For longer rebase sessions where you want to track progress, this matters.

Pattern 2: use git worktrees

For larger refactors during a rebase:

# from main worktree
git worktree add ../proj-rebase HEAD
cd ../proj-rebase
git rebase -i HEAD~5

# in another terminal
cd ../proj-aider
aider  # auto-commits on, in this worktree

The aider worktree commits to the original branch as usual. The rebase worktree manipulates history in isolation. When the rebase is done, you cherry-pick the aider commits onto the rebased branch.

This is more setup than pattern 1 but cleaner for situations where aider is doing meaningful new work in parallel with the rebase.

Pattern 3: aider for fixing rebase conflicts

A useful pattern: when a rebase produces conflicts, aider can resolve them.

git rebase main
# CONFLICT in path/to/file.ts

aider path/to/file.ts
> /add path/to/file.ts
> resolve the merge conflict in this file
> the goal is to keep the changes from "feature" branch while accepting the
> renaming changes from "main"

The aider workflow during a conflict:

Aider reads the file with conflict markers
You describe what the resolution should look like
Aider produces the resolved file
You inspect, accept if right
git add and git rebase --continue

This is faster than manual resolution for non-trivial conflicts. The model is good at understanding the intent of both sides and producing a sensible merge.

The mistake to avoid: don’t enable auto-commits in this mode. Aider would commit the resolved file to the rebase, which would confuse git rebase --continue. Resolve, exit aider, then continue the rebase.

What goes wrong without these patterns

The default behavior — aider auto-committing during an active rebase — fails in interesting ways:

Aider commits to “rebase HEAD.” During an interactive rebase, HEAD points to a temporary state. Aider’s commits land there. When you continue the rebase, aider’s commits are intermixed with the rebase’s reordering. Disentangling is unpleasant.

Aider amends the wrong commit. With --amend enabled (some configs do this), aider can amend the commit being edited in an interactive rebase, instead of creating a new commit. Side effect: you lose the original commit’s metadata.

Conflicts during continued rebase. If aider’s edits during a rebase touch the same lines as a later commit in the rebase, you get conflicts when continuing. The conflicts are confusing because they’re between aider’s mid-rebase changes and your historical changes.

These are recoverable but painful. The patterns above prevent them entirely.

Recovering from a tangled rebase

If you’ve already gotten into a tangled state (aider committed during a rebase and now the rebase won’t continue), the recovery:

# stop the rebase
git rebase --abort

# inspect what aider did
git reflog
# find the commits aider made and any pre-rebase state

# cherry-pick aider's commits onto the desired base
git checkout your-target-branch
git cherry-pick <aider-commit-sha>...

This works most of the time. For severely tangled states, sometimes the cleanest path is git reset --hard to a known-good reflog entry and redoing the rebase manually.

A rule for your editor’s workflow

If you’re regularly using aider during rebases, add to your shell aliases:

alias aider-rebase='aider --no-auto-commits'
alias rebase-i='git rebase -i'

The aider-rebase alias is the everyday “I’m rebasing, don’t auto-commit” mode. The cognitive overhead of remembering to disable auto-commits drops to zero.

For teams: this could go in a CONTRIBUTING.md or shared shell config. Anyone using aider during rebases benefits from the pattern; you don’t have to teach it twice.

When aider is the wrong tool during rebase

Some rebase tasks aider doesn’t help with:

Reordering commits. Pure git operation. No code changes. Aider has nothing to add.

Squashing commits. Likewise. The squash is git’s job.

Splitting one commit into two. This requires partial-staging, which is a manual git operation. Aider can suggest how to split (which lines belong to which commit) but the actual splitting is manual.

For these, just use git directly. Aider’s value during rebase is in conflict resolution and in continued code work, not in the rebase mechanics themselves.