Imagine this scenario: your code’s ready to go, your teammates have approved your pull request, and the builds are green. Now you just need to merge your feature branch into master, but you have a choice to make: which merge strategy should I use?
Natively, Git offers several merge strategies. In Pull Request Merge Strategies: The Great Debate, fellow Atlassian Nicola Paoluicci presents the merge strategies that are most popular amongst teams, along with the pros and cons of each option.
As Nicola’s post mentioned, teams at Atlassian lean towards using explicit merge commits:
Bitbucket already supports squash on merge, which results containing your merged changes. The result? A tidy list of commits – one for each merge:
, squashed merges can be undesirable in some cases: you may want to maintain a linear commit history without squashing to a single commit. For example, if your feature includes an API change and a front-end change, you might prefer to keep those changes as separate commits – but you still want a linear history without merge commits.
Fast forward merge strategy
To use the new fast forward option the next time you merge, select it as your desired Merge strategy in the merge dialog:
Default merge strategy repository setting
As a matter of team policy, some teams would prefer to always use the same strategy. To make this easier, we’ve introduced a default merge strategy repository setting.
This setting determines which merge strategy should pre-populate by default when your team members merge a pull request in Bitbucket. From your repository Settings, you can find this option on the Merge strategies page under Workflow.
We hope you enjoy! If you have any feedback to share regarding this feature, tweet us @Bitbucket. Happy merging!