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 master 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 master at the point of the merge. The master had no commits; It never diverged from the branch.
At the time of the merge, Git recognizes this situation, so it fast forwards the master branch's pointer to match the merged commits. The merge message tells you about the fast forward:
git merge greenbranch Updating 45tP..56tk9 Fast forward some.src | 1 − 1 files changed, 0 insertions(+), 1 deletions(−)
After the merge, users can delete the branch as it no longer needed – the master 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 master branch had intervening changes between the branch point and the merge back to the master. 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 master 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.