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
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.