Would like to start off by saying that we love the Automatic Merging feature in bitbucket. However, we have a usecase where we need to disable Automatic Merging to specific feature branches, but leave it on for others.
This is largely do to our branching strategy, so either some advice on how to better tackle this scenario, or pointing out a feature/plugin that allows me to exclude a specific release branch from the Automatic Merging selection would help.
We've adapted our branching strategy to be what is basically recommended here:
under the "Continuous delivery workflow for installed products" section. For our uses however we've modified the model a bit so that we keep release branches that have been released as "hotfix" branches, and create an additional release branch for each support version thereafter. Additional commits to a released branch would automatically build under the same version, but with an incremented build number of sorts, and be "promoted" on validation.
The issue here is that we maintain multiple versions, so any update(s) to an older version of our product on a lower release branch will automatically merge into our "hotfix" branch, which should be isolated. This is an undesirable result, as we do not want potentially unstable code to be shipped with a hotfix.
The solutions that I can come up with are to:
1) Rename the branch after a release, undesirable in our case, as we track the build numbers based on the branch name.
2) Somehow exclude the released branches, as the release process is automated, an API call to do this would ensure we can automate this process fairly easily.
3) Change our branching model, have releases off of "hotfix" branches. Closely tied to the reason why we don't want to do 1), this is undesirable as we would need a different process to track our build numbers.
Note: We track the build numbers with a mix of git depth + git notes, when a branch with "release" is created, we trigger a post-receive hook to automatically create a git note on the commit the branch was created from. This is then used as the origin point for the branch, on build, we determine the number of commits from the origin to the head and use that as the build number. If either option 1 or 3 were done, we would have to find a way to additionally update the corresponding notes to keep the build number sequential
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs