We currently integrate JIRA and Bitbucket server together for our development, and we pretty close to a 1-1 mapping between JIRA projects and Bitbucket projects. My question is that when a user goes to create a branch from a New Feature, it seems to default to branching from the master branch, even though we use the git-flow branching model with feature branches. Additionally, Improvements, which are a default issue type in the JIRA templates, tries to produce a bugfix branch.
Where can I change these mappings?
EDIT: Additionally, when we try to merge them back in, they all seem to try merging into the production branch, not the development branch.
Seems I have misread your question as related to Bitbucket Cloud (despite the definite tag), sorry about that.
Your workflow can be mapped to branches in the Bitbucket Server 'branching model', allowing Bitbucket Server to:
- guide your developers into making consistent naming decisions when creating branches.
- identify the type of each branch and apply actions like automatic merging accordingly.
Notably, Bitbucket Server allows you to Configure the branching model to define the branch workflow for each repository:
As a project administrator, configuring the model lets you:
- enable the branch types that will be available in your workflow.
- specify the naming convention to be used for each branch type.
The naming convention simply adds prefixes to branch names, so that branches of the same type get the same prefix.
As further outlined on that page, Bitbucket Server makes a number of branch types available:
Aside from configuring the prefix so that the appropriate branches are mapped you can also Use the checkboxes to enable just those branch types that map to your workflow.
The most relevant setting regarding your workflow seems to be the 'Main branch' of a Bitbucket Cloud repository, which you can change from a repository's 'Settings' page. It indeed defaults to 'master' for Git repositories for example, so even after e.g. initializing Git flow via SourceTree, one still needs to adjust said 'Main branch' manually to henceforth use the 'develop' branch and achieve the desired workflow defaults:
Hmm. I guess that sort of stopgaps this particular issue, but I feel like the branching model should force some element of where branches are created and merged back into. For instance, hotfixes should always come off of the release branch. I'm curious why there are two separate options for what constitutes the "main" branch. Thanks for your response.
So I have all of that in place, but it doesn't cover the JIRA link. The main issue at play is that a JIRA improvement will map correctly to a feature branch, but the branching point will be based on the "Main Branch" that you mention in your original answer (so this is an improvement). However, something like a hotfix would need to be tied to the release branch, and I can't find anything that forces the branch point to be different based on the branching model type. I just took another quick look at the Branch Permissions portion of the configuration and it doesn't have what I'm looking for, either. Thanks for your update.
I see, makes sense - I'm not aware of an option to tie the branch point to the issue type for example (similar to how the branch type and name are inferred), even though it would be an obvious improvement accordingly. You might want to watch/vote/comment on https://jira.atlassian.com/browse/BSERV-2491 to raise the priority for this kind of branching model granularity.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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