Editor Tools

Improved pull request experience in GitHub for Atom

There’s a new way to view and interact with new pull requests in Atom through the GitHub package!

@smashwilson and @simurai have been working on a number of improvements that we’re excited to share with you today, with more on the horizon.

New pull request list view

First, we’ve added a pull request list view. Now you can see the most recent pull requests in the GitHub tab Ctrl+8 with information such as:

  • Author’s avatar
  • Title of the pull request
  • Pull request number
  • CI status
  • “Last Updated” information

When you click on a pull request, you’ll see a view similar to the conversation view on GitHub.com, and can quickly check out the PR with the click of a button!

Click on a pull request for a view similar to the conversation view on GitHub.com, and check out the PR with the click of a button

The top of the view contains the most important information:

  • The pull request author (clicks to their GitHub.com profile)
  • The pull request title
  • The status of the pull request (for example, open)
  • The organization, repository, and pull request number (clicks to the pull request on GitHub.com)
  • A Checkout button that allows you to quickly checkout this pull request inside of Atom
  • A Refresh button to pull updated information about the pull request
  • Your CI and build status, with quick links to view the details
  • The description of the pull request
  • Reactions (currently unclickable)

After this information, you will find the same conversation view you would see on GitHub.com. Sometimes, it may be something as simple as the list of commits and other times it might be an entire conversation.

Hover card functionality

We’ve also added some user experience enhancements, such as enabling the hover card functionality in @mentions and references to other issues and pull requests:

Enabled  hover card functionality in @mentions, issues, and pull requests

Creating pull requests

In addition to seeing more information about your existing pull requests, you can also open a new pull request directly from Atom.

Starting from master, you will see a new message in the GitHub pane providing you with information on what you might want to do next, such as checking out an existing branch or creating a new branch. If you create a new branch, you will be prompted to start making changes to your branch. Finally, if you make changes, stage them, and commit to your branch, you will be invited to publish your branch and create a pull request with those changes:

Screenshot showing you're invted to publish your branch and create a pull request with changes

Clicking Publish + open a new pull request will launch your browser at the draft of your pull request on GitHub.com. There, you can add an extensive description, reviewers, labels, and more. Visit https://github.atom.io/ for more information on the GitHub panel in Atom.

Emoji support in commit messages

We also care about making the experience consistent with GitHub.com. You might notice that commit messages in Atom now support emoji! :sparkles: to @annthurium for making committing in Atom a bit more entertaining:

Commit messages in Atom now support emoji

Learning from our users

We’re excited about the new experiences we’re bringing to the Atom community and looking forward to continuing to improve our package. You might have seen in a recent blog post that we’re working on improving our understanding of who you are, how you write code, and how you collaborate with your team. This involves usability studies, as well as a large project that @annthurium and @jasonrudolph have been working on to improve our metric gathering. Read about the details of Telemetry on the Atom Blog.

We have integrated Telemetry into our GitHub package for Atom so that we can better understand what features are useful—and which are being left undiscovered. We invite you to revisit your opt-in decision on metrics if you’re interested in helping us improve our package by sending metrics through our secure GitHub data pipeline. Just open your Atom Preferences and choose Allow limited anonymous usage states, exception, and crash reporting.

Atom Preferences tab showing option to choose Allow limited anonymous usage states, exception, and crash reporting

Try GitHub for Atom

Bringing checks and statuses to GitHub for Visual Studio

With the release of GitHub for Visual Studio 2.5.5, pull requests now support checks and statuses.

Checks and statuses—like continuous integration builds or deployment services—determine if the conditions set for a repository are met. Once checks and statuses are set up, every commit will show a status of pending, passing, or failing for each check.

Bringing this functionality to Visual Studio provides necessary information to review and merge pull requests. It also takes us one step closer to building out a complete pull request workflow. Huge shoutout to @stanleygoldman for making this happen!

Checks and statuses in GfVS pull requests

Pull request list view

When you enable checks and statuses for a repository, the pull request list view shows the status of each pull request. The status displayed is that of the latest commit.

Pull request detail view

In the detail view, you’ll see a section for “Checks”. Expanding the “Checks” sections shows all the individual checks and their respective statuses.

Expand the checks section to see which checks have passed

Clicking Details next to each check will open the URL to the service where you can view more information and logs. When a check fails, for example, you can open up more details in your browser to see what went wrong.

Open up more details on failing checks right from your browser

Call to action

Reach out to @GitHubVS to let us know what you think about this new functionality—and follow the latest updates on our work.

We’d also love to hear from you if you run into bugs or limitations in GitHub for Visual Studio. Feel free to open an issue in our repository. Or if you want to contribute to our extension, review our README, peruse our Contributor Guidelines, and join the fun!

Finally, if you’re interested in participating in usability studies around our extension, we invite you to fill out a short survey.

New improvements in GitHub for Visual Studio

As we shared in a recent blog post, the Editor Tools team at GitHub has been working on improving the user experience of our GitHub extension for Visual Studio.

Here’s what’s new in the latest GitHub for Visual Studio release (Version 2.5.4):

Pull request improvements

We are now using the new Octokit.NET library that uses the GraphQL API, which has improved the performance for listing pull requests. Lists that used to take minutes to load are now loading in a matter of seconds within our extension. Additionally, by using GraphQL for our pull request models, we will be able to use GitHub GraphQL APIs as they become available, keeping our extension up to date.

We’ve also improved our general pull request experience by fixing the UI on pull request changes when scrolling horizontally, removing leftover [remote…] entries that were left in the .git/config file when previewing a pull request to upstream, and preventing pull requests from opening in the browser multiple times.

@stanleygoldman, @grokys, and @donokuda have led the efforts for these improvements, and we’re also very grateful to @Neme12 for contributing to our project by updating the pull request changes view to use the built in Visual Studio icons.

Something we’re particularly excited about exploring is how and why users navigate between GitHub.com and Visual Studio. We’ve started explore the functionality of what is possible with things like opening links that have been copied to the clipboard (Code context > GitHub > Open from clipboard) and copying links from Visual Studio to your clipboard (Code context > GitHub > Copy link to clipboard).

Thank you @jnm2 for opening up an issue that started this conversation and @jcansdale for recognizing this opportunity and taking lead to improve this user experience!

Get involved

As always, we are eager to hear from you in a number of ways. If you run into bugs or limitations in our functionality, open up an issue in our open source repository. Or if you want to contribute to our extension, review our README and Contributor Guidelines and join the fun!

If you’re interested in participating in some usability studies around our extension, we invite you to fill out a short survey.

Let us know on Twitter how you use the Open from clipboard feature! Follow us @GitHubVS for the latest on what we’re doing.

Bringing GraphQL to Octokit.NET

If you’ve built apps that connect with GitHub, you are no doubt familiar with Octokit. GitHub offers three official flavors of the easy-to-use Octokit library—one for Ruby, .NET, and Node.js—that work with the GitHub REST API v3. Back in September of 2016, we announced that we would move to GraphQL, the query language developed by Facebook, in part due to the ability to fetch all of the data we wanted in a single request. As a result, the GitHub API v4 is built on GraphQL instead of REST.

Introducing Octokit.NET in GraphQL

The Editor Tools Team is particularly excited about this move to GraphQL because loading lists of pull requests in Visual Studio through our extension can be time consuming for some projects. We’ve experimented with GraphQL APIs, but we wanted to make it as easy to use as the Octokit.NET library. As such, we are excited to announce the GraphQL flavor of the Octokit.NET library is now available.

Creating a GraphQL-based .NET API presents certain challenges. GraphQL is a query language best suited for dynamic languages. Developers that want to take advantage of GraphQL in statically compiled languages like .NET have to make some compromises, resulting in a much different experience.

This started as an experiment to see if we could use GraphQL’s self documenting functionality to generate a library that gets the benefit of static compilation while retaining the flexibility and spirit of GraphQL. In GitHub for Visual Studio, we perform many round trip queries when displaying pull requests. We’ve used this library in our extension, and it has helped us improve performance, most notably with pull request lists. Before, these lists took minutes to display and now load in under two seconds.

The syntax is designed to look as much like GraphQL as possible while still feeling familiar to .NET developers:

using Octokit.GraphQL;
using Octokit.GraphQL.Core;
using static Octokit.GraphQL.Variable;

var connection = new Connection("https://api.github.com/graphql", YOUR_OAUTH_TOKEN); 

var query = new Query()
    .Select(repo => new

var vars = new Dictionary<string, object>
    { "owner", "octokit" },
    { "name", "octokit.graphql.net" },

var result =  await Connection.Run(query, vars);

Console.WriteLine(result.Login + " & " + result.Name + " Rocks!");

If you want to use the GraphQL API in .NET and make queries in your statically compiled C# code, try out the new GitHub v4 Octokit.NET library.

We’re excited to hear from you. Are you a .NET developer? Is this something that you would find useful? Get in touch with us in our GitHub for Visual Studio repo or on Twitter (@GitHubVS).

Using quantitative and qualitative measurements to improve GitHub’s Editor Tools

The Editor Tools team at GitHub builds tools for other developers, and we often feel like we know what we should build next. Though we often have good instincts, we know that other developers have different workflows and different pain points. We don’t always know how you will discover, use, and understand what we have built.

As such, we’ve started the process of discovering how you use what we build, and where the gaps in our extensions are. Our primary goal is to bring parts of the GitHub experience to your development environment. We’re dedicated to discovering what we can about how you use your developer environment, and how we can improve the way you collaborate with your code and your team.

We’re tackling this in two major ways:

  1. Improving our metrics
  2. Conducting usability studies

Improving how we collect and analyze metrics

The purpose of improving our metrics is to better understand how you use our extensions and how Editor Tools improve your workflow. We recently wrote a blog post about how we gather metrics in Atom, which you can read more about here.

Through collecting metrics around how you work throughout the development cycle, we can identify better ways to support you: the developer. We continue to be dedicated to protecting our users’ privacy and security, and in this process we are only interested in gathering large amounts of information that will give us indicators for the success of the features we create.

Conducting usability studies

We’re conducting usability studies with developers in the community to better understand who you are, how you write code, and how you collaborate with your team. All of this will help us understand how to better support your goals and workflows. If you’d like to learn more about future usability studies, follow us on our various Twitter accounts: GitHub for Visual Studio, GitHub for Unity, and Atom.

Learning from you

We are currently running usability studies around Visual Studio. If you use Visual Studio to develop software in any capacity (side projects, school, career, open source projects, just learning, etc), we want to learn from you! Our usability studies are typically done remotely over video conferencing software. Learn more about this study and sign up to participate.

You can also check out what we are up to in our various open source repositories:

We always welcome new contributions. Look for issues with the “Good First Issues” label in our repositories’ issue trackers to get started.




GitHub Universe logo

GitHub Universe

October 16-17 in San Francisco
Get tickets today

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more