This error occurs during a Git rebase when Git encounters a merge conflict it cannot automatically resolve. The rebase is paused, not failed, and you can either fix the conflict, skip the problematic commit, or abort the rebase entirely.
The "error: could not apply" message during a Git rebase indicates that Git encountered a merge conflict while trying to replay one of your commits on top of the new base. This happens when both your commit and a commit in the target branch modified the same lines in the same file. Importantly, this is not a fatal error - your rebase operation is paused, not failed. Git is waiting for you to resolve the conflict before continuing. The commit hash shown (like "abc1234...") identifies which specific commit caused the conflict, making it easier to understand what changes are conflicting. This error commonly appears when: - Rebasing a feature branch onto an updated main branch - Interactive rebasing to clean up commit history - Pulling with rebase when remote changes conflict with local commits - Cherry-picking commits that conflict with existing code The underlying cause is always the same: two commits modified the same code, and Git cannot automatically determine which version to keep.
First, understand which commit caused the conflict and which files are affected:
# See the current state
git statusThis will show:
- That you are currently rebasing
- Which commit is being applied
- Which files have conflicts (marked as "both modified")
- Instructions on how to proceed
Example output:
interactive rebase in progress; onto def5678
Last command done (3 commands done):
pick abc1234 Add new feature
You are currently rebasing branch 'feature' on 'def5678'.
(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: src/app.jsLook at the conflicting files to understand what needs to be resolved:
# See the diff of the conflicting commit
git show HEAD
# See what the incoming commit is trying to change
git show REBASE_HEAD
# Compare your changes with the target branch
git diff HEAD REBASE_HEADOpen the conflicting files in your editor. You'll see conflict markers like:
<<<<<<< HEAD
// This is the code from the target branch (where you're rebasing onto)
const result = calculate(x, y);
=======
// This is your change from the commit being applied
const result = compute(x, y, z);
>>>>>>> abc1234 (Add new feature)The section between <<<<<<< HEAD and ======= is the current state.
The section between ======= and >>>>>>> is your incoming change.
Edit each conflicting file to resolve the conflicts:
1. Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
2. Keep the correct code - this might be one version, the other, or a combination
3. Test your changes if possible
Example resolution:
// After resolving - keep the combined logic
const result = compute(x, y, z);For multiple files, resolve each one:
# List all conflicted files
git diff --name-only --diff-filter=U
# Use your preferred editor/IDE
code src/app.jsMany IDEs have built-in merge conflict resolution tools:
- VS Code: Shows "Accept Current", "Accept Incoming", "Accept Both" buttons
- IntelliJ/WebStorm: Has a dedicated merge conflict resolver
- Git mergetool: git mergetool opens configured merge tool
After resolving all conflicts, stage the files and continue the rebase:
# Stage the resolved files
git add src/app.js
# Or stage all resolved files at once
git add .
# Continue the rebase
git rebase --continueIf there are more commits to apply, Git will continue with the next one. You may encounter additional conflicts if later commits also have issues.
If the commit message editor opens:
Git may open your editor to confirm or modify the commit message. Save and close to proceed.
Verify the rebase completed:
git status
# Should show "nothing to commit, working tree clean"
# and you should be on your branch, not in a rebase stateIf the commit's changes are no longer needed (perhaps they were already incorporated differently), you can skip it:
git rebase --skipWhen to skip a commit:
- The changes in the commit are already present in the target branch
- The commit was a temporary fix that's been superseded
- The commit only makes sense in the old context
Warning: Skipping means ALL changes from that commit are discarded. Make sure you understand what you're losing.
Check what would be skipped:
# See the commit that would be skipped
git log -1 REBASE_HEAD
# See the actual changes
git show REBASE_HEADIf the rebase is too complex or you need to approach it differently, abort:
git rebase --abortThis returns your branch to its exact state before you started the rebase. No changes are lost.
When to abort:
- The conflicts are too complex to resolve quickly
- You realize you're rebasing onto the wrong branch
- You need to prepare your branch differently first
- You want to try a different approach (like merge instead)
After aborting, consider:
# Maybe use merge instead of rebase
git merge origin/main
# Or break up your changes into smaller commits first
git reset --soft HEAD~3 # Undo last 3 commits but keep changes
# Then commit more granularly and try rebase againEnable Git's "reuse recorded resolution" feature to automatically resolve conflicts you've fixed before:
# Enable rerere globally
git config --global rerere.enabled trueHow rerere works:
1. When you resolve a conflict, Git records how you resolved it
2. If the same conflict appears again (same content on both sides), Git automatically applies your previous resolution
3. Very useful for long-running branches that get rebased repeatedly
View recorded resolutions:
# See recorded conflict resolutions
ls .git/rr-cache/
# Forget a specific resolution if it was wrong
git rerere forget <pathspec>This is especially helpful in workflows where you frequently rebase feature branches onto an evolving main branch.
Understanding What Happens During Rebase:
When you run git rebase <target>, Git:
1. Finds the common ancestor of your branch and target
2. Saves all commits from your branch that aren't in target
3. Resets your branch to match target
4. Replays your saved commits one by one
The "could not apply" error occurs at step 4 when a commit can't be cleanly applied.
Interactive Rebase and Conflicts:
During git rebase -i, commits can conflict because:
- Reordering: Moving a commit before one it depends on
- Squashing: Combining commits that touch the same lines
- Editing: The edited commit conflicts with later ones
Conflict Resolution Strategies:
# See what the commit was trying to do
git show REBASE_HEAD
# Compare with the current state
git diff HEAD...REBASE_HEAD
# Use a three-way merge tool
git mergetoolRebasing Merge Commits:
If your branch contains merge commits, use:
git rebase --rebase-merges <target>Without this flag, merge commits are flattened and can cause confusing conflicts.
Preserving Author Information:
When resolving conflicts, the commit author and date are preserved. The committer information (you) is updated. This is normal and maintains proper attribution.
Complex Rebase Workflows:
For very complex rebases, consider:
1. Rebase in chunks: Instead of rebasing 50 commits at once, do 10 at a time
2. Create backup branches: git branch backup-before-rebase
3. Use git log to plan: Review the commits you're about to rebase
# See exactly what will be rebased
git log --oneline main..HEAD
# Check for potentially problematic commits
git log --oneline --name-only main..HEAD | grep -B1 "specific-file.js"When to Prefer Merge Over Rebase:
| Situation | Recommendation |
|-----------|---------------|
| Many conflicts expected | Use merge (one resolution vs. multiple) |
| Shared/pushed branch | Use merge (avoid history rewriting) |
| Preserving exact history | Use merge |
| Clean linear history | Use rebase |
| Personal feature branch | Use rebase |
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