It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Automatic branch merging + branch workflows

cricket Jul 15, 2016

This question is in reference to Atlassian Documentation: Automatic branch merging

I've studied this awesome document:

https://www.atlassian.com/git/tutorials/making-a-pull-request/

This suggests that release branches should be created only for the endgame of a release cycle. This is how we currently use release branches. However, you also have this automatic branch merging feature that applies only to release branches. If you have a "1.0" release branch for finishing up 1.0, but it's recommended you don't create a "2.0" release branch until the endgame for that release. Given that, when would branch forwarding actually be useful? By the time you create the 2.0 branch, 1.0 has long shipped so there would be nothing to commit to it that would need to get forwarded.

I'm missing something here, so I hope someone can help out!

c

1 answer

1 accepted

2 votes
Answer accepted
Stefan Petrucev Atlassian Team Jul 17, 2016

Hi,

With multiple release branches, automatic branch merging can be useful when you need to fix an issue on earlier, still supported release. Consider an example where the latest release is release/2.0, but a critical bug was found in release/1.0 and this was still a release being used and supported. With automatic branch merging, a fix could be made via a pull request targeting release/1.0, and this fix would automatically cascade to all later release branches (including release/2.0), and onto master (assuming the development branch is set to master).

Kind regards
Stefan Petrucev
Atlassian Bitbucket 

Adam Ahmed Atlassian Team Jul 17, 2016

Stef has stated the main use case for our team perfectly. In addition, we also create our release branches slightly before the ship date (typically about a week). This way new/risky code not meant for the upcoming release can be merged directly to master to avoid contaminating the release, but any bugfixes/polish on the release branch can still be cascaded to master automatically.

cricket Jul 18, 2016

Thanks, that helps! One of the reasons I was asking is that conceptually I like the idea of having a release branch for upcoming known releases and not waiting until the last few weeks. The explicit nature of saying "I'm committing this to 2.0" rather than putting it in master just because there's no release branch yet. I see the downsides (more merging), but it avoids the very common discussion I hear in the hallways ("what is master right now? is it release x or release y?"). Also, it seems easier to drop things on the floor if it always goes to an explicit release branch which cascades down to later releases and to master.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published in Bitbucket Pipelines

Building a Bitbucket Pipe as a casual coder

...ipe.sh :  #!/bin/bash source "$(dirname "$0")/common.sh" enable_debug extra_args="" if [[ "${DEBUG}" == "true" ]]; then extra_args="--verbose" fi # mandatory variables R...

1,925 views 1 19
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you