How to compare two revisions in Bitbucket – and more!

Atlassian’s Bitbucket is easily one of the most practical tools in a development team’s toolkit. Bitbucket is a web-based version control repository hosting service. It comes in handy to development teams that use Mercurial or Git revision control systems.

The brand new release of the tool – Bitbucket 4.8 – focuses on optimizing the work of development by providing them with features that take productivity to the next level – for example, faster turnaround time for pull requests or zero downtime backup (which backs up a Bitbucket instance without the need to lock it for maintenance and causing downtimes).

Here’s a short overview of the new features – among them comparing revisions to show you how Bitbucket helps development teams work together to create higher quality code.

It’s much easier for developers to collaborate in the code review process thanks to pull requests. Pull requests also help development teams stick to the best code review practices with specified reviewers in the workflow.

Still, what happens if you’re a reviewer who would like to review the individual commits added to a pull request quickly?

With Bitbucket’s new feature – the commit-level review – reviewers can take advantage of per-commit diff views and commenting within pull requests. That’s how they can easily review individual commits added to a pull request.

Here’s an example:

If the author of a pull request author has broken down the work into logical commits, the reviewer can now step through the changes made to each commit. Moreover, the effective diff for the entire pull request is still available to allow reviewers to access the big picture view.

Here’s another use case of this new Bitbucket feature:

What happens when the reviewer wants to return to a pull request they’ve already reviewed to see whether and how their feedback has been implemented? The commit-level review helps in this situation as well. The reviewer can see all their feedback implementation without mixing it up with the changes they’ve already seen. The commit-level review allows viewing and commenting on individual changes, one change at a time.

Reviewers have an easier time highlighting changes at the granular level, making the entire experience much better for all team members. It also results in faster pull request turnarounds.

For companies that rely on hosted software, backups are essential. One of the challenges businesses face in backups is ensuring the consistency of data copies made using supported mechanisms. That’s why backups usually incur some amount of downtime that occurs on a regular basis.

Here’s what that can be problematic for development teams:

If you have builds running at night and the downtime happens during that time, your builds will inevitably , and it will take a while for your team to address the problem. And if your team is dispersed all over the world, then your nighttime might be their day time – and that means downtime happens during their working hours.

Bitbucket Server and Bitbucket Data Center 4.8 now offer teams the opportunity to create a backup without locking or shutting down the instance. The idea here is reducing downtime due to backups.

So, if your file system and database snapshots are consistent within themselves, a restore where the data snapshots aren’t in sync will result in a working instance which is tolerant to minor inconsistencies in places where operations occurred during the backup period.

Moreover, Bitbucket Data Center offers an active recovery mode your team can run on startup to find, log, and resolve any inconsistencies between the filesystem and database. Zero downtime backup combined with active-active clustering in Bitbucket Data Center is yet another way companies can deliver constant access for users.

To learn more about the zero downtime backup, check out the updated documentation.

Pull requests are at the core of Bitbucket workflows. No wonder that the new version of the tool includes a brand-new commit-level review option. But what about assigning reviewers to pull requests? Some development teams struggle to streamline this process.

Just ask yourself these questions:

Does your team have a release gatekeeper responsible for reviewing or merging every pull request?

Is your team small and everyone needs to review each pull request?

If what you’re aiming for is avoiding the creation of a reviewer list from scratch for every pull request, here’s a solution. Bitbucket’s new default reviewer feature allows configuring a default set of reviewers who will be pre-populated on the pull request creation form in any given repository. These default reviewers can be defined by source and target branch. Once you set it all up, you can add or remove people from this list easily.

Here’s something extra:

The new version of Bitbucket also offers a new merge check for specifying that a specific number of default reviewers must add their approval before a merge can occur. Setting up such checks is a smart move – that way, you’ll be making sure that the release manager gets a heads up on pull requests which target release branches. You can also notify them that a senior developer has approved all changes to the default branch or that the bug-master has reviewed all the bug fixes. Such a granularity of configuration helps teams to adjust the entire pull request experience to their unique process, becoming more innovative.

The new features released in the brand-new version of Bitbucket take a team’s Git best practices to the next level and make collaboration much more straightforward. Zero downtime backup helps to avoid putting work on hold and makes teams independent from clients or team members located in different time zones.

The features I presented above make code reviews easier for quick turnaround times and help teams create better quality code.

Are you looking for a team of experts who know how your team can make the most of Bitbucket? Get in touch with us; we help companies take full advantage of Atlassian tools for software development teams.