@rbarnes I can only agree partly with that. I'm looking for a means to ensure that any source branch being merged via PR is up-to-date with the the target branch, before it can be merged. This is to ensure that we don't introduce bugs / test failures / etc due to the merge / rebase,

The only way to do this currently is via the "--squash --ff-only" strategy:

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.

With the "--rebase --ff-only" strategy it will simply rebase your branch (as expected) during the PR merge, leaving up the possibility to have a broken build on the target branch afterwards.

If we had a "source branch is up-to-date with target branch" merge check instead, we could disable the PR merge until the source branch is rebased (e.g. via the new Rebase button in the PR dropdown menu)

tknerr, Bitbucket already had an --ff-only merge strategy for some time. Now it also has one that will do the rebase for you. No need for merge checks, per se, in either case.

That is an awesome addition to BB server @bturner!

Does it also include a merge check which prevents PR merges unless the branch is rebased on top of the latest state of the base branch?

That is an awesome addition to BB server @bturner!

Does this also include a PR merge check which prevents PR Merges unless the branch is rebased on top of the latest state of the base branch?

One final suggestion: For any organization that has a rebase-heavy workflow and plans to make extensive use of rebase functionality on the server, I'd strongly encourage to upgrading Git on the server to at least 2.6.0.

git-am, which is used to apply patches as part of processing a rebase, was written from being a shell script to being a C built-in, and 2.6.0 was the first version to include the change. Using git-am as a built in makes it substantially faster than the script-based command. For example, we tested a rebase which rewrote 10,000 commits, as part of developing this feature, and Git 2.2.3 took between 5 and 6 minutes to complete the rebase where Git 2.13.6 was able to finish in about one minute. For teams running Bitbucket Server on Windows, the performance difference between the shell script git-am and the C version will be even more significant, due to the higher overhead of launching new processes on Windows.

To be clear: The minimum supported Git version for Bitbucket Server 5.x remains 2.2.0, and all of the new rebase functionality will work back to that version. It'll be faster on newer versions, though.

Best regards,
Bryan Turner
Atlassian Bitbucket

joseph3 I just want to further clarify that this applies only to Bitbucket Server. Bitbucket Cloud (bitbucket.org) is a separate product, with a separate roadmap, and it still does not offer rebase support. (I'll add that Bitbucket Server doesn't have repository size limits; that's a Cloud-only restriction.)

Bitbucket Cloud's issue tracker has several rebase-related issues. I'd encourage you to vote for the ones that meet your needs, or raise a new issue if there's not a good fit already. This BSERV project is not monitored by the Cloud team.

Best regards,
Bryan Turner
Atlassian Bitbucket

Awesome!

After puzzling over this one for a long time, I've finally found an approach that keeps the performance for rebase operations much closer to our "normal" merge performance. Rebases are still slower, but in general they're pretty close.

With the performance aspect finally resolved, I'm pleased to note that Bitbucket Server 5.5 introduces support for several rebase workflows:

• Two new merge strategies
  • "Rebase and fast-forward" rebases the incoming commits from the tip of the target branch and then updates the target branch to reference the newly-rewritten commits, for linear history
  • "Rebase and merge" rebases the incoming commits from the tip of the target branch and then performs a --no-ff merge, producing a "railroad tracks"-style history
    
• A "Rebase" action in the pull request action drop-down (see BSERV-8252) to rebase a pull request's source branch from the target branch at any time, on the server
• A "Rebase" action for ref sync, to rebase changes on a fork's branch from upstream changes made to its version of the same branch
  

For organizations that want to ensure rebase workflows are not used in any repository, a system administrator can add feature.git.rebase.workflows=false to bitbucket.properties to fully disable rebase functionality in all repositories. When the feature is disabled, it cannot be overridden.

Repository administrators can enable the new "Rebase and fast-forward" and/or "Rebase and merge" strategies based on what works best for their project. Both strategies are disabled by default on all repositories; git merge --no-ff remains the default unless explicitly configured otherwise. The "Rebase" actions for pull requests and ref sync are always available, unless the entire rebase feature is disabled.

Adding support for git rebase also includes a new GitRebaseHookRequest which can be used by PreRepositoryHook and PostRepositoryHook to inspect a rebase and, in the case of a PreRepositoryHook, to reject it if desired. Branch permissions are applied to all rebase operations as normal, so if a branch has a rule to reject rewriting history, rebasing will not be allowed.

There are more things we plan to polish going forward, but I hope this MVP set of functionality will be useful. If you have any questions or suggestions, please raise issues!

Best regards,
Bryan Turner
Atlassian Bitbucket

BTW: gitlab enterprise edition supports automatic rebases of pull requests for both on-premise installs, and also their cloud hosted instances on https://githost.io

The lack of core support for this feature was the primary reason I just migrated a customer to gitlab instead of to Bitbucket, though the 1G soft repo limit in Bitbucket cloud was also an issue.