Is there a full list of how Bitbucket Server treats branches in a branching model?

[Chris Cogdon]

I'd like to know all the ways Bitbucket Server treats the various branch types in a branching model. This is to determine the best way to integrate these into our workflow here.

Here's what I've found so far:

• Jira can create branches from a ticket based on the ticket type, and which branch types are enabled for the repository. [ref]
• Automatic branch merging makes use of release, production and the dev branch types. [ref]

Are there any others?

Also, it's not clear from the Automatic Branch Merging doc the exact algorithm in terms of the difference between release and production branches. If both are enabled, are they independent, or is it something like the following? :

• [If enabled: Release branches with versions being cascade merged] > [Production branch, if enabled] > [Development branch, if enabled]

And does Production branches have the same version cascade? If so, are the release and production branches interleaved? Eg: release/4.3.2 -> production/4.3.2 -> release/4.3.3 -> production/4.3.3... or the other way around ?

I thank you for any information you (yes, you, reader!) can provide!

[Aaron · Accepted solution]

Hello Chris,

Welcome to Atlassian Community!

I think there is a bit of confusion that I would like to attempt and clear up here. You are mentioning "production branches" but you can't have more than one production branch at a time. If you go to the branching model settings in Bitbucket you will see that you can set a production and development branch. This is different from the release branches. So you can have numerous branches as release branches with semantic versioning, while you will only have one development branch that you will be branching from and merging back into, and a production branch.

Bitbucket will only attempt to do any automatic merging if you attempt to merge code into a release branch, or production branch. If the target branch is a release branch, it will cascade into the semantic versioning names of the release branches (1.0.0 > 1.0.1 > 1.1.0) and then into development. If the target branch is a production branch, it will automatically merge into that production branch and then the development branch.

Please let me know if I can help clarify anything else or if you have any further questions with automatic merging :)

Regards,
Aaron Levinson
Dev Tools Support Engineer