Git Merge Conflict Keeps Reappearing After Resolving

If you resolve a Git merge conflict, commit it, and then the exact same conflict shows up again later — on the next pull, the next merge, or even the next day — it's almost always because the resolution never actually made it into the branch history the way you expected, not because Git is "forgetting" your fix.

The Problem

You run into a merge conflict, manually edit the conflicted file, remove the conflict markers, and commit. Everything looks fine. But later — after another git pull, another merge, or a teammate merging the same branches — the identical conflict reappears in the same file, sometimes with the same lines you already resolved.

Why It Happens

Git conflicts are tied to the specific commit history being compared, not to "the file" in the abstract. The most common reasons a resolved conflict reappears are:

• The merge commit that contains your resolution was made on a local branch, but never pushed — so anyone else merging the same two branches recreates the conflict from scratch, since your resolution doesn't exist anywhere but your machine
• You resolved the conflict but forgot to git add the resolved file before committing, so the merge commit still contains the unresolved (conflicted) version, even though your editor shows it as fixed
• The same two branches are being merged repeatedly without the earlier merge commit being part of the ancestry Git checks — common when a long-lived feature branch is repeatedly merged with main instead of being rebased, and the merge base calculation ends up comparing against an older point than expected
• A rebase or cherry-pick reintroduced the same changes from a different commit hash, which Git treats as a completely new, unrelated change — so it conflicts again even though the resulting content is identical to what you already resolved

The Fix

First, confirm your previous resolution actually made it into a commit, and that the commit was pushed:

git log --oneline --merges -5
git push origin your-branch-name

If the merge commit with your resolution never got pushed, that's very likely your root cause — push it, and the conflict should not reappear for anyone merging against that branch going forward.

Next, double check that the resolved file was actually staged before the commit. After resolving conflict markers manually, Git requires an explicit add step — skipping it means the conflict technically isn't marked as resolved from Git's perspective:

git status
# look for "both modified" - if it's still listed there, it was never staged
git add path/to/file
git commit

If you're repeatedly merging a long-lived branch instead of rebasing it, consider switching strategy. Merging the same two branches over and over tends to recreate similar conflicts each time, since the diff Git evaluates grows with every merge. Rebasing your feature branch onto the latest target branch periodically keeps the history linear and tends to produce fewer repeat conflicts:

git checkout your-feature-branch
git rebase main

If the conflict is being reintroduced through cherry-picks or rebases creating new commit hashes for the same logical change, use Git's rerere ("reuse recorded resolution") feature, which remembers how you resolved a specific conflict and automatically reapplies that resolution the next time the same conflict pattern appears:

git config --global rerere.enabled true

Once enabled, the next time you resolve a matching conflict, Git records it — and future identical conflicts get resolved automatically without you repeating the manual work.

Still Not Working?

If the conflict keeps coming back even after confirming the merge commit was pushed and properly staged, check whether two different people are independently resolving the same conflict differently on separate branches that later get merged together. In that case, the "reappearing" conflict isn't really the same one — it's two different, incompatible resolutions colliding. Coordinating who owns the resolution for that specific file, or discussing the conflicting change directly, resolves this faster than repeatedly re-resolving it in isolation.