Understanding why git auto merge keeps the older version of a line

Question

We have a branch "sprintX" and a "master" branch, during our sprint we push to the sprint branch and at the end of the sprint, we merge it into master. A few times during the sprint we merge master into the branch for getting the hotfixes.

Today we try to merge master into our branch and we have multiple conflict on file that were not updated since the branch creation and the git auto merging keep the file from the master branch ie removing our new code into our sprint branch.

We would like to understand why is git resolving the conflict that way and how can we change our way of doing things for avoiding it ?

Answer 1

Most probably someone some time ago used a "revert" option to remove that line on the master branch, or any patch branch that was merged to master, but not to your current sprintX. In this case, "master" branch knows that it was changed and then undone, and thinks that the old version is the correct one, while your sprintX has not seen the revert and thinks that the new version is the correct one. Bam! Conflict.

Go to master branch and carefully check the history of this file. Check that line and see when it was changed back/forth between new and old version. Look for any explicit "reverts" (commits named 'revert') or implicit (someone simply edited the file back to old form) or reverts-by-uncareful-merge (someone did a merge that overwrote the line with old version). Really. All of that. It's because "revert" option is just a commit. There is nothing special about it. It could be a direct revert, or accidental, and the things I just listed ae the most common things that force a branch to have an old-version-of-something.

Then, knowing where it happened on master, check history around that places, and try to guess why that person (who did it the revert) did not include it in sprintX