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?
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) :
commit --amend or rebase, and uploading her changes using push -f,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