This error occurs when Git cannot automatically apply a commit during a rebase because changes in the commit conflict with changes in the target branch. You must manually resolve the conflicts by editing the affected files, staging them, and continuing the rebase.
When you run `git rebase`, Git takes each commit from your branch and attempts to replay it on top of the target branch. If a commit modifies the same lines of code that were also changed in the target branch, Git cannot determine which version to keep automatically. The message "CONFLICT (content): Merge conflict in file.txt" tells you which file has conflicting changes. The "error: could not apply abc1234" portion identifies the specific commit that Git couldn't apply cleanly. Inside the conflicted file, you'll find conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) showing both versions of the code. This is a normal part of the rebase workflow, not a fatal error. Git pauses the rebase and waits for you to manually decide how to combine the conflicting changes before continuing.
When Git reports a conflict, first check which files need attention:
git statusFiles listed under "Unmerged paths" or showing "both modified" need conflict resolution. You can also see the current failing patch:
git am --show-current-patchOpen each conflicted file in your editor. You'll see conflict markers like this:
<<<<<<< HEAD
// This is the code from the target branch (already rebased commits)
const result = calculateTotal(items);
=======
// This is the code from your commit being applied
const result = computeSum(items);
>>>>>>> abc1234 (commit message)The section between <<<<<<< HEAD and ======= shows the target branch version.
The section between ======= and >>>>>>> shows your commit's version.
Important during rebase: "HEAD" refers to the rebased state so far, not your original branch. "Theirs" and "ours" are swapped compared to merge conflicts.
Edit each conflicted file to create the correct final version:
1. Remove all conflict markers (<<<<<<<, =======, >>>>>>>)
2. Keep the code you want (could be from either version or a combination)
3. Save the file
Example resolution:
// Final resolved version - combining both changes
const result = calculateTotal(items); // Kept the better function nameFor simple cases, you can use Git's built-in tools:
# Keep your version (the commit being rebased)
git checkout --theirs path/to/file.txt
# Keep target branch version
git checkout --ours path/to/file.txtOr use a visual merge tool:
git mergetoolAfter editing each conflicted file, stage it to mark as resolved:
git add path/to/file.txtOr stage all resolved files at once:
git add -AVerify all conflicts are resolved:
git statusThere should be no files under "Unmerged paths".
Once all conflicts are resolved and staged, continue the rebase:
git rebase --continueGit will apply the resolved commit and move to the next one. If more conflicts arise, repeat the resolution process.
If you get "No changes - did you forget to use 'git add'?": This means the resolved version is identical to the target branch. You can skip this commit:
git rebase --skipIf the conflicts are too complex or you want to start over, abort the rebase:
git rebase --abortThis returns your branch to its exact state before the rebase started. You can then:
- Try a different approach (merge instead of rebase)
- Break up your changes into smaller commits
- Coordinate with teammates about conflicting changes
### Enable diff3 for Better Conflict Context
The default conflict view only shows two versions. Enable diff3 to see the common ancestor:
git config --global merge.conflictstyle diff3Conflicts will then show three sections, including what the code looked like before either branch changed it. This makes it much easier to understand what changed and why.
### Enable rerere to Record Resolutions
Git can remember how you resolved conflicts and automatically apply the same resolution if it sees the same conflict again:
git config --global rerere.enabled trueThis is especially useful when rebasing repeatedly or dealing with long-running branches.
### Understanding "Ours" vs "Theirs" in Rebase
During a rebase, the terminology is counterintuitive:
- "ours" = the target branch (where you're rebasing onto)
- "theirs" = your commits being replayed
This is the opposite of merge conflicts. Keep this in mind when using --ours or --theirs flags.
### Squash Before Rebasing
If you have many small commits that touch the same files, consider squashing them first:
git rebase -i HEAD~5 # Interactive rebase last 5 commitsMark commits as "squash" or "fixup" to combine them. Fewer commits means fewer potential conflicts during the main rebase.
### Rebase Frequently to Minimize Conflicts
The longer your branch diverges from the target, the more likely you'll face conflicts. Rebase regularly:
git fetch origin
git rebase origin/mainSmall, frequent rebases are easier than one large rebase with many conflicts.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server