Git Rebase Conflict: How to Resolve (Tested)

A git rebase conflict happens when the commit git is replaying changes a line that the branch you're rebasing onto already changed differently. git marks the spot in the file with <<<<<<<, =======, and >>>>>>> — the same three markers a merge conflict uses, but labeled differently. We reproduced one from scratch and recorded exactly what git prints and writes.

1. How we reproduced it

We made one file, committed it, then branched and edited the same line differently on main and on feature before rebasing feature onto main.

git init -b main
git config user.email "test@example.com"
git config user.name "Test User"
printf "line1\nline2\nline3\n" > file.txt
git add file.txt
git commit -m "base commit"

git checkout -b feature
printf "line1\nFEATURE-CHANGE\nline3\n" > file.txt
git commit -am "feature: change line2"

git checkout main
printf "line1\nMAIN-CHANGE\nline3\n" > file.txt
git commit -am "main: change line2"

git checkout feature
git rebase main

git rebase main printed exactly:

Rebasing (1/1)Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
error: could not apply 286b0aa... feature: change line2
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Could not apply 286b0aa... feature: change line2

git rebase exited with status 1.

2. The markers look different from a merge conflict — here's exactly how

Here is the full content of file.txt after the conflicting rebase, byte for byte:

line1
<<<<<<< HEAD
MAIN-CHANGE
=======
FEATURE-CHANGE
>>>>>>> 286b0aa (feature: change line2)
line3

We ran the exact same two-line conflict through git merge instead, for comparison. Its markers:

line1
<<<<<<< HEAD
MAIN-CHANGE
=======
FEATURE-CHANGE
>>>>>>> feature
line3

The opening <<<<<<< HEAD line looks identical, but it means something different in each case:

• In a merge, we ran git merge feature while checked out on main, so HEAD is main, your current branch. The closing marker is labeled with the branch name being merged in: >>>>>>> feature.
• In a rebase, git had already moved HEAD onto main's tip before replaying feature's commit on top, so HEAD here means the branch being rebased onto — main, same content, different reason. The closing marker is labeled with the abbreviated commit hash and subject line of the commit being replayed, not a branch name: >>>>>>> 286b0aa (feature: change line2).

That's the one thing worth remembering: a merge's closing marker names a branch; a rebase's closing marker names the specific commit (hash + message) currently being replayed, because a multi-commit rebase can conflict on each commit in turn with a different hash each time.

3. What git status says during a rebase conflict

We ran git status while the conflict was open. Exact output:

interactive rebase in progress; onto a267195
Last command done (1 command done):
   pick 286b0aa feature: change line2
No commands remaining.
You are currently rebasing branch 'feature' on 'a267195'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
	both modified:   file.txt

no changes added to commit (use "git add" and/or "git commit -a")

Note it says "interactive rebase in progress" even though we ran a plain, non-interactive git rebase main — git 2.47.3 uses the same sequencer-based machinery for both, so the message is identical either way. The both modified line is the same wording a merge conflict uses.

4. Is this a "detached HEAD"? Yes, but git tells you exactly what's going on

We checked directly: during the conflict, git branch --show-current printed nothing, and git symbolic-ref HEAD failed with fatal: ref HEAD is not a symbolic ref (exit 128). .git/HEAD held a raw commit SHA, not a ref name. Mechanically that is the same detached HEAD state you get from checking out a commit directly.

The difference is what git tells you. A plain detached checkout's git status just says HEAD detached at <sha> with generic advice. Mid-rebase, git status instead says "You are currently rebasing branch 'feature' on '<sha>'" and gives rebase-specific next steps (--continue/--skip/--abort). You're detached either way, but a rebase in progress is self-documenting, so you don't need to recognize detached HEAD yourself to know how to get out.

5. Resolving it: edit, add, --continue

We edited the file to the content we wanted, removing all three marker lines ourselves (git does not do this for you):

printf "line1\nRESOLVED-LINE\nline3\n" > file.txt
git add file.txt
git rebase --continue

Exact output:

[detached HEAD 6a7763d] feature: change line2
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/feature.

Exit code was 0. Git itself labels the intermediate commit [detached HEAD ...], confirming the state from section 4. The resulting commit has a new hash (6a7763d, not the original fa34f88) because rebase rewrites every commit it replays. git log --oneline afterward showed a clean, linear history: feature's commit now sits directly on top of main's, with no merge commit.

6. git rebase --skip: drops the commit entirely

Instead of resolving, we ran git rebase --skip on the same conflict. Exact output:

Successfully rebased and updated refs/heads/feature.

Exit code 0 — but the conflicting commit's change is simply discarded, not applied in any form. git log afterward no longer contained the feature: change line2 commit at all, and file.txt matched main's version exactly (MAIN-CHANGE), with no trace of FEATURE-CHANGE anywhere. Use --skip only when you're sure that commit's change is no longer needed; there's no silent recovery of it afterward other than finding the original commit hash via git reflog.

7. git rebase --abort: full rollback

We also triggered the conflict and ran git rebase --abort instead. Exit code 0, no other output. git status immediately showed On branch feature / nothing to commit, working tree clean, git branch --show-current printed feature again (HEAD reattached), and git log --oneline showed the branch's single original commit, unchanged. --abort is a complete, exact restore to the state right before the rebase started — unlike --skip, nothing is lost.

8. Quick comparison

Quick checklist: run git status to see which command you're mid-rebase and which file is both modified; open it, delete the <<<<<<</=======/>>>>>>> markers by hand after picking the content you want; git add each resolved file; then git rebase --continue. Changed your mind entirely? git rebase --abort restores the pre-rebase state exactly.

Written with AI assistance. Measured on 2026-10-03 with git 2.47.3 on Linux, plain CLI only (no GUI tool), in disposable /tmp repos. PlainHeaders is our extension; git is free and open source.