Bitbucket Server 5.5 adds a "Rebase" action to the dropdown on pull requests:

If the rebase is completed successfully, the pull request is reloaded. We're still polishing that interaction, due to the asynchronous processing that updates a pull request's hashes in the database when they change on disk, but we feel it's better to get this functionality shipped so it can add value for those teams that use rebase workflows, rather than waiting for "perfect" polish. We feel like the current approach is still very usable, if not quite ideal.

Further details about additional rebase actions supported in 5.5 can be found on BSERV-2874.

Enjoy!
Bryan Turner
Atlassian Bitbucket

My paid add-on (Bit-Booster - Rebase Squash Amend) puts a rebase button on the pull-request screen:

Bit-Booster is smart about branch permissions, too.  The Rebase Button is automatically disabled if the from branch for the pull-request does not allow history rewrites.

The end result is pushed to Bitbucket locally via "git push --force-with-lease" and so all hooks, permissions, and config are respected.  It doesn't circumvent anything.  It's exactly as if the user had done the rebase locally and pushed it, but more convenient.

This is also related to https://bitbucket.org/site/master/issues/6202/sync-feature-branches-via-rebase-bb-7369 

And shouldn't this be closed as duplicate of https://jira.atlassian.com/browse/BSERV-2874

Yes, regardless of conflicts the merged result still needs review. But I don't know if that needs to be part of a rebase in pull request feature, as it happens anyway when there are more commits pushed to the source branch. We have chosen to use a plugin that un-approves when there are further changes.

We, too, require that our source branches be up to date with the target before merging. That said, the question arises if this pure "rebase" action should invalidate reviews or, at least, retain the option to NOT revoke reviewer approvals for pure and clean rebase actions. If any conflict resolutions are detected, this would "change the game" for reviewers and reviewers should be allowed to decide if they want, generally speaking, to retain or revoke their reviews when pushing this proposed button.

We use a workflow that requires the source branch to not be behind the target branch (that is, only fast-forward merges are allowed) when merged as part of a pull request. This forces the source branch to be rebased on the target branch before the merge.

For our projects, the majority of the merges will be conflict free, so having a rebase feature in the Pull Request that could rebase the source branch onto the target branch IFF there are no conflicts would be very useful.

I see this exact feature is now supported by GitLab.

Merges should not be possible unless the pull request rebases cleanly on top of master. I could even imagine this to be automatic where pull requests would be always pinned on top of a rebased master and if that does not work anymore to mark them as stale and unmergable.

The merge strategies available in Bitbucket Server do not cover this case. This feature suggesting has actually nothing to do with the merge event at all. It is a feature to use while preparing a neat pull request.

Typical use case when simple rebase is a good idea. Our developers are of course doing this, locally, already. I am only looking for a way to make development more efficient.

Ex)
Say I have written a new feature that is using the project custom thread class in branch "feat1". I have created a pull request, "feat1" => "develop", and all builds/tests has passed.
During the time I worked with my threaded feature, a college has refactored the thread class (keeping interfaces compatible) and merged into our dev branch "develop".

At this time a merge between "feat1" and "develop" is trivial, but I do not know if my new threaded feature is using quirks from the old thread class implementation. Hence it is a good idea to rebase my branch to test the new thread class implementation together with my new threaded feature.

Thanks for the suggestion - could you elaborate a bit on the types of cases you'd use this? Would you see this being selected ad-hoc, or set system wide?

We currently support a squashed commit merge strategy as a system setting which would give you the rebase onto the target of the PR for all PR's on the system, but this is not exactly what you're after as it would affect every PR raised in the system.