Why do merge conflicts happen?

Question

For example:

• I have a master branch.
• I create a file file.txt and I write Master branch in it, and then I commit it.
• I create another branch called fix20, and modify the text of file.txt to This is fix20 branch. Then I commit it.
• I switch to the master branch and then I create a branch hotfix and switch to it.
• I modify file.txt to have the text This is the HotFix. After that I commit the changes.
• Now I switch back to the master branch and merge it with the hotfix. The file (with no problems) changes it text to This is the HotFix (They are basically merged)).

Now I merge with the fix20 branch and I get a merging conflict. The file.txt has both the text from fix20 branch and the text, that I had after merging with HotFix. At this point, I should open an editor and decide, what should be left, and what should be removed.

The question is: Why does the merging conflict happen the second time? Why didnt I decide which text to leave, when I merged the master with the hotfix? Why havent the files been merged, when I merged with fix20 branch (why the text was not just replaced as with the hotfix)? Why basically this conflict happens the second time and not the first one???

Answer 1

The problem here is that you know your intention... but Git doesn't.

This is how Git looks at what you did: you made two independent changes to the same line. When you merge the first one, your intention is clear: you want the change to become part of master. Since there haven't been any changes in master itself since you branched off, there is no problem with that: Git can always directly merge a piece of code if only one side of the merge changed it.

When you try to merge your second change, that is no longer true: by merging the first branch, you have introduced changes to master that are not directly "compatible" with the changes in the second branch. Git calls this: "the branches have diverged". Git doesn't know whether you'd rather keep the stuff you merged from the first branch, or the stuff you are merging from the second branch.

In your situation it's obvious to you because the second branch is a newer fix of the same thing... but many merges involve more complicated changes to the code, and maybe the correct way to merge the second branch is to combine the changes from the two merges: often, if two merged changes touch the same line of code, both will have to leave their marks on it.

Example original code:

send_request("bake cookies")

Branch 1:

send_request("bake cookies", additions: ["chocolate"])

Branch 2:

send_request("bake cookies", flour: "wheat")

The correct way to merge both of these probably isn't to take one of the two lines verbatim, it's probably more like this:

send_request("bake cookies", flour: "wheat", additions: ["chocolate"])

Since you know the intention of your code much better than Git, Git will never make an automatic decision in this kind of situation.