Preventing pushes to our develop branches, but allowing pull request merges.

We are quite new to GIT and Stash, and getting on really well. Stash in a branching/merging flow works very well for us. We use Pull requests to manage reviewing.


One thing that sometimes trips us up, is if a developer forgets to branch, they can comit and push their code directly on dev, bypassing the pull request review phase.


How can we prevent this? Seems like a massive hole, and one that must surely be simply solved? However looking around I am not coming up with much in the way of answers..

Thanks.

2 answers

One thing you can do is to set the branch permissions in such a way that not everyone can push to your dev branches. (Side effect: only some selected people can merge pull requests.)

Alternatively, you can write a pre-receive hook that rejects all commits to the dev branches which are not merges of pull requests (easy to identify by the commit message).

Is there any examples of such a post-recieve hook? I have no idea what they are, how they work, or even where to go with that suggestion?

Is this something that can be added from the Stash Marketplace? Is it something that resides server-side, or is it something the developers need to setup (which again presents a obvious hole, if they forget to branch, they can forget to add the hook).

(Server-side) hooks are little Java modules that run on the server at certain events. If you want to write the hook, start here. There is a very good SDK and fairly many examples available.

Once you write the pre-receive hook, deploy it to your server (can be enabled/disabled per repo) and then it accepts/rejects the pushes based on the code in it.

Wondering if WorkZone and it's AutoMerge is the answer? Can we remove write permission to our dev branch and allow WorkZone to do all the merging?

This would also be a possible solution if you are OK with auto merges. (I wonder what happens if there is a merge conflict, but that is a sidetrack.)

Personally, I prefer having a human actually make a conscious decision about when the merge button should be pressed. (e.g. It might be that one of the reviewers still has something critical to say when the pre-set percentage of the others has already approved and the server auto-merges the code.)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 06, 2018 in Bitbucket

Upgrade Best Practices

Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...

191 views 3 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you