Wednesday, May 08, 2013

Making code review on BitBucket suck less

I'm a big fan of code review, I feel that almost everything should be given a once over. I'm used to it in various work places, I'm especially used to it when working in an open source project.

BitBucket is a follower, not a leader, and has managed to get a lot of what makes Github work well added - inline comments are great.

BitBucket has lead in one area though - much like a 'merge pull request', on each change there's an Approve button.


If you are happy with a commit, it's a click away - you don't even have to say 'LGTM', if not, have a discussion.


This adds a handy tick in the commits list, letting you see what is accepted or what needs to be talked about.

There are two problems with this though:

  • Every time you hit the button, notifications are sent
  • The review is per commit, not per feature or branch. If you use a simple 'all in' model, it's hard to group a stream of work - later fixes are applied that invalidate your review, all in the same push.

The best answer I have for issue 1 is to create email rules. If it has to works "commit approved" from bitbucket.org, mark as read and archive it.
This dramatically changes the signal to noise ratio, but lets you still leverage the visual indications of review having taken place.

For the second, feature branches and pull requests are the next best bet - BitBucket allows you to do a pull request from a feature branch on your repository to master.

This lets review take place on sets of code and features; and works extremely well for integrating stable changes only.


Post a Comment