Fixing "fatal: rebase in progress" in Git

What this error means

Git reports "fatal: rebase in progress" when a previous rebase has not finished and you try to start another operation that conflicts with it (e.g., pull, merge, or another rebase). You must either continue or abort the in-progress rebase.

Typical causes:

• You started a rebase and hit a conflict but didn't resolve it.
• A previous rebase was interrupted (crash, editor closed, CI canceled).
• A script attempted another operation while a rebase was active.

Quickstart (most cases)

1. Check status: git status (it will say "You are currently rebasing").
2. Decide:
   • Continue the rebase after resolving conflicts: git rebase --continue.
   • Abort and return to the original branch state: git rebase --abort.
   • Stop tracking the rebase but keep current worktree changes: git rebase --quit.
3. If conflicts exist:
   • Fix files, git add <files>, then git rebase --continue.
4. If the rebase seems stuck or corrupt:
   • Try git rebase --abort or git rebase --quit.
   • As a last resort, back up and remove .git/rebase-merge or .git/rebase-apply after verifying with git status.

Minimal working example (reproduce and fix)

# Start a demo repo
mkdir demo-rebase && cd demo-rebase
git init
git branch -M main
echo "line" > file.txt
git add file.txt
git commit -m "init"

# Create a feature branch and change the same line
git checkout -b feature
echo "feature change" > file.txt
git commit -am "feature edit"

# Diverge main with a conflicting change
git checkout main
echo "main change" > file.txt
git commit -am "main edit"

# Start a rebase that will conflict
git checkout feature
git rebase main
# Resolve conflict now OR simulate the fatal message by attempting another op:
# (this triggers: fatal: rebase in progress)
# git merge main

# Proper fix: resolve and continue
# Edit file.txt to the desired content
printf "resolved content\n" > file.txt

git add file.txt
git rebase --continue

# Verify history is linear and clean
git log --oneline --graph --decorate --all

Step-by-step resolution guide

1. Detect rebase state

   • Run: git status
   • Look for: "rebase in progress; onto <commit>" or "You are currently rebasing".
   • Internal markers: .git/rebase-merge/ or .git/rebase-apply/ exist.

2. Choose an outcome

   • Keep the rebase: resolve conflicts, then git rebase --continue.
   • Cancel the rebase and restore pre-rebase state: git rebase --abort.
   • Exit rebase bookkeeping but keep current changes: git rebase --quit.

3. Resolve conflicts (if any)

   • Open conflicted files, choose the correct content.
   • Mark resolved: git add <files>.
   • Continue: git rebase --continue.
   • If the next commit also conflicts, repeat until done.

4. Verify and push

   • Inspect: git log --oneline --graph
   • If you rebased commits that are already pushed, you will need git push --force-with-lease to update the remote safely.

Common situations and commands

Recovering from a stuck or stale rebase

If your repo was interrupted (power loss, CI cancellation) and Git complains about an in-progress rebase:

• Try the safe exits first:

  • git rebase --abort (preferred)
  • git rebase --quit (if you want to keep current worktree changes)

• If those fail, inspect state:

  • test -d .git/rebase-merge && echo merge-mode or test -d .git/rebase-apply && echo apply-mode
  • git status to see which files are staged or conflicted

• Manual cleanup (last resort):

  • Back up your branch: git branch backup/<name>
  • Remove the rebase dir: rm -rf .git/rebase-merge .git/rebase-apply
  • Optionally restore to pre-rebase commit: git reset --hard ORIG_HEAD (destructive; ensure backup)

• Use reflog for recovery:

  • git reflog shows recent HEAD positions
  • git reset --hard <reflog-id> to return to a known-good state

DevOps-focused practices

• Pre-merge checks: Require clean working trees and no ongoing rebase in CI before running release jobs.
• Safer updates: Use git pull --rebase --autostash in automation to avoid merge commits and reduce conflicts.
• Protect shared history: When rebasing commits that have been pushed, coordinate and use --force-with-lease in CI to avoid overwriting teammates' work.
• Re-run conflict resolutions faster: git config rerere.enabled true to have Git remember conflict resolutions across rebases.

Performance notes

• Rebasing large stacks is O(number of commits). Limit scope with:
  • git rebase --rebase-merges to preserve structure when necessary (can reduce conflict churn).
  • git rebase -i --autosquash to squash fixups and reduce the number of applied commits.
• Avoid repeatedly rebasing long-lived branches against fast-moving main; rebase just before integration.
• Use shallow clones in CI only if you do not need to rewrite deep history.

Pitfalls and how to avoid them

• Force pushing after rebase without --force-with-lease can clobber teammates’ changes. Always prefer --force-with-lease.
• Manually deleting rebase state without a backup can lose work. Create a safety branch first.
• Mixing merge and rebase on the same branch can create confusing histories. Pick a strategy per branch.
• Running new Git operations during a rebase triggers the fatal error. Finish or abort the rebase first.

Tiny FAQ

• Q: Should I use --abort or --quit?
  • A: --abort restores the pre-rebase commit; --quit stops the rebase bookkeeping but keeps current index/worktree.
• Q: Will aborting delete my uncommitted changes?
  • A: It restores the branch tip; local changes may be preserved or conflicted. Stash first if unsure: git stash -u.
• Q: How do I know what commit I started from?
  • A: ORIG_HEAD points to it. See git log -1 ORIG_HEAD or git reflog.
• Q: Can I fix the error by pulling?
  • A: No. Complete or abort the rebase first; then git pull --rebase if desired.