How do you use Bitbucket branch models and branching strategies to support team workflows?

Think of a branch model like a road network in a city. The highway (main branch) carries the final, production-ready traffic. On-ramps (feature branches) let new features merge in safely. Service roads (release branches) handle the final preparation before going live. Emergency lanes (hotfix branches) allow urgent fixes to bypass the normal flow. Bitbucket's branch model defines this road network so everyone drives on the right roads.

Bitbucket's branching model is configured in Repository Settings > Branching Model. You define the production branch (typically 'main'), the development branch (typically 'develop'), and prefixes for branch types: feature/, bugfix/, hotfix/, and release/. When a developer creates a branch from the Bitbucket UI or from a Jira issue, the branch type determines the naming prefix. Creating a branch from Jira issue PAY-567 with type 'feature' automatically names it feature/PAY-567-description. This standardized naming ensures the Jira integration works consistently and makes it easy to identify branch purposes from their names.

The branch model is more than cosmetic. It integrates with several Bitbucket features. Branch permissions can use the prefixes to apply different rules: for example, allow any developer to create feature/* branches but restrict release/* branches to release managers. The Bitbucket UI uses the branch model to display categorized branch lists and to suggest the correct destination branch when creating pull requests. Feature branches default to targeting the development branch, while hotfix branches default to targeting the production branch. This prevents the common mistake of merging a hotfix into develop instead of main.

In production, teams typically align their branch model with their release process. Teams practicing continuous delivery use a simple model: main is production, feature branches are short-lived, and hotfix branches exist for emergency fixes. Teams with scheduled releases add a develop branch (GitFlow-style) and release branches for stabilization. Bitbucket's branch model configuration ensures the UI and automation support whichever strategy the team chooses. Some teams go further by adding custom branch types for specific purposes like 'experiment/' branches that have relaxed quality gates or 'docs/' branches that skip certain pipeline steps.

A gotcha that causes confusion: Bitbucket's branching model does not enforce the workflow by itself. It only configures defaults and UI behavior. To actually enforce that developers create branches with the correct prefixes, you need branch permissions that restrict push access to branches not matching the defined patterns. Without this enforcement, the branch model is a suggestion that developers can ignore. Additionally, switching branch models mid-project (e.g., from GitFlow to trunk-based) requires careful migration of existing branches and pipeline configurations.