Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Different merging strategies for master and plan branches

Is there a way to have a different automatic branch merging configuration for the master branch and what automatically created plan branches inherit?


While we use a standard feature branching model branching off of the master branch, we have some branches 'further upstream' for test and production work.

feature-branches -> master -> testing -> production

This works so far by manually overriding the configuration for the plan branches:

- production: no merging

- testing: auto merges from production

But to make master auto merge from testing I have to manually create a plan branch called 'master-branch' which auto merges from testing and all developers have to remember to never run the default 'master' plan which is a cumbersome and fragile setup (especially for a lot of different plans).

Unfortunately using master as the production setup is also not an option for us because of long testing cycles. That means while master is the current reality and integration point for all developers the testing and production branches can be quite some time behind so using master as the most upstream branch would not work.

1 answer

1 accepted

0 votes
Answer accepted

Master of your plan doesn't have to point to 'master' branch, it can just as well point to 'production' which doesn't require merges.

Another thing you can do is to _disable_ the master of the plan and only build 'master' _branch_ as a plan branch, which at least will make it more obvious for your users that they should not run master plan. Disabling plan doesn't disable the plan branches, they will still build; it doesn't disable branch detection either.

I tested some more with this and discovered that the branch dialog did work different from what I first understood: Instead of being applied to all branches (incl the default branch from the linked repository) this only applies to plan branches and there is no way to apply branch merging to the default branch.

Then I tried using our production branch as the default branch, as initially suggested, but ran into the issue that in the branch merging dialog for whatever reason it is not possible to select git branches for merging, only plan branches. That means to even enable all feature branches to merge from master, I have to first create a plan branch 'master' and select that in the plan branching dialog.

So my current setup would be (without CasC / RSS):

Default branch: production

Plan branch settings: merge from 'master' plan branch

Custom branch 1: called 'testing', merges from project
Custom branch 2: called 'master', merges from 'testing' plan branch

All feature branches would now get the correct settings.

Unfortunately, this is not possible with CasC / RSS:

Since the plan branch settings require the reference of an existing plan branch I'm running into a catch-22 where Bamboo can not create the plan based on RSS because the plan branch within does not exist and I can not create the plan branch because the plan itself does not exist.

------------------ Old Answer --------------

Thanks for the answer! That disabling a plan does not disable plan branches is a good info (although a bit weird)..


I actually used your first part of the solution. We have one persistent feature branch called dev (designed for minor changes where creating a separate feature branch would be overkill) and made this the default branch for the build plans and simply create a plan branch called 'master' which is based on the master branch. Now I do not have any doubled branches and everything is fine.

We're having some issues getting this to work with our setup. We follow gitflow but have the main branch configured as development, master as a plan branch, then all feature branches from development. 

Ideally we'd like any changes to development to be automatically merged into the feature branches, and any changes to master automatically merged back into development. Is this something that is possible with Bamboo? 

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events