Git - Merging develop into master causes major conflicts when it shouldn't?

Question

I am a little confused as to whats happened to my branches.

The process I have been following for a release are:

Create release branch off of develop when ready for release.

Test release branch

Any bugs that are fixed during this time are merged into the release branch and into develop

When release is ready I merge the release branch into master. At this point master has everything for the release and everything that is in develop apart from any new features added after the release branch was made.

However, any time I want to merge release into master I got a plethora of conflicts. But I thought that merging into master would just overwrite anything in master since these are the latest changes.

So I had to take all changes from the release branch OVER the conflict from the master branch to finish the merge.

Now any time I change a file in develop and then try merge into master I get a conflict. Its like the master branch doesn't realise that the code in develop came after or something.

How can I fix this?

In dev ops it states that my master branch is 100 commits behind develop (which is correct as there have been changes since that release) but that it is 2 ahead of develop. The two commits ahead of develop are the merge commits from the release branches into master. Do I need to merge master into develop so develop has those to commits even though there would be no file changes?

Answer 1

First off, I'm assuming you're using the documented Git Flow, or a close variant. If that's true, then:

I agree with you that you should never have conflicts when merging release into master.

So now let's try to figure out why you do have conflicts. The most likely cause would be at this step of your workflow:

Any bugs that are fixed during this time are merged into the release branch and into develop

If you merge a bug fix branch into release, and then turn around and merge that same bug fix branch into develop and if the commit IDs end up being different on each branch, then you definitely could get conflicts later on when those commits on develop end up getting merged into master. Instead, if you merge a bug-fix into release, you should be merging the release branch back down into develop. If you're going to have conflicts you should have them at that merge, for example, if the same files you modified in that bug fix were also modified on develop.

As a rule of thumb, you should rarely ever merge the same branch into two shared branches. Instead, merge it into the higher branch first and then merge that branch down into the lower branch. For example, if you have a hotfix to production, merge the fix into master, and then merge master down to release if it exists, or develop if it doesn't. Or, if you have a bug fix to release, merge it in there and then merge release down to develop.

Sometimes this is unavoidable, for example if you make a fix on develop and then realize you need that in the existing release branch. (Or similarly if you put a bug fix on the release branch but then realize you need the fix in production now.) In that case you have no choice but to cherry-pick the fix into the higher environment, but then you should merge that change down to the lower environment right away and resolve the conflict right then.

If you follow this pattern all of your conflicts will only ever happen when merging master into release (or master into develop if you don't have a release branch), or when merging release into develop. You should never again have conflicts when merging release into master.

Side Note: when releasing to Prod, you don't have to merge the remainder of the release branch back into develop. Instead after merging release into master you can then merge master down to develop. This is slightly cleaner so that you don't have extra merge commits sitting on master that aren't in develop yet. Functionally it doesn't change anything. I, when using Git Flow, use this tactic because I like to see the tip commit of master is always on either release or develop, so that every merge of release into master could be a fast-forward merge, if you wanted it to. (Thus proving it would be impossible to have conflicts when merging release into master.)