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.

A quick guide to code review

In my opinion, it's good practice to have a strong culture of peer review - it ensures your team knows what is going on, catches simple issues, and makes you a better group of developers.

Bitbucket and Github both provide a quite intuitive interface for reviewing code. You can simply look at a list of recent commits, and find a particular line to add a comment.

If you are new to git, I'd recommend you find an existing project and try this out.

1. Find the commits tab - https://github.com/jaz303/tipsy/commits/master for example
2. You can see a number of commits, with references like 3545aa6ae2 - these are hashes that uniquely identify the change.
   It shows the commit message, author, as well as date/time.
3. Viewing one brings up the review user interface.

Code review is a fairly simple process. Different teams do different things, but I generally do: Does the code change meet the description? Is the code self describing / self explanatory? Are there tests? If you have questions, or don't understand something - ask. It may not be that you don't understand, it may be an oversight by the original developer. Give it a go on an open source project today!