Chapter 5.6 — Rebase Conflict Flow — continue/skip/abort☕ 16 min read

Rebase Conflict Flow — Continue, Skip, Abort

Resolve, add, continue — yeh rebase ka mantra hai. Commit mat karna beech mein!

01Rebase Stops Midway

Merge conflicts are like fighting a final boss — all divergent changes come at you at once, and you must resolve everything in one big battle. Rebase conflicts are different — they are like fighting mini-bosses, one at a time.

When you run git rebase main, Git replays your commits one by one onto the new base. If commit #3 conflicts with main, Git pauses right there. You resolve ONLY commit #3's conflict, then continue. Git moves on to commit #4.

This is often easier than merge conflicts because each conflict is smaller and more focused — you know exactly which commit caused the problem.

But it can take longer if many commits conflict — you might resolve the same lines repeatedly across multiple commits.

# Rebase with 5 feature commits onto main
git rebase main

# Applying: feat: add login (no conflict)
# Applying: feat: add validation (CONFLICT!)
# Git pauses here. Resolve this commit's conflict only.

# After resolving and continuing:
# Applying: feat: add tests (CONFLICT!)
# Git pauses again. Resolve this commit's conflict.

# After resolving and continuing:
# Applying: feat: add logging (no conflict)
# Applying: feat: add cleanup (no conflict)

# Done! All 5 commits replayed successfully.

Merge = one big battle. Rebase = many small battles. Each has its place. If your branch has few commits and simple conflicts, rebase is smooth. If you have 20 commits all conflicting on the same lines, merge might be the better choice — resolve once and move on.

02--continue

When rebase pauses at a conflict, you have 3 options:

git rebase --continue — I resolved the conflict, move to the next commit.
git rebase --skip — Skip this commit entirely (it is now empty or unnecessary).
git rebase --abort — Cancel the entire rebase, go back to the original state.

The standard flow: resolve conflicts → git add → git rebase --continue

DO NOT run git commit during a rebase (unless you are in an edit action). --continue creates the commit for you.

If you feel overwhelmed, use --abort. It is always safe and returns you to the pre-rebase state.

# Rebase pauses with conflict
git rebase main
# CONFLICT (content): Merge conflict in app.js

# Option 1: Resolve and continue
# Edit conflicted files, then:
git add app.js
git rebase --continue
# Git creates the commit and moves to the next one

# Option 2: Skip this commit
git rebase --skip
# This commit is skipped entirely
# Use when: commit's changes already exist in the base

# Option 3: Abort everything
git rebase --abort
# Cancels rebase. Branch is back to original state
# Use when: too many conflicts, want to start over

💡 Pro Tip: During rebase conflicts, Git tells you how many commits remain: "Rebasing (2/5)" means you are on commit 2 of 5. This helps you decide whether to continue or abort. If you are on commit 2 of 10 and already overwhelmed, abort and try a different strategy (like merging instead).

03--skip

Step by step, the --continue flow looks like this:

Step 1: Open the conflicted file(s) in your editor.
Step 2: Resolve the conflict markers (<<<<<<<, =======, >>>>>>>).
Step 3: Stage the resolved file with git add <file>.
Step 4: Run git rebase --continue.
Step 5: If more conflicts, repeat. If done, Git completes the rebase.

CRITICAL: Do NOT run git commit during a regular rebase continue. --continue handles the commit creation.

If you accidentally commit, it creates a separate commit outside the rebase flow — messy to fix.

# Rebase in progress, conflict detected
# Step 1: Check which files are conflicted
git status
# both modified: app.js

# Step 2: Open and resolve
# Change this:
# <<<<<<< HEAD
# main code
# =======
# feature code
# >>>>>>> feat: add login
# To this:
# resolved code

# Step 3: Stage the resolved file
git add app.js

# Step 4: Continue the rebase
git rebase --continue
# Git may open editor for commit message (optional to change)
# Save and close.

# Step 5: Repeat if more conflicts
# Or if all resolved:
# Successfully rebased and updated refs/heads/feature.

04--abort

Use --skip when the commit you are applying is now empty or its changes already exist in the base.

This happens when: someone else already made the same fix on main, or the conflicting code makes your commit unnecessary.

Skipping PERMANENTLY drops that commit — its changes are NOT applied.

Make sure the commit is truly unnecessary before skipping. If it contains other changes, you will lose them.

If --skip drops a commit you needed, use git reflog to find it and cherry-pick it later.

# Scenario: Your commit fixed a bug that main already fixed
git rebase main
# Applying: fix: null pointer in auth
# CONFLICT!

# You check the file and realize: main already has this fix
# Your commit's changes are now redundant

# Resolve by keeping the main version (which has the fix)
git checkout --theirs auth.js  # keep main's version
git add auth.js

# But wait — if we keep main's version, our commit adds NOTHING
# The commit becomes empty. Git will warn:
# "The previous cherry-pick is now empty, possibly due to conflict resolution."

# Skip this empty commit
git rebase --skip
# Commit is dropped. Rebase continues with next commit.

# WARNING: If your commit also had OTHER changes besides the fix,
# those changes are lost! Check carefully before skipping.

--skip is permanent. The commit is gone from the rebased branch. If you realize later that you needed it, you can find it in the reflog (git reflog) and cherry-pick it back. But prevention is better than cure — always check git show REBASE_HEAD before skipping to see what you are dropping.

05Step-by-Step Flow

git rerere = Reuse Recorded Resolution — Git remembers how you resolved conflicts.

If you resolve the same conflict during rebase, and later during merge, Git auto-resolves it.

Enable once: git config --global rerere.enabled true

During conflict, Git says: "Recorded preimage for resolution" — it is saving the conflict state.

When you resolve and continue, Git says: "Recorded resolution for [file]" — it is saving your resolution.

Next time the same conflict appears, Git applies your resolution automatically.

Useful for: long-lived branches that are rebased frequently, or testing merge compatibility.

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

# Rebase with conflicts
git rebase main
# CONFLICT in app.js
# Git: Recorded preimage for app.js (saving conflict state)

# Resolve conflict manually
echo "resolved code" > app.js
git add app.js
git rebase --continue
# Git: Recorded resolution for app.js (saving your resolution)

# Later, if the same conflict appears (e.g., during another rebase)
git rebase main
# CONFLICT in app.js
# Git: Resolved app.js using previous resolution.
# Auto-resolved! You just need to verify and continue.

git add app.js
git rebase --continue
# Much faster — Git remembered what you did last time!

The rebase conflict flow is a loop: resolve → add → continue → [next conflict?] → repeat. If you get stuck, abort and try a different strategy. Never "power through" a rebase with conflicts you do not understand — each resolution affects all subsequent commits. When in doubt, abort and merge instead.

Lo kar liya — Key Points:

✅ Rebase conflicts happen one commit at a time (mini-bosses), unlike merge conflicts which happen all at once (final boss)
✅ When rebase pauses at a conflict, you have 3 options: --continue, --skip, --abort
✅ git rebase --continue: resolve conflict, git add, then continue to next commit
✅ git rebase --skip: drop this commit entirely (use when commit becomes empty/redundant)
✅ git rebase --abort: cancel the entire rebase and return to the original state
✅ NEVER run git commit during a rebase continue flow — --continue handles the commit for you
✅ git rerere remembers your conflict resolutions and auto-applies them next time

Previous5.5 — When NOT to Rebase 📋 All Chapters Next Chapter5.7 — Autosquash — fixup & squash automation →