How to properly merge different "dev" branches into master?

Question

I have a master branch and two other branches, "dev1" and "dev2" both created from master. But if person1 modifies one line and does a push into dev1 and then create a merge request into the master branch, it won't show a merge conflict, just show that a line was changed to a new value. Then if person2 who hasn't done a git pull yet, does a git push to the dev2 branch and then create a merge request into master, the line that was modified by person1 will be modified again to the old value that person2 still had in their repository.

But if I create a merge request from dev2 to dev1, then it will show a merge conflict over the value that was changed. I'm confused as to why it only shows when I'm trying to merge these two and not when I try to merge into the master branch.

Can anyone explain me what i'm doing wrong and what is the proper way to merge? Thank you.

Answer 1

In general, when 2 people modify the same bit of code, there is no getting around the need for manual merge conflict resolution. After all, how is git supposed to know which branch is the "right" one? Using a recursive merge strategy like -s theirs or -s ours (or the non-recursive -ours) might be OK, but those are the "scorched earth" approaches to merge and they don't really get to the core of the issue: how can we take 2 different changesets on the same file, automatically merge them together, and end up with something that works (much less works the way the author intended...)?? Conflicting changes on a file generally need to be dealt with manually; Git is smart, but it ain't that smart....

Let's look at your examples.

Person1 and Person2 create their own branches off of master. hack hack hack. Person1 commits and pushes some changes. Person2, having not pulled the latest changes (those made by Person1), attempts to push a change set which is in conflict with the latest version of the master branch. Those changes will be rejected by the remote repository (probably Github) because there is a conflict and Person2 is attempting to push changes that are missing the commit from Person1.

If Person2 attempts to merge the changes made by Person1 into their own branch before pushing, they will still have a conflict. But in this case, Person2 will be able to sort through it (maybe with some help from Person1) manually, so that the next push will include both change sets, cleanly merged, and git will be happy again.

---

I just reread this a bit more carefully, and noticed that you did not mention whether the merge request raised by Person1 had actually been merged by the time Person2 raise the second request.

If the merge from Person1 has not yet been merged, then at first there will be no merge conflict for either branch due these commits. In effect, the 2 branches are still on equal ground in a race to get their changes merged first: whoever wins will get a clean merge, and the one left pending will then be in conflict with those changes.

The reason it works like that is that Git/Github is only comparing the source and target branches (dev1 <--> master, and dev2 <--> master). It does not compare pending pull requests to one another. In fact, there is really no way to compare 2 pull requests using git¹, because the whole "pull request" concept exist purely in Github. Git has no understanding of pull requests, so until one of the merges is complete nothing will actually change in git, and no merge conflict will exist.

But in both cases there will be a merge conflict sooner or later. it's just a question of when that will happen:

• dev1 --> master followed by dev2 --> (conflict) --> master

• dev1 --> (conflict) --> dev2 --> master

---

_{1 Not quite true: the underlying commits on these two branches can be compared on GitHub or by using git diff, but this is not taken into account when merging pull requests to a third branch (nor should it be).}