Recognize the failure
CONFLICT (content): Merge conflict in <file>
error: could not apply <commit>...
hint: Resolve all conflicts manually, mark them as resolved with git add/rm, then run git rebase --continue.Git is replaying one of your commits onto a new base and cannot combine that commit automatically with the file state already present on the new base. Git pauses because choosing the intended result requires human context.
A rebase conflict is not a request to delete conflict markers as quickly as possible. It is a question: “What should this old change mean when applied to the newer code?” Resolve that question first; the markers are only evidence of where Git could not decide.
Why this happens
Both histories changed the same lines
The new base and the commit being replayed edited overlapping text, so Git cannot infer which version—or combination—represents the intended result.
What you may see: The conflicted file contains <<<<<<<, =======, and >>>>>>> markers around nearby edits.
One side moved or deleted code the replayed commit still edits
The newer base may have renamed, reorganized, or removed code that the older commit expects to find in its previous location.
What you may see: git status may report modify/delete or rename-related conflicts, or the old context may no longer exist where you expect it.
The same logical change already exists upstream
The new base may already contain an equivalent fix implemented differently. Replaying the old commit can collide even though both histories are trying to reach the same behavior.
What you may see: After reading the upstream implementation, you discover that much of the replayed commit is redundant rather than truly competing.
Diagnose it in this order
Confirm exactly where the rebase paused
Run git status before editing anything.
git statusWhy this step matters: Status tells you which files are conflicted and reminds you that a rebase is in progress instead of leaving you to infer state from the editor.
Identify the commit Git is trying to replay
Inspect the current rebase state and nearby history.
git rebase --show-current-patch git log --oneline --decorate --graph -12Why this step matters: You need to understand the purpose of the old commit before deciding how its change belongs on the new base.
Read both versions in context
Open the conflicted file and inspect surrounding code, tests, and callers—not only the lines between conflict markers.
Why this step matters: A locally tidy conflict resolution can still violate a renamed API, changed invariant, or newer design decision.
Check behavior before continuing
Run the narrowest useful test, typecheck, lint, or build step after resolving and staging the file.
Why this step matters: git rebase --continue validates Git state, not application correctness.
Choose the fix that matches the evidence
Resolve the change and continue
Use this when: Use this when the replayed commit is still needed and you understand how its intent should fit the new base.
- Edit each conflicted file into the desired final state and remove conflict markers.
- Run focused checks that exercise the affected behavior.
- Stage only the resolved files you have reviewed.
- Continue the rebase and repeat if another replayed commit conflicts.
git add <resolved-files>
git rebase --continueAbort and return to the pre-rebase branch
Use this when: Use this when the conflict set reveals that the chosen base or rebase strategy was wrong, or when you are no longer confident in the intended result.
- Stop editing and preserve any notes you need outside the conflicted working tree.
- Abort the rebase.
- Inspect the original branch and decide whether to rebase differently, merge, or update the work another way.
git rebase --abortCaution: Abort is often safer than guessing through conflicts. It is not a failure; it restores a known state so you can choose deliberately.
Skip only when the replayed commit is provably unnecessary
Use this when: Use this rarely, such as when the exact change already exists upstream and dropping the replayed commit preserves the intended final behavior.
- Inspect the current patch and upstream implementation.
- Prove the commit adds no unique required behavior.
- Run git rebase --skip and verify the resulting history and tests.
git rebase --skipCaution: Skipping removes that commit from the rebased history. Never use it merely because resolving the conflict is inconvenient.
Weak approach vs safer approach
git checkout --theirs src/app.ts
git add src/app.ts
git rebase --continueBlindly choosing one side treats the conflict as a file-selection problem. During a rebase, “ours” and “theirs” are also easy to misunderstand because Git is replaying commits onto the new base. You can silently discard required logic even though the rebase completes.
git status
git rebase --show-current-patch
# edit the conflict to preserve the new API and the feature intent
npm test -- --runInBand relevant-test
git add src/app.ts
git rebase --continueThis sequence starts from state, reconstructs the replayed commit’s intent, resolves against the newer design, verifies behavior, and only then allows Git to continue.
Prevent the same class of failure
- Rebase local feature work frequently enough that conflicts stay small and understandable instead of accumulating for weeks.
- Fetch and inspect the target base before starting so you know what changed upstream.
- Keep commits focused: a commit with one coherent intent is easier to replay and reason about than a large mixed change.
- Avoid rebasing shared published history unless the collaboration workflow explicitly expects history rewriting.
- Maintain focused automated tests around behavior that is likely to conflict; tests turn ambiguous manual resolutions into checkable decisions.
Continue from troubleshooting to understanding
Frequently asked questions
Should I use ours or theirs to resolve a rebase conflict?
Do not choose based on the label alone. In a rebase, the labels can feel reversed from an ordinary merge because Git is replaying your commit onto the new base. Decide from intended behavior, then construct the correct final file.
Why does git rebase --continue open an editor?
Git may ask you to confirm or edit the commit message for the commit being replayed. Review the message, save it, and close the editor. If the editor behavior is unexpected, check your Git core.editor configuration rather than terminating Git blindly.
Can I recover after a bad completed rebase?
Often yes. git reflog usually records the branch position from before the rebase. Stop making destructive changes, inspect the reflog, and recover deliberately. Reflog is a recovery tool, not a substitute for understanding the operation.