---
title: Feature branch code reviews
teaser:
tags: git,playbook
author: Dan Croak
published_on: 2011-01-19
---

"Code review." My knee-jerk reaction to that phrase? Nap time.

I'll be honest, I never really felt engaged during "code review" meetings at the
end of an iteration. It always took too long to get and discuss the code.  The
room would get warmer. We'd discover things we'd want to change. Many of those
changes would never be made.

Since today is [Boycott a Meeting Day](http://boycottameetingday.com), I thought
I'd offer an alternative we've used lately.

Here's the flow. Read [Josh Susser's
post](http://blog.hasmanythrough.com/2008/12/18/agile-git-and-the-story-branch-pattern)
for the git commands.

1. Start a user story.
1. Code the feature.
1. Push the feature to a branch.
1. A Github hook starts a CI build.
1. A [Github Campfire
   hook](https://github.com/blog/570-campfire-service-hook-returns) posts your
   work to Campfire.
1. Click the link that's in Campfire.
1. **Click the Github "Pull Request" button.**
1. **It will smartly select all commits in your branch that are not in
   master.**
1. **Create the pull request.**
1. **Ask your team in Campfire for a review of the pull request.**
1. **The team comments in-line, right on the code.**
1. Make the suggested changes.
1. Merge into master.
1. Push to master.
1. CI runs again.
1. Deploy to staging.

Many teams use this "feature branch" pattern. The "code review" part is the
Github pull request flow stuck right before the code goes into master.

Here's what a pull request looks like:

![Pull Request](http://images.thoughtbot.com/ui/pull-request.png)

Notice the `jm-cm-client-sets-up-recurring-payment` branch is compared to
master.

And here's what a comment on a commit looks like:

![Commit comment](http://images.thoughtbot.com/ui/commit-comment.png)

You could use normal git tools to check out a team member's feature branch, view
the history, etc., but Github one-ups bare git by adding a streamlined user
interface and commenting.

## Why we like it

Test-Driven Development moves code failure earlier in the development process.
It's better to have a failing test on your development machine than in
production. It also allows you to have tighter feedback cycles.

Code reviews that happen right before code goes into master offer similar
benefits:

- The whole team learns about new code as it is written.
- Mistakes are caught earlier.
- Coding standards are more likely to be established, discussed, and followed.
- Feedback from this style of code review is far more likely to be applied.
- No one forgets context ("Why did we write this?") since it's fresh in the
  author's mind.

I've personally loved this process. Give it a shot!