How we use GitHub as a killer bug tracker and code review tool

I like a place to organize my bugs and features. I don’t like to double track in my own to-do list and in a bug tracker. I’m also a huge fan of code review. It was important to me that code review integrated well with my bug tracker.

Enter GitHub and Hub

I’ve started a few team projects, and haphazardly ended up using GitHub for bug tracker and code review. Once I found that Hub converted issues into pull requests, I fell in love. My team has a very simple workflow for code review. (This could work well for individual projects as well by simply skipping the code review step.)

Planning and bug tracking

  • Create milestones in GitHub Issues
  • Create issues for features or bugs for each milestone


  • Create a branch for each issue you start work on

    git branch –track issue8 origin/issue8

  • Push to the branch on GitHub (You can commit/push as much as you want to this GitHub branch)

Code submission and review

  • Convert issue into pull request with Hub

    hub pull-request -i 8

  • The code can be reviewed on GitHub by a co-developer

  • Changes are pushed to the branch and GitHub tracks commits in the pull-request thread
  • Once the code is ready — Merge

Rinse and Repeat

  • Rinse: delete branch
  • Repeat: create another branch for another issue  

Tracking branches

The only step that felt like extra work here was adding branches for each issue. However, once it became habit I can’t imagine it any other way.

We have a master branch that is merged into, and a release branch that gets updated with each milestone. It seems natural that each issue/feature has it’s own branch to update and merge.