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

[Mark Gillespie]

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.

[Balázs Szakmáry]

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).

[Mark Gillespie]

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).

[Balázs Szakmáry]

(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.

[Mark Gillespie]

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?

[Balázs Szakmáry]

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.)