Gitflow: Merging release bugfixes back to develop from master

Question

My question is around a very specific point in the gitflow process (as documented here).

I've already merged bugfixes from release/1.2 into master, and tagged appropriately.

Apart from how the history looks, what are differences between back-merging from release/1.2 vs back-merging from master into develop.

I have tried both ways, and in my simple, contrived example I see no difference in develop, as I expected.

Are there dangers to this? Am I going to encounter messy issues later on? Am I missing something obvious? I suspect the answer may be to do with other features that have gone into master, but which should remain out of develop for the moment.

merging release in to develop:

merging master in to develop:

Plage

Could you include a diagram showing your flow? Maybe someone who uses Git flow heavily would follow your description, but I don't. – Questa

@TimBiegeleisen done! – Plage

Answer 1

If you merge master back into your develop, you will have all the merge branch release/x.y into master merge commits in your develop branch, while when merging the release/x.y branch itself, you only get the real changes.

Of course, this is more or less a cosmetic issue. But the merge direction is usually only from develop to master, never the other way around.

There are no real dangers except for said merge commits cluttering up your develop branch. If you stick to the flow, there should never be features in master that are not in develop, since hot fixes as well as release branches should always be merged into your develop as well as in master.

Octagonal

Good points. I don't think I intend to deviate from the process, this is more of a curiosity question. – Plage

Anyway, you have not answered question. Non-accepted answer below has more details and more deep explanations. – Lucite

This answer is slightly misleading in that eventually all the merge commits end up in develop regardless. – Downstroke

Could you elaborate? As I understand and practiced GitFlow for years, these commits never end up in develop since there are never merges from master to develop, only the other way around. – Octagonal

@Octagonal because hotfixes branch off of master, so they will include all of the merge commits that have been sitting on master since the last hotfix. When you complete the hotfix branch you merge it back to develop. I suppose if you never do hotfixes you may never have seen them... The first time I did a hotfix and saw this, was when I decided to switch to merging master back to develop and I've preferred that ever since. – Downstroke

@Downstroke You're right, hotfixes branch off and merge into master, but instead of merging them back to develop, we cherry-pick the relevant commit(s) to prevent the backwards merge. Feels cleaner to us, but after all it's not that important and just a nuance of how you implement the workflow. – Octagonal

Answer 2

Are there dangers to this? Am I going to encounter messy issues later on? Am I missing something obvious?

No dangers; no issues; and you're not missing anything. Merging master back to develop is (IMHO) the slightly better way to go, and there are no downsides. Either way you choose you will always end up with the same total number of merge commits in develop. The difference is only the timing of when those merge commits end up there. If you merge release back first you don't get all of the release to master merge commits until later, all in one shot when you do a hotfix. If you do master back to develop you see the recent merge commits right away. But there's an even bigger advantage of merging master back to develop:

At all times it's important to make sure all changes in master are also in develop or in release when it exists. (The only time they should ever be out of sync is during the completion of a release or hotfix branch.) Perhaps the easiest way to confirm master is synced up is to make sure the tip (top commit) in master is always in develop, or release when it exists. You could easily script that to run at some regular frequency and notify you if it's not true. That script is more complicated if you can't expect the tip commit of master to ever be in release.

Downstroke

Answer 3

I suspect the answer may be to do with other features that have gone into master, but which should remain out of develop for the moment.

Commits from master go into develop with next hotfix merge anyway. If there were real code change, it could be unexpected outcome and distort the hostfix content.

Merging stable branch (master in gitflow) into development branch (develop in gitflow) is known way in various git workflows. Bbitbucket Server (commercial solusion being sold by Atlassian) has a feature of Automatic branch merging. Git project itself always merges branch maint into master as there is some bugfix.

So I don't really see the reason why gitflow's author has chosen another way. It might be that there is no real rationale, it was just an accidental decision.

Haunt

Answer 4

I like to do it so it doesnt look like master is ahead of develop in the list views. If you merge master down to develop instead of release branch and hotfix it will make it so master is never ahead of develop in list view and if it is you know something has gone wrong and needs to be fixed

Rainmaker