Git – Code Review Process Using GIT

code-reviewsgit

What is the best process for code review when using GIT? We have an external GIT provider (Unfuddle) and have caps on resource usage – so we can't have dedicated remote repositories for every dev.

Current process:

  • We have a GIT server with a master branch to which everyone commits
  • Devs work off the local master mirror or a local feature branch
  • Devs push to server's master branch
  • Devs request code review on last commit

Problem:

  • Any bug in code review are already in master by the time it's caught.
  • Worse, usually someone has burnt a few hours trying to figure out what happened…

So, we would like

  • To do code review BEFORE delivery into the 'master'.
  • Have a process that works with a global team (no over the shoulder reviews!)
  • something that doesn't require an individual dev to be at his desk/machine to be powered up so someone else can remote in (remove human dependency, devs go home at different timezones)

We use TortoiseGIT for a visual representation of a list of files changed, diff'ing files etc. Some of us drop into a GIT shell when the GUI isn't enough, but ideally we'd like the workflow to be simple and GUI based (I want the tool to lift any burden, not my devs).

Best Answer

A simple but effective model is the GitHub pull request model, where contributors file "please merge in my code" requests. A maintainer reviews the changesets and decides if they need more work or if they are suitable for merging. He then may merge into the master branch. Committers are generally not allowed to push directly to the master branch (this can be customized to your tastes, we allow "minor" commits to go directly in).

Related Topic