Merge conflict on unchanged files when working on the same branch

Question

Two people, A and B, are working on the same branch. Person A pushes changes on file X to the branch. Person B has not touched file X and does git pull. This resulted in a merge conflict on file X. Why does this happen, and how does person B avoid, or handle this situation?

Answer 1

Person B should inspect the history of his local branch, compared to the history of the remote branch :

git log --oneline --graph <branch> origin/<branch>

# you possibly want to only see what commits impacted file X :
git log --oneline --graph <branch> origin/<branch> -- X

# generic shortcuts :
#  - "the commit I'm currently on" is HEAD
#  - "the tracked upstream branch" is @{u}
git log --oneline --graph HEAD @{u}

I suggested terminal commands to view the history, most of GUI frontends also allow to view the combined history of several branches.

---

Possibilities include (but are not limited to) :

• person A committing her changes with commit --amend or rebase, and uploading her changes using push -f,
• person B having rewritten part of her local history (e.g : commit --amend or rebase) before pulling.

I don't really see how a conflict can occur without a history change, but perhaps I overlooked some possibility. Anyway : the history view should highlight something.

---

The most appropriate way to "fix" this situation depends on what you see in the history, some generic ways are :

• person B can rebase her changes on top of the most recent version of the remote branch ; if there are redundant commits to drop, she can use rebase --interactive, and mark "drop" in front of said commits

• person B can simply fix conflicts in the merge she has ; if she knows for sure that the correct version for file X is the one pushed by person A, she can run :

# remove the "conflicting" flags :
git reset -- X
# use the version from the remote branch :
git checkout origin/<branch> -- X