Take the 2-minute tour ×

I wish to enforce the use of reviews for any code that gets pushed to our common remote git repository. I have selected ReviewBoard as the tool to help us achieve that, however I am struggling in making the review a requirement before any piece of code is pushed to the repository.

Unfortunately, git pre-push hooks are not an option, and won't ever become one from what I saw. The only option I see is to use pre-receive hooks, however tying these with a review is kind of tricky.

In order to make this work, each developer will have to follow a process like the following one:

  • code, commit, code, commit...
  • post-review (generate a new review)
  • fix problems, commit, post-review (to update the review ticket with the new diff)
  • once the review is accepted (status: Ship it!), commit again with a keyword like '#review ' (that'll have to be a commit --amend I guess if no changes were required)
  • git push

The pre-receive hook will have to check for the keyword, check that the corresponding review was indeed accepted, otherwise exit with an error.

I feel that this will be much better handled by creating a wrapper around the push action and have a customized script that will handle all this properly (it could create automatically a review ticket before even pushing, store the ticket id with git config branch..review_ticket and push when everything is over). This basically is the same as above but semi-automated, which also means that it will kind of restrict the devs on how they use branches (not necessarily a problem though).

Finally, I can let the devs do whatever they want but have a cron job run on the remote repository and check if any changes were pushed without review (kind of tricky) and send a warning email.

All of these solutions feel kind of "dirty" though. Did someone manage to set up such an environment, or can provide any tips here? Please note that all this has to work on a shared hosting and I would really wish to make it work with the current set of software I have.

share|improve this question
Another option I just thought about is to force (via the pre-receive hook) devs to push only new branches, which will have to be tied to a review ticket (the branches could have a specific name, or maybe use git config again). As soon as the review ticket is accepted, a cron job could maybe merge this to master? –  acp Jun 29 '12 at 18:07
add comment

1 Answer

up vote 0 down vote accepted

You could write a post-receive hook that would search your ReviewBoard installation to make sure that the HEAD of what's being pushed in exists in a completed review. That would change your workflow to just:

  • code, commit, code, commit, code, commit...
  • post-review
  • fix problems, commit, post-review with reworked code
  • git push

thereby getting rid of the ugly commit-amend thing.

share|improve this answer
add comment

Your Answer


