automatic merging from master to release branches

[Rob Ormond]

Hi,

We follow gitflow branching model here, which means master is our current production code, and we create release/* branches for things as they are going through QA before release.  When a version is pushed to production we merge the release/* branch into master, and delete the release branch.

Now, when we have a hotfix applied directly to master, it automatically merges into our develop branch, but not any release branches.

Following gitflow, I would expect any hotfix applied to master would get automatically merged into any release branches, and develop.

Is there a reason it isn't doing this?

Cheers,

Rob

[Kristy · Accepted solution]

Hi @Rob Ormond,

I'm a little bit confused because in one sentence you say you delete the release branch and then in the other sentence you say you want something to merge into the release branch. Do the release branches still exist or were they deleted?

That aside, you cannot have master merge back upstream into your release branches. The point of having the release branch separation is that downstream release branches are always *ahead* of the upstream release branches. This is so that new features and potential bugs from newer versions don't accidentally find their way onto old versions.

When you have a hotfix, you need to find the version that it originated. You should then create a branch from that release branch to create the fix, and merge the fix to that release branch. If you have automerge enabled in your branch model then merging to that release branch will propagate the chnages downstream to the later release branches and eventually to master etc.

Hope that helps, 

Kristy

[Rob Ormond]

Hi Kirsty,

Sorry I wasn't clear.

When we do a release, we merge the release branch into master and delete the release branch, but at that time there will be 1 or 2 other release branches (for future versions) that are in QA.

So master is always production code, release branches are what is in QA (and there may be multiple of these).  This is how I understand gitflow to work.

If we leave the release branches around after we merge the code into master, and create hotfixes for production code from the release branch, then the opposite problem exists where the hotfix won't get merged into master automatically.  It'll be in the release branch, and any other release branches that exist that are newer (higher version), and develop, but not master, which is actually meant to be production code.  So either way we'll need to do a manual merge for hotfixes.

I hope that is clearer now?

Cheers,

Rob

[Kristy]

Hi Rob,

That makes more sense now, thanks.

I made a mistake when I said that the release branches will eventually merge to master. It does for my team because our configuration is that master is the development branch and we have no 'production' branch.

However, for your configuration that is not the case.

I've checked the behaviour of Bitbucket Server and found that if your configuration is roughly like this:

Then the resulting automerge will look something like this:

Note that it does not merge into the production branch (master) here.

This is intended behaviour as explained in BSERV-9740 because our interpretation of GitFlow is that merging changes to master is an explicit step should be taken only when a new release is cut.

In the case of a hotfix, you're likely going to want to cut a release straight away - but the timing of when that happens is up to you and shouldn't be dictated by a tool. For all Bitbucket knows, you may have multiple hotfixes that you want to release at the same time in which case you would wait for all of them to merge to develop before merging to master to cut the release.

Hope this helps. Let me know if anything I've said isn't clear,

Kristy

Bitbucket Server Developer

[Rob Ormond]

Thanks, what you are saying makes sense.

Is there a feature request for optional auto merging? Eg, instead of just showing up what it is going to merge into, allow the user to choose which branches it should auto merge into, maybe with some defaults of what it is doing now (downstream release branches, develop, etc)

[Kristy]

Maybe  BSERV-4241?

[Jorge Suarez]

Hi, resurrecting this as I have the same original question but the marked answer does not address it.  

I understand that auto-merging bugfixes on release to master (production) is not desireable, got it and agree.

However, the question is when a hotfix is applied to master, why is the next release not included in the auto-merge chain.  This should be the primary scenario, which is patch production with a fix and apply that fix to current development and release/QA branches.

In the Merge Pull Request picture in Kristy's post this would mean the target of the PR is master and would be the desired effect is the same as inserting master in the picture between the hotfix and release/1.

This is absolutely desired in the gitflow scenario that we use and that is promoted on Atlassian.com and is what the OP originally asked.  Again, the inverse is not desired as already established. 

[Rob Ormond]

Hi Jorge,

Assuming that your release branches as long lived (i.e. they still exist for older versions that are no longer in production) then how would bitbucket know what is the next release that the hotfix should be automatically merged in to?  Even if your release branches are not long lived, it has to support that for other users.

For example, let's say you have

release/1

release/2

release/3

and master is currently at release/2, but you've left the release/1 branch around for history.

If you did a hotfix against master, how would bitbucket know to not merge the change into release/1?

So what we do is all our hotfixes are actually done against the release branch of what is currently in master.  We have a PR for a hotfix against release/2 in my above example, we merge that in, do QA, then create a new PR from the release/2 to master when the fix is ready to go to production.

This way we keep our branches nice and clean, we know exactly what's where (what's in QA, what's in PROD etc).  And as a nice bonus the automated merging works perfectly for this scenario, when the hotfix is merged in to release/2 it is merged in to release/3 and develop!  Nice!

[Jorge Suarez]

Hi Rob, 

  Ok I understand that scenario for you.  Without getting into a philosophical discussions about the standard gitflow model, we don't use any long lived branches and typically have only a single release branch at a given time, which gets deleted when it is merge with master.     So my modification of the diagram is a misnomer, though I could see us setting up for the current and next releases if need be.  Essentially, we are not using any maintenance branches.  Perhaps this is because we primarily develop commercial, customer facing websites and APIs that don't require maintaining fixes for legacy versions that customers remain on because they don't want to upgrade to the latest and greatest.

  Instead of keeping our release branches around, we simply create a tag on master with the version that went out the door and delete the release branch; if we really needed to we can checkout that tagged commit and branch from that point, essentially retrieving that branch.  I suppose that would be the same as if you simply prefixed your released branches with archive_release/1, or rename to releaseD/1, etc.

  The scenario you are describing is basically the same thing that we face, because you still have manually create a PR to master after creating the PR to release.  It's not a huge deal to remind our devs to create dual PRs, but the more standardization we have in place the less likely someone is to forget. 

   Additionally, I am now facing a situation where one of our teams has multiple 'develop' integration branches to work on what are essentially features that are several releases away.  But it appears that the final stop for auto-merge is the singular 'develop' branch.  It would be nice if auto-merge included any branch with the 'develop' prefix, like it does for release.  EG:

develop

develop_largefeatureX

develop_2021vision

    We can write custom scripts to do this, but I think the most generic solution, which I hope is in the works, is to allow adding multiple branches as a destination to a pull request, and not determine the auto-merge branches at the time of merging.  After all, that popup that shows which branches will auto-merge only shows after the PR is approved.  Approvers are therefore saying it is ok to merge these changes into unknown branches at sometime in the future (eg, if someone creates a new release for which the changes is not desired sometime between when the approval is given and when the merge is done, a previously non-existent branch would show in the list - haven't tested, but my understanding is that it would work this way).

Thanks for the input!

[justinhp]

I would just like to add that in the gitflow documentation it describes what to do in this scenario, where you have a hotfix and a release branch at the same time.

"The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished."

I'm not sure why this part of gitflow was missed or not implemented, but I imagine this a fairly common issue especially if the team is using the documented gitflow.

[Kristy]

Can you help me understand what you think was missed? Do you mean missed in the Bitbucket Server branch model? Because its certainly possible to create a hotfix branch from a release branch and when that is merged into the release branch, the release branches will automatically cascade down into later release branches and then develop. Perhaps I'm misunderstanding your point?

[Nikolay Kojuharov]

I'm in the same camp as Jorge (although, I've had projects following other models).  But currently, release branches are created for upcoming releases and when ready they are merged into master which is the current production state.  We use tags to track deployments of master to various clients and we create hotfixes off of those tags.  

So in the above model once a hotfix is merged to master, it needs to automatically propagate to all release/* branches and the development branch.  Currently, the Bitbucket behavior is to only do master -> development because it assumes that release branches are upstream instead of downstream, which is our case.

[Rob Ormond]

Hi Nikolay,

Yeah, that's the same situation I was originally in.  So I changed our process to keep the release branches around after merging to master when they go to production.  Then we just keep using the release branch, rather than a tag, for hotfixes etc.  Works fine.  Change your process to match gitflow/bitbucket, rather than expect bitbucket to match your existing process. 

[martineca]

Hi Kristy, 

The whole discussion here is going around the auto-merge feature offered by Bitbucket so I am not sure why you got the context of branch models. What Justinhp said is missing, is the simple logic of having prs merged into master to get auto merged in the latest release branch that is still live + the development branch.

I don't know why is the release marked as branch that is upward of master when it is not. Currently this misalignment reduces the usage of auto-merge because you need to always create extra prs manually when a hotfix is going to master. 

Also, I disagree with Rob as what he has describes is not gitflow. It is a change to adapt to the wrong auto-merge feature. 

Is there a way to request an option to auto-merge the hotfixes in release branches as well? Please let me know, thank you!

[sorzechowski@marketaxess.com]

Hello,

Hitting this exact same scenario where PRs merged into Master are only be auto merged to develop and not merged as well to what we consider downstream release branches. 

Ideally this should just work with auto merge, should not have to tell devs to make multiple PRs when hotfixing changes on master. Everything downstream should also get the changes (develop, release branches)

Are there any updates on this?

[Joyce Huang]

Hi,

I have been using Gitflow and it's very convenient, but I realized only recently that the hotfix to master will not propagate down to release branch.

After reading through the comments above, what's desired in our team's case is what @Jorge Suarez said. I am not sure what configuration can help achieve the following

Any feedback or input is appreciated. Thank you!