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
masterbranch to which everyone commits - Devs work off the local
mastermirror or a local feature branch - Devs push to server’s
masterbranch - 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).
3
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).
4
Git is a distributed version control system: don’t have only one repo with one branch!
You can set up multiple repositories – one for each developer – and another which is the master repo. When one of their branches is ready to be merged, the developer requests a merge and their changes are pulled from their branch/repo into the master.
Before that merge actually happens, the reviewer can pull the changes into their environment, and review them before pushing them to master.
Added advantages are that this way a developer can have as many branches as they want, named whatever say they want, without interfering with each other or even having to see each other’s dirty laundry that much.
Also, learn the lingo: by “Devs commit to server’s master branch” do you mean that they push their changes to master?
4