Actual: Gatekeeper by default starts the build by merging the branch to master. This creates a merge commit in the history.

The Bamboo UI for the build page says something like:
Checked out: branch a1b2c3d4
Merged with: master f9e8d7c4

Desired: We'd rather rebase the branch onto master at the start of our Gatekeeper builds and force push the branch, to avoid the merge commit. There would be a checkbox in the Gatekeeper option box on the Branches tab, "Rebase branch instead of merging. (git only)"

The Bamboo UI would then say something like:

Checked out: branch a1b2c3d4
Rebased onto: master f9e8d7c4
Pushed: branch 8a6b4c2a

This requires a bit of justification. First, why do we want it? And second, how could this be safe?

For background, we only want to use Gatekeeper for short-term (often single-commit) bug branches. For long-lived branches, we'll prefer to use Branch Updater and merge back to master manually at the end of the branch, most likely after a pull request.

We want Gatekeeper to do rebases because doing a merge commit for a branch with just a single commit on it messes up the revision history, which has an impact when we use git-bisect. Here are a couple of blog posts talking about why it's a good idea to use rebase or merge --squash when you land small branches on master, instead of merging.

https://sandofsky.com/blog/git-workflow.html
http://blog.izs.me/post/37650663670/git-rebase

You may or may not be convinced by those articles, but I hope you can at least see why someone would want to do it that way, even if you don't approve of it for yourself!

For reasons like this, at our organization we always do "git pull --rebase" when we do our pulls.

You may have heard that rebasing public branches is inherently unsafe. This is basically good advice, but it's overblown. The publicity of the branch isn't what really matters; it's whether people have committed work on top of rebased commits.

Rebasing history is dangerous if other people have made commits on top of commits that you're rebasing, because it will force them to rebase their commits (by hand!) on top of your new rebased head. One way you can be sure that it's safe to rebase is if the branch is completely private and has never left your machine. In that case, it's impossible for anyone else to do a commit based on your private branch. But there are other ways to have reasonable assurances of privacy while still pushing your code to Bitbucket.

For example, if you push a branch whose name is private-dgf-BAM-13032, it would be very unusual for anyone to decide to arbitrarily start committing in your private branch. It's not impossible, but in practice, it won't happen.

Our goal is to use Gatekeeper only with "private" branches; this wouldn't be enforced in a security sense, but via naming standards and public norms. So in those cases, it's perfectly fine for Gatekeeper to rebase them; the only person who will be impacted when my private branch is rebased is me.

Furthermore, as long as I pull Gatekeeper's rebase into my repository with "git pull --rebase", (which, again, is what we always do at our organization) git will automatically recover from Gatekeeper's upstream rebase, and all will be well.

In conclusion: using Gatekeeper to rebase branches is safe and even desirable if you take reasonable precautions; we'd love it if Gatekeeper would support our workflow.