Git revert conflicts occur when the changes you're trying to undo have been modified by subsequent commits. Resolve conflicts by editing files, staging them, then completing the revert with --continue.
The "could not revert" error with a "CONFLICT (content)" message indicates that Git was unable to automatically reverse the changes from a specific commit because those same lines have been modified in later commits. When you run `git revert <commit>`, Git attempts to create a new commit that undoes the changes introduced by the specified commit. This works by applying the inverse of the original changes. However, if the codebase has evolved since that commit—meaning other commits have touched the same lines—Git cannot automatically determine what the final result should look like. Unlike `git reset`, which rewrites history by removing commits, `git revert` is a safe operation that preserves history by adding a new "undo" commit. This makes it ideal for shared branches where rewriting history would cause problems for other developers. The trade-off is that you may need to manually resolve conflicts when the code has changed.
First, check which files have conflicts and understand the situation:
# See which files are in conflict
git status
# Example output:
# Unmerged paths:
# (use "git restore --staged <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# both modified: src/utils.jsThe "both modified" status indicates files where Git couldn't automatically apply the revert.
Open each conflicted file and look for conflict markers:
<<<<<<< HEAD
// Current code in your branch
const result = processData(input);
=======
// What Git tried to apply from the revert
const result = handleData(input);
>>>>>>> parent of abc1234 (original commit message)The section between <<<<<<< HEAD and ======= shows your current code. The section between ======= and >>>>>>> shows what the revert is trying to restore.
Edit each file to produce the desired final state:
1. Remove all conflict markers (<<<<<<<, =======, >>>>>>>)
2. Keep the code you want—this might be one version, the other, or a combination
3. Save the file
For example, if you want to keep the current code and not apply the revert:
// Keep the current version
const result = processData(input);Or if you want the reverted version:
// Restore the original code
const result = handleData(input);After resolving conflicts in each file, stage them to mark them as resolved:
# Stage a specific resolved file
git add src/utils.js
# Or stage all resolved files
git add .
# Verify the status
git status
# Should now show: "all conflicts fixed: run 'git revert --continue'"Important: Only run git add after you've removed all conflict markers from the file.
Once all conflicts are resolved and staged, complete the revert:
git revert --continueThis opens your default editor to confirm or modify the commit message. Save and close to complete the revert commit.
If you want to use the default message without editing:
git revert --continue --no-editIf you decide not to proceed with the revert, you can abort it entirely:
# Abort and return to the state before the revert
git revert --abortThis discards all conflict resolution work and restores your working directory to its pre-revert state. Use this when:
- The conflicts are too complex to resolve cleanly
- You realize the revert isn't the right approach
- You need more time to understand the changes before proceeding
If you're reverting multiple commits and want to skip one:
# Skip the current problematic commit
git revert --skipThis skips the current commit and continues with the remaining commits in the revert sequence. Only use this when you've started a multi-commit revert with a range like:
git revert HEAD~3..HEADFor certain scenarios, you can use merge strategy options to automatically resolve conflicts:
# Favor the current branch's version (effectively skip conflicting changes)
git revert -X ours <commit-hash>
# Favor the reverted version (apply revert even if it overwrites newer changes)
git revert -X theirs <commit-hash>Warning: Using these options blindly may discard important changes. Only use when you understand the implications and have verified the result is correct.
### Reverting Merge Commits
When reverting a merge commit, you must specify which parent to revert relative to using the -m flag:
# Revert relative to the first parent (usually the main branch)
git revert -m 1 <merge-commit-hash>
# Revert relative to the second parent (the merged branch)
git revert -m 2 <merge-commit-hash>In most cases, -m 1 is what you want—it undoes the changes brought in by the merged branch while keeping the main branch's history intact.
### Using Rerere (Reuse Recorded Resolution)
Git's rerere feature can remember how you resolved conflicts and apply the same resolution automatically in the future:
# Enable rerere
git config --global rerere.enabled true
# With rerere enabled, Git records your conflict resolutions
# and can auto-apply them when the same conflict appears againThis is particularly useful when you frequently encounter the same conflicts (e.g., during rebasing workflows).
### Reviewing What Would Change
Before running a revert, you can preview what changes would be applied:
# Show what the revert would do without actually doing it
git show <commit-hash>
# Or see the diff that would be created
git diff <commit-hash>^..<commit-hash>### Revert vs Reset vs Restore
- git revert: Creates a new commit that undoes changes—safe for shared branches
- git reset: Moves branch pointer back—rewrites history, not safe for shared branches
- git restore: Discards uncommitted changes in working directory—doesn't affect commits
When working on a branch that others have pulled, always prefer git revert over git reset to avoid causing problems for your teammates.
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