Control Freak: Commit rejected. Foxtrot merges not allowed in Bitbucket

The easiest way to avoid this problem is to always run "git pull --rebase" and to never run default "git pull". Here's a deep dive blog post on that: Too much fun with "git pull --rebase"

The reason you're encountering this problem is because your company has installed the free Control Freak plugin for Bitbucket and they have left its default Foxtrot Prevention control enabled for all branches.

If you're on Bitbucket Server 5.5 or newer you can rebase pull-requests directly from the pull request screen. Click on the "..." button on the far right of the pull-request screen and a "Rebase" menu item should be available.

Alternatively you can ask an admin to disable the foxtrot prevention. Even repo admins can do this (does not require global admins). But I don't recommend disabling this control since it prevents messy commit history.

Full disclosure: I wrote and maintain the free "Control Freak" plugin for Bitbucket Server.

Note: rebases and amends should never cause foxtrots. Typically only default "git pull" causes foxtrot merges, and "git pull -r" is a great remedy. The "git merge" command can also cause it, but it's rare for people to accidentally create a foxtrot merge when using "git merge" in typical scenarios that call for "git merge". I suspect 99% of the time it's "git pull" that is causing the problem.

That is related to Foxtrot merges, specifcally prohibited on BitBucket:

A foxtrot merge is a specific sequence of git commits. A particularly nefarious sequence. Out in the open, in lush open grasslands, the sequence looks like this:

But foxtrots are rarely seen in the open. They hide up in the canopy, in-between the branches. I call them foxtrots because, when caught mid-pounce, they look like the foot sequence for the eponymous ballroom dance:

Foxtrot merges are bad because they change origin/master’s first-parent history.

The parents of a merge commit are ordered. The first parent is HEAD. The second parent is the commit you reference with the git merge command.

You can think of it like this:

git checkout 1st-parent
git merge 2nd-parent

If pushed:

As explained in "GIT: How can I prevent foxtrot merges in my 'master' branch?", commit 'D' is a foxtrot merge because 'origin/master' is its 2nd parent.
This is the result of a pull (fetch + merge)
Once that fox-trot merge D is pushed... the first-parent history of 'origin/master' no longer contains commit 'B'!

As explained by torek in "how to avoid foxtrot merge in git", this is the result of working directly on master (new commit C), and doing a git pull (instead of a pull --rebase, as I always advice)

That will merge B and C into D (the foxtrot merge), which, once pushed, means the origin/master no longer has B as direct ancestor, but C.
Your work 'C' now becomes the main published branch history (origin/master), instead of B, relegated to something that was merged.