Chapter 3.8 — Rebase Conflict Resolution Flow☕ 15 min read

Rebase Conflict Resolution Flow

Merge = ek bada conflict. Rebase = chhote chhote conflicts. Har commit pe ruko, resolve karo, continue karo. Kabhi commit mat karo rebasing mein!

01Rebase Conflicts: One Commit at a Time

During a rebase, Git replays EACH of your commits on top of the target branch one by one. If a commit conflicts, Git PAUSES and asks you to resolve just that one commit's changes.

This is fundamentally different from merge: merge shows ALL conflicts at once, rebase shows them sequentially.

Each rebase conflict is usually SMALLER and simpler because it is only one commit's worth of changes. But there can be MANY conflicts — one for each commit that touches changed areas.

Think of it this way:

Merge conflict = one big boss fight with all enemies at once
Rebase conflict = many mini-boss fights, one at a time

The rebase approach means you never face a massive combined conflict. But you may need to resolve the same area multiple times across different commits.

# Rebase feature onto main
git checkout feature
git rebase main

# If commit 1 conflicts:
# CONFLICT (content): Merge conflict in app.js
# Could not apply commit1... feat: add login

# Resolve ONLY the changes from commit 1
# Then continue to the next commit

# If commit 2 also conflicts:
# CONFLICT (content): Merge conflict in app.js
# Could not apply commit2... feat: add logout

# Resolve commit 2's changes, continue...
# This repeats for each conflicting commit.

Rebase conflicts are sequential. Git applies commit 1 first. If it conflicts, you resolve ONLY commit 1's changes. Then Git applies commit 2. If that conflicts too, you resolve ONLY commit 2's changes. Each conflict is isolated to one commit — smaller scope, but potentially more rounds.

02The Rebase Resolution Flow: Resolve -> Add -> Continue

The rebase conflict resolution flow is a loop. Once you learn the loop, every rebase conflict follows the same pattern:

Step 1: Open the conflicted file(s) and resolve the conflict markers (<<<<<<<, =======, >>>>>>>).
Step 2: git add <resolved-file> — stage the resolution (DO NOT commit!).
Step 3: git rebase --continue — tell Git to move to the next commit.
Step 4: Repeat for each conflicting commit.

CRITICAL: Do NOT run git commit during a rebase conflict. Rebase handles commits automatically. Running git commit manually breaks the rebase sequence.

Git tells you how many commits are left: Rebasing (2/5) means 2 done, 3 to go. This progress indicator helps you know how much work remains.

If Git can open your editor, it may also ask you to edit the commit message for each commit. Usually you just save and close — the original message is fine.

# The rebase conflict resolution loop:

# 1. Rebase starts
git rebase main
# CONFLICT! (1/3)

# 2. Resolve the conflict in your editor
# Edit file, remove conflict markers

# 3. Stage the resolution
git add app.js

# 4. Continue to next commit
git rebase --continue
# CONFLICT! (2/3)

# 5. Resolve again
# Edit, remove markers

# 6. Stage and continue
git add app.js
git rebase --continue
# CONFLICT! (3/3)

# 7. Last one
git add app.js
git rebase --continue

# Done! All commits rebased successfully.

💡 Pro Tip: Always run git status before --continue. A single commit can conflict in MULTIPLE files. If you only resolve one file and continue, the other files' conflict markers get committed into your code. Check for "Unmerged paths" in git status output.

03When to Skip: git rebase --skip

git rebase --skip skips the current commit entirely — Git does not apply it during the rebase.

When should you skip?

Commit is empty after resolution: Your commit's changes are already in the base branch, making your commit redundant.
Commit is no longer needed: The commit was a temporary fix that's already addressed in the base.

DANGER: Skipping permanently loses that commit's changes. Be absolutely certain before using --skip.

After skipping, Git continues to the next commit in the rebase sequence. The skipped commit is gone from the rebase result.

If you skip accidentally, you can find the commit hash in git reflog and cherry-pick it back later. But prevention is better than recovery.

# Scenario: Your commit's changes are already in main
git rebase main
# CONFLICT! Could not apply "fix: handle null response"
# After resolving, you realize your changes duplicate what's already in main

# Check if the commit is now empty after resolution
git status
# nothing to commit, working tree clean

# The commit is empty — skip it
git rebase --skip
# Skipped commit, moving to next...

# NEVER skip just because resolving is hard
# Only skip if the commit is genuinely no longer needed

--skip vs --abort: If you're unsure whether to skip, abort instead. git rebase --abort is always safe — it restores your original branch. --skip permanently discards a commit. When in doubt, abort and reassess.

04When to Abort: git rebase --abort

git rebase --abort cancels the entire rebase and returns your branch to the exact state it was in before the rebase started.

When should you abort?

Overwhelmed by conflicts: Too many conflicts, you're making mistakes.
Made a resolution mistake: You resolved a conflict incorrectly and continued.
Wrong strategy: Rebase was the wrong approach — merge would be better.
Something feels wrong: The conflicts don't make sense, or you're losing code unexpectedly.

After aborting, your branch is exactly as it was. Nothing is lost. You can then try a different approach: git merge main instead, or rebase with strategy options like -X ours or -X theirs.

Abort is a strategic retreat, not a failure. Every experienced developer uses --abort regularly. It is far better to abort and restart than to force a bad resolution through.

# The rebase is going badly
git rebase main
# CONFLICT (1/5)
# Resolved... --continue
# CONFLICT (2/5) — this one is really hard
# Resolved... --continue
# CONFLICT (3/5) — I messed up the resolution
# "I need to start over with a different strategy!"

git rebase --abort
# Clean state restored!

# Try merging instead
git merge main

# Or try with strategy options
git rebase -X ours main
# (automatically resolve conflicts by keeping YOUR version)

💡 Pro Tip: Before starting a rebase, note your current commit hash with git rev-parse HEAD. This gives you a safety net — even if something goes very wrong, you can always git reset --hard <that-hash> to get back. But --abort should handle 99% of cases.

05git rerere: Remember Resolutions

git rerere stands for Reuse Recorded Resolution — Git remembers how you resolved conflicts and reuses the same resolution automatically.

If the same conflict appears again (same file, same conflicting lines), Git auto-resolves it the same way you did before. You just need to verify and continue.

Enable it globally:

git config --global rerere.enabled true

When is rerere useful?

Long rebases: Same conflict pattern repeats across multiple commits.
Repeated rebases: You rebase your feature branch onto main daily.
Testing merge conflicts: You want to see conflicts without actually merging.

When rerere kicks in, Git shows: Resolved 'file' using previous resolution. The conflict markers are automatically replaced with your previous resolution.

You should still verify the auto-resolution before continuing. Rerere is smart but not infallible — context may have changed.

# Enable rerere
git config --global rerere.enabled true

# Now during rebase, when you resolve a conflict:
git rebase main
# CONFLICT in app.js
# Resolve it manually...
git add app.js
git rebase --continue
# rerere RECORDS this resolution!

# Next time the same conflict appears:
git rebase main
# CONFLICT in app.js
# Resolved 'app.js' using previous resolution.
# Git auto-resolves it! You just need to verify and continue.

# Check rerere status
git rerere status
git rerere diff  # see what rerere resolved

rerere is a productivity multiplier for teams that rebase frequently. If you rebase your feature branch onto main every day, you'll see the same conflicts repeatedly. rerere eliminates the repetitive manual resolution. Enable it once in your global config and forget about it — Git handles the rest.

Lo kar liya — Key Points:

✅ During rebase, conflicts occur ONE COMMIT AT A TIME as Git replays each commit on the new base
✅ The resolution flow: resolve conflict → git add <file> → git rebase --continue (DO NOT git commit)
✅ git rebase --skip skips the current commit entirely — only use if the commit is empty or no longer needed
✅ git rebase --abort cancels the entire rebase and returns to the original branch state
✅ Each rebase conflict is usually smaller than a merge conflict, but there can be many of them
✅ git rerere (Reuse Recorded Resolution) remembers how you resolved conflicts and auto-applies the same resolution next time

Previous3.7 — package-lock.json Conflicts 📋 All Chapters Next Chapter4.1 — Branches Kya Hoti Hain →