Git fast forwards and branch management

In certain situations, Git does a fast forward when you merge a branch that is ahead of your checked-out branch. Consider the following branch and then merge situation:

The green branch and the blue main branch both have the 45tP2 commit in their history. The branch had a single commit (and could have had several) before the merge. The branch is ahead of the main branch at the point of the merge. The main branch had no commits; It never diverged from the branch. 

At the time of the merge, Git recognizes this situation, so it fast forwards the main branch's pointer to match the merged commits. The merge message tells you about the fast forward:

After the merge, users can delete the branch as it no longer needed – the main branch points to the same place. This is perfectly acceptable if the branch was never pushed to the remote Bitbucket Cloud repository.

A non-fast-forward merge is a merge where the main branch had intervening changes between the branch point and the merge back to the main branch. In this case, a user can simulate a fast-forward by rebasing rather than merging. Rebasing works by abandoning some commits and creating new ones.

Rebasing can cause problem when working in public repositories. It can cause extra merge work for your collaborators; You may want to prevent these problems before they start. You can do this with the Branch permissions dialog.  

Limit push powers 

You can set rules that limit who can push to a branch. For example, you can allow only a certain group of users to push to the main branch. You can use wildcards to define branch names.  Wildcards let you set up rules that apply across sets of branches.  

For example, suppose you use contractors for bug fixes and developers for work on feature branches. You use the issue name to name your bug fix branches. You preface feature branches with a feat- prefix.  See Branch permissions for information on how to do this.