Feature branch code reviews

Here’s the flow. Read Josh Susser’s post for the git commands.

1. Start a user story.
2. Code the feature.
3. Push the feature to a branch.
4. A GitHub hook starts a CI build.
5. A GitHub Campfire hook posts your work to Campfire.
6. Click the link that’s in Campfire.
7. Click the GitHub “Pull Request” button.
8. It selects all commits in your branch that are not in master.
9. Create the pull request.
10. Ask your team in Campfire for a review of the pull request.
11. The team comments in-line, right on the code.
12. Make the suggested changes.
13. Merge into master.
14. Push to master.
15. CI runs again.
16. Deploy to staging.

Many teams use this “feature branch” pattern. The “code review” part is the GitHub pull request to team comments.

Here’s what a pull request looks like:

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:

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.