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:

Answer 1

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

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.

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.

Answer 4

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.