Merge plugin
The merge plugin replaces the default merge functionality from Bitbucket Cloud and adds support for:
- Enforced merge extended checks
- Restricting strategies and options
- Rebase strategy
- Redundant builds prevention
The simplest configuration is:
ts
import {configure } from "flowie.app"import {merge } from "flowie.app/plugins"configure ({plugins : [merge ()],})
Advanced examples using options:
ts
import {configure } from "flowie.app"import {merge } from "flowie.app/plugins"configure ({plugins : [merge ({allow : ["Team leaders"],strategies : "rebase_fast_forward",select : false,}),],})
using rules and conditions:
ts
import {configure } from "flowie.app"import {merge } from "flowie.app/plugins"import {target ,labels ,otherwise } from "flowie.app/conditions"configure ({plugins : [merge ([target ("master"),{autoMerge :labels .has ("Auto-Merge"),},]),],})
Options:
autoMerge
- Automatically merges the pull request when all the extended checks
are passing. It relies on the default values for the merge options as well. Default: false
allow
- The groups that are allowed to merge. By default, anyone that has write permissions is allowed to merge.
strategies
- The strategies that can be used to merge the pull request. It can also be a single strategy. Default is all existing strategies.
e.g. "rebase_merge"
or ["merge", "squash", "fast_forward"]
. See the all supported strategies here.
closeBranch
- Whether the branch should be closed after the merge is performed. Default: Inherits the value specified when
the pull request was created.
commitMessageTemplate
- Template for using for the merge commit message. It’s
only supported when using auto merge or default value - it won’t affect the commit dialog.
preventRedundantBuilds
- Redundant builds prevention feature when merging. Default: false
select
- Defines the options that are can be selected. It affects the merge commit dialog.
Default is to allow all values to be selected; false
locks the values to the defaults.
Enforcing merge checks
The merge plugin will only show the merge button once all the extended merge checks are passing.

Permissions
In order to support enforced extended checks, Flowie uses Bitbucket branches restrictions. It updates the permissions of the repository to only allow Flowie to perform merges. This is due to current Bitbucket limitations on creating custom checks, so to overcome this limitation Flowie implements its own enforced checks.
The changes to permissions are performed when applying the configurations and the
merge plugin is enabled. The default changes are usually suitable for most
installations, but if you need to customise it, you can use the branch.restrictions
property in the configuration. You can also disable the
permissions change for debugging purposes or to work around an issue.
When the merge plugin is removed or the branch.restrictions
are disabled, the previous permissions will be restored.
Restricting merge options and default values
It’s common when defining your workflow to pick a merge strategy e.g. only use merge commits when applying to master. The merge plugin allows you to enforce and restrict the options available.
By default, all the merge strategies will be available, but you can use
the strategies
option to restrict them:
ts
merge ({strategies : ["merge", "squash"],closeBranch : true,})
This configuration will restrict the options to only the strategies specified and close branch will be selected by default.

You can also restrict the options that can be selected in the dialog using
the select
option:
ts
merge ({strategies : ["merge", "squash"],closeBranch : true,select : ["strategy"],})

Now ‘close branch’ will be always true and can’t be changed, the user can only choose the strategy.
You can also enforce the all the options by setting select
to false
as below:
ts
merge ({strategies : "rebase_fast_forward",closeBranch : true,select : false,})

Because there is nothing to select, Flowie will show the merge button without a dialog and when pressed it will use rebase as the merge strategy and close the branch.
Strategies
The merge plugin supports all the Bitbucket Cloud strategies and adds support for additional strategies, including rebase.
merge
Always create a new merge commit and update the target branch to it, even if the source branch is already up to date with the target branch.
fast_forward
If the source branch is out of date with the target branch, create a merge commit. Otherwise, update the target branch to the latest commit on the source branch.
fast_forward_only
If the source branch is out of date with the target branch, reject the merge request. Otherwise, update the target branch to the latest commit on the source branch.
rebase_merge
Commits from the source branch onto the target branch, creating a new non-merge commit for each incoming commit. Creates a merge commit to update the target branch.
rebase_fast_forward
Commits from the source branch onto the target branch, creating a new non-merge commit for each incoming commit. Fast-forwards the target branch with the resulting commits.
squash
Combine all commits into one new non-merge commit on the target branch.
squash_fast_forward
If the source branch is out of date with the target branch, reject the merge request. Otherwise, combine all commits into one new non-merge commit on the target branch.
Redundant builds prevention
Avoiding redundant builds saves time and resources by eliminating the need to reprocess unchanged code, leading to cost savings and better use of continuous integration servers. This also reduces the feedback loop for developers, boosting productivity and allows them to concentrate on valuable tasks like adding features or fixing bugs.
Whenever a Git operation results in an identical set of changes, altering only the log, Flowie can prevent a redundant build and preserve the status if there is already a passing build for those changes. This applies when the branch is up-to-date and a fast-forward merge is executed, or when rebasing it solely to eliminate merge logs.

Even though you might attempt to bypass the build process manually, pushing changes like a rebase will reset the build results. Consequently, if your workflow requires a passing build check, you’ll need to rerun the build for those changes.
This behavior can be enabled or disabled in the plugins that support it.