The remote control. Napster. The Smartphone. The plastic bits at the ends of shoelaces. All incredible technologies that made what came before both instantly antiquated and forgettable. A technology shift, even a subtle one, can entirely transform an industry. It happened in software development 10 years ago with agile – a once in a decade change to how teams build and ship software – and it’s happening again, now, with distributed version control systems (DVCS) like Git.

Git introduces completely new ways for development teams to share and work with code, in much the same way peer-to-peer technologies changed the way we “shared” music and media. The benefits are clear: developers can get further, faster on their local copies, and merge changes with the rest of the team when the code is more stable. Speed, quality, happiness. Enterprises are moving in droves to Git and DVCS. We made the move last year, and heard from many of our customers that they wanted a better management system for Git on their own servers. So we built one – Atlassian Stash – which we shipped in May of this year.

And today we’re pleased to announce Stash 1.3, which extends our great support for Git with two new important capabilities for enterprise teams – pull requests and inline commenting.

The new, social Stash – now with pull requests

If you’re new to pull requests, here’s a quick primer: pull requests are a simple way to contribute code, review the changes, discuss them and have the option of merging them into the existing code base. If a pull request could talk it would say something like “Here are my changes, here is what I’m changing and here is why I want to change it. Can I merge, please?”

In Stash, pull requests provide an easy way for developers to review changes on a branch, discuss those changes with one another, make modifications and merge the branch back into master or the main development branch. For those familiar with centralized version control systems (like Subversion), think “pre-commit reviews.” But pull requests have a key evolutionary advantage: instead of working alone on your local repository, your changes will be shared on an isolated branch in Stash where others can review the code and contribute changes. That’s a big deal for speed, quality and happy developers.

Why open a pull request?

Stash pull requests let developers merge code changes via the click of a button, but that’s not what’s most important. It’s the discussion around pull requests that brings the most value to teams. A pull request is opened when code is:

  • Ready to merge – the branch a developer has been working on is ready to be merged into the main code base or;
  • Open for continuous review – a developer opens up a feedback loop to discuss potential code changes with the team

Pull requests – start with a branch, end with a merge

Stash encourages the use of branches, where code changes can be made in isolation and reviewed before being integrated with the mainline. Once a branch is ready for prime time – typically after a bug is fixed or a feature is implemented – Stash and pull requests facilitate the process of merging.

Quickly select the branch you’ve been working on, the branch you want to merge to, add a brief title and description, identify the Reviewers and you’re done.

When creating a pull request you can select multiple reviewers to review proposed changes, formalizing control of merging by delegating the approval to key stakeholders. Once the pull request is created, reviewers are notified via email and other members of your team can also participate.

Unlike traditional code reviews, reviewers have an actual obligation to act on the request quickly (nobody wants to be the bottleneck, right?). And an approved pull request signals that both the developer and the team have upheld the social contract – otherwise known as your ‘definition of done.’ Unless code reviews are complete the changes will not be integrated.

The review process

Stash aims to make the review process simple and fast, not the usual two words you think of when code review comes to mind. Once a pull request is created the activity dashboard allows you to see the entire lifecycle of a pull request and get instant updates on changes. There is also a full audit trail to reference later, such as during a ‘Five Why’s?’ session or a bug retrospective.

Overview

Stash pull request ‘Overview’ gives you a historical view of the entire pull request – status changes, comments and code updates. You can understand, chronologically, what happened and why, reducing overhead and saving you time when reviewing code.

After absorbing the changes you can start a discussion or reply to existing comments directly if you have any feedback or suggestions.

Diffs

With so many changes happening when using Git, understanding what the final merge will be is key. Stash’s unique diff capability shows the exact set of changes that will be applied when integrating the proposed changes. When reviewing changes you know, with certainty, what files are changing and what changes will be applied when you click on the merge button.

The ‘Diff’ tab is where code reviews take place. Start discussions about code changes, understand the context of the changes and ask the author for clarification or suggest changes to be made.

Side note: Another advantage of Stash’s diff capabilities is showing merge conflicts before they happen by identifying the exact changes that may cause the conflict. That way you can avoid messy merges (and look like a total bad-ass) by resolving them in advance.

Comment and discuss

Pull requests provide more than a gate-check for your code: they draw developers out of their silos and get them communicating with each other. Keep your team engaged and invested in the project as a whole, even if you’re geographically distributed.

  • Catch major defects before they are introduced into the existing code base
  • Discuss architectural improvements and provide guidance for changes
  • Establish and follow coding standards
  • Give some kudos for great work

Keep your comments in context when collaborating and have discussions inside your code. After adding a comment, Reviewers are notified via email and a threaded discussion can take place in Stash.

The point of any code discussion is to (hopefully) identify changes that need to be made. It is no different when commenting on pull requests. Comments will spur contributors to review their own work and make changes. If changes are made and a pull request is still open, Stash will recognize that changes have been made and alert Reviewers and Participants. Comments fuel discussions, discussions improve code quality!

Stash also maintains an audit of all discussions and updates that went on around a feature or bug fix.

Light-weight approval process

Stash provides an instant approval mechanism for fast feedback on pull requests. With one-click, reviewers can approve or decline proposed changes.

Once changes are approved and merged an email notification is sent out that the pull requests has been closed.

On the Stash development team, the last reviewer to approve a pull request performs the merge. Stay tuned until next week to learn how the Stash team uses pull request to develop Stash.

Get to know the more social stash

New to Stash? Git going, start a free trial today and get up and running in minutes.

Already using Stash? Your upgrade awaits you. Check out our full release notes to get started.

Want to learn more about Stash 1.3? Stay tuned, this release blog just scratches the surface on pull requests.