Fix 'fatal: You have not concluded your rebase' in Git

What this error means

Git found an unfinished rebase in your repository. You likely started a rebase, hit conflicts, and then tried another Git operation (e.g., rebase again, pull --rebase, merge, or switch branches). Git blocks the new action until you either finish or abort the current rebase.

Key idea: complete the current rebase with --continue or stop it with --abort.

Quickstart (most cases)

• Check status: git status
• Resolve conflicts in files, then stage them: git add <file>...
• Continue: git rebase --continue
• If you want to drop the conflicting commit: git rebase --skip
• If you want to cancel the rebase entirely: git rebase --abort

Minimal working example (reproduce and fix)

# 1) Setup a sample repo with a conflict
mkdir demo-rebase && cd demo-rebase
git init -b main
printf "line1\n" > app.txt
git add app.txt && git commit -m "init: add app.txt"

git checkout -b feature
printf "feature change\n" >> app.txt
git commit -am "feat: append feature change"

git checkout main
printf "main change\n" >> app.txt
git commit -am "main: append main change"

# 2) Start a rebase that will conflict
# Rebasing feature onto main
git checkout feature
git rebase main  # will report a conflict in app.txt

# 3) If you now try another rebase/pull, you’ll see the error
git pull --rebase  # fatal: You have not concluded your rebase

# 4) Fix the rebase properly
# Open app.txt, resolve the conflict, then:
git add app.txt
git rebase --continue  # finishes applying the remaining commits

# 5) Verify history
git log --oneline --graph --decorate --all

Example conflict file state (what you’ll edit):

<<<<<<< HEAD
main change
=======
feature change
>>>>>>> <commit-being-rebased>

Resolve it to the intended final content, save, then stage and continue.

Step-by-step resolution

1. Inspect the state

• Run: git status
• Look for “You are currently rebasing” and a list of conflicted files.

1. Identify the commit being applied

• git status usually shows which commit is in progress.
• Optional: git show REBASE_HEAD to inspect the patch that is being applied (if REBASE_HEAD exists).

1. Resolve conflicts

• Open each conflicted file and decide the correct content.
• Remove conflict markers (<<<<<<<, =======, >>>>>>>).
• Stage each resolved file: git add <file>

1. Continue, skip, or abort

• Continue when all conflicts are resolved: git rebase --continue
• Skip the commit if you intentionally want to drop it: git rebase --skip
• Abort the rebase to return to the pre-rebase state: git rebase --abort

1. Verify and clean up

• git log --oneline --graph to confirm the expected history.
• git status should no longer report a rebase in progress.

Common commands and when to use them

DevOps-focused tips

• In CI/CD scripts, ensure a clean workspace before rebase:
  • git reset --hard and git clean -ffd to avoid leftover state.
  • If a job can be interrupted mid-rebase, protect with: git rebase --abort || true before new fetch/merge steps.
• Enable conflict reuse to speed repeated rebases: git config rerere.enabled true.
• Favor smaller rebases: rebase and push frequently to reduce conflict surface.
• For shared branches, coordinate with your team to avoid force-push surprises after rebase.

Diagnostics and recovery

• Show what’s conflicting: git status lists files.
• See staged vs unstaged: git diff (unstaged), git diff --staged (staged).
• If you accidentally staged wrong content:
  • Unstage: git restore --staged <file> (or git reset <file>)
  • Edit, then re-stage.
• If you get stuck or the state looks wrong:
  • git rebase --abort to reset to pre-rebase.
  • git reflog to find prior positions; recover with git reset --hard <reflog-entry> if needed.

Pitfalls to avoid

• Running new Git operations mid-rebase: finish or abort first.
• Skipping without understanding the impact: --skip drops a commit; review with git show REBASE_HEAD first when possible.
• Editing only some conflicts: all conflicted files must be staged before --continue.
• Manual deletion of .git/rebase-* directories: prefer --abort; only consider manual cleanup if the repository is already corrupted and you understand the risk.
• CRLF vs LF differences: configure core.autocrlf or .gitattributes to prevent noisy conflicts.
• Binary or large-file conflicts: you must pick one side or re-create binaries; staging is still required.

Performance notes

• Rebase cost scales with number of commits and conflicts. Keep feature branches short-lived.
• Enable rerere to auto-apply previously recorded resolutions: git config rerere.enabled true.
• Use partial rebases to limit scope: git rebase --onto <base> <upstream> <branch>.
• For very large repos, run git fetch --prune --tags regularly and consider git gc during maintenance windows to keep operations snappy.

Tiny FAQ

• Q: Why do I see “fatal: You have not concluded your rebase”?
  A: A prior rebase is unfinished. Resolve conflicts and git rebase --continue, or --abort.

• Q: How do I know what I’m about to skip?
  A: Inspect the current patch with git show REBASE_HEAD (when available) or review the todo list with git rebase --edit-todo.

• Q: I resolved conflicts but Git still complains.
  A: Ensure all conflicted files are staged (git add <file>). Then run git rebase --continue.

• Q: Can I switch branches during a rebase?
  A: Not safely. Finish or abort the rebase first.

• Q: I aborted; can I get back to where I was?
  A: Use git reflog to find the previous HEAD and git reset --hard <entry> if you need to restore it.