Pull requests provide a lightweight way to do peer code reviews and merges as part of a branch-based development workflow. Sure beats having to huddle around a monitor with 3 other developers! Today I’d like to share with you some improvements we’ve made to pull requests in Bitbucket Server that will help you get to master faster.
Pull request reviewer status
Professional teams benefit from having an explicit set of reviewers on pull requests, making it clear who is expected to pitch in and review. And we built that into Bitbucket long ago. As powerful as that has been, we’ve heard feedback that it wasn’t obvious who had reviewed the latest changes – even to the reviewers themselves. Some reviewers were also appearing a little too judgmental and reaching for the decline button when they really just wanted to say that the code needed a little improvement.
Pull requests need a way to help reviewers and authors keep track of what was going on around all the feedback flying around. So we added reviewer status to make reviewers’ intention clear to everyone. As a result, both the author and reviewers can see which pull requests need their attention. We shipped this last month with Bitbucket Server 4.4 and have seen strong uptake amongst our customers.
Another useful improvement we made to pull requests is the ability for users to quickly add or remove themselves as a reviewer. If you’re on a team that adds lots of reviewers, it’s now easy for a reviewer to opt out whilst make it clear who’s still on the hook. Conversely, if your teammates prefer to “self-select” by opting in as a reviewer, that’s easy too.
Even better branch permissions
Awesome pull requests are awesome and everything… but only if people use them. We’ve long had branch permissions that let teams choose who can write to a branch without a pull request. That’s pretty much an expected feature these days. Recently, we made it possible to protect certain branches by requiring pull requests for changes.
Organizations that wanted stricter pull request based workflows found this quite useful, though as some pointed out, there are times when bypassing this restriction is necessary. For example, when applying merges of already approved changes between release branches.
With Bitbucket Server 4.5, it’s now possible to nominate exceptions to any of the available restrictions – be it force pushes, branch deletions, or requiring pull requests. This means you can ensure developers’ changes always go through pull requests, while the release manager can propagate previously reviewed changes with regular merges.
Overdue for a Bitbucket upgrade?
If you’ve been holding off upgrading to the latest release or want to try Bitbucket Server for the first time, there’s never been a better time. Get these goodies into developers’ hands and they’ll thank you for helping them fly!