In our first release of the new year, we’ve included a lot of great pull request features.  Let’s take a lap around them to see how they can help improve your workflow.

My Pull Requests

One of the big features in the latest release is the new, personalized account page, which includes a new “My Pull Requests” view.  The experience is just like the existing project scoped PR view, but provides a single place to see all of your PRs, in all projects and repos in the account.  For developers working in multiple projects and/or repos, this view makes it significantly easier to keep track of all of your PRs.

The next feature coming to the My PRs view is the addition of the PRs assigned to the teams that you’re a member of – a feature we plan to make available in the next release.

Highlight updated PRs

In the My PRs view (and in the existing PR hub), you’ll notice another new feature – highlights about what’s new in your PRs.  At a glance, you can see which PRs have updates, as well as what’s changed – whether it’s a new comment, votes from reviewers, or newly pushed changes.

Once you open a PR with updates, the Overview will highlight the changes that have occurred since you last viewed the PR.  In the example below, you can see the new vote from Mateo, and the update to the comment on Program.cs.

View diffs of the latest code changes

When a PR has new code changes since you last viewed it, the overview will provide a link to see the diff between the latest changes and the code as you last saw it.

Clicking on the link will take you to the Files view where you can see how the code has changed while you’ve been away.  In the screenshot below, notice the “Comparing 6 to 8”, which indicates that this is a diff between pull request updates.  The list of changed files and the code diffs are scoped to just those files with changes since you’ve last viewed the PR.  This feature is really useful to see how the author has responded comments you’ve left on a PR.

Email notifications

Staying up to date on all of your PRs can be tough – email notifications can make that easier, especially when they’re automatically configured for you.  In the latest release, we have a preview of a new “out-of-the-box notifications” feature, which includes notifications for your PR changes.  This feature is great for ensuring that all of the reviewers on your PRs know that you’ve asked them to review your changes – and it will help you know when your input is needed by others.

Currently, these default notifications only work for individual reviewers – teams and groups added to reviews won’t receive emails yet.  We know this is a painpoint, and we’re working hard to improve that in an upcoming release.  In the meantime, you might try configuring team notifications manually so PRs don’t fall through the cracks.

Attachments

One of the most frequently asked for PR features has been to allow images on the clipboard to be pasted into comments – screenshots of UI changes are number one scenario.  With the addition of attachments, we’re now able to support images pasted from the clipboard.

You can also attach other file types that are rendered as links in the comments.  Here’s an example of a Word doc being dragged into a comment.

The next feature for attachments will be to allow files to be attached to the PR description when you’re creating the PR.  As a workaround, you can edit the description after the PR is created to add your screenshots and other attachments like test plans, specs, etc.

Merge conflict details

For PRs with conflicts, we’ve made it easier to identify which files have conflicts.  When you have a PR with conflicts, the list of conflicting files and the type of conflicts will be shown in the PR overview.

Merge strategy policy

Some teams care a lot about how their PRs should be merged into the target branch.  Some want to see the merge commits so they see the history of the intermediate commits, while others want a clean history graph and choose to squash.  Until now, the choice to merge or squash was a user option, and could be changed on each PR.  With the new merge strategy policy, teams can configure how PRs should be merged for each branch.

Exclude paths from required reviewer policies

Teams using the required reviewers policy sometimes find that not all items in a given folder need review signoff from a specific team.  To accommodate this, we’ve enabled path exclusions when configuring policies.  Simply add a “!” prefix on the paths you want to exclude from the policy.  The example below shows how you might configure all files to require signoff from someone in the Contributors group, except for changes to the docs folder.

The next few releases will contain more great PR features, so stay tuned.  And if there is something we’re missing, don’t hesitate to submit ideas on the Team Services UserVoice site.

Happy coding!