meaghanlewis
In the latest GitHub for Atom release, we’re introducing two new features that will improve your commit experience.
Previously, DOM elements were rendered for every line of each diff, which meant a lot of work for React and the DOM to process. This led to rendered diffs being limited to less than 32k bytes, resulting in the inability to load large or multiple diffs.
Now diffs are rendered using Atom’s TextBuffer. The text buffer’s most important benefits are improved performance when loading large diffs and the ability to render multiple diffs. A few other perks include keyboard bindings to use Atom shortcuts with the ability to navigate around diffs, as well as copy and pasting code from a diff.
Rendering diffs with TextBuffer makes it easier to review and edit code from within a diff view whether you’re making changes now or in the future. TextBuffer provides options, such as:
Now you can use the option to “See All Staged Changes” before you commit, opening diffs of all staged changes in one pane. Seeing all changes at once makes it easier to double-check your work and write a meaningful commit message about your changes. Commit preview uses the new and improved diff rendering to render multi-file diffs.
While building out this feature, user research sessions gave us informed data to make (and finalize) changes to the design, color, and text of the button. This feedback helped us feel confident that the updates created a more intuitive workflow and led to a more polished diff view with a cleaner look.
User experience is important. Our goal is to make it easy to write, review, and collaborate on code within Atom. We have plenty of updates in store, but look out for upcoming improvements to pull request reviews.
If you have feedback about what we’ve worked on—or ideas for what you’d like to see in the pull request workflow—reach out to us in the Atom repository. We’re always looking for participants for our ongoing usability studies.
meaghanlewis
The GitHub Pull Requests extension in VS Code allows you to manage your pull requests directly from your IDE. Over the past months the team has added even more enhancements to pull request functionality. Using the latest version, you can now create pull requests, leave suggested edits as a comment, and view status checks for each pull request.
To create pull requests in VS Code, hover over the GitHub Pull Requests title and click the + sign. Choose the target branch for the pull request, press enter, and relax—you’ve opened your pull request.
Provide suggested code edits and leave them as comments with a diff that shows the current code alongside your suggested changes. The suggestions can easily be applied by selecting Apply Patch to commit the new patch of code.
You also have the option to stage all suggested changes when changes have not yet been staged.
Once you create a pull request, status checks will appear in the description. You can now view the progress of each check that was integrated: passing, failing, and in-progress.
Visit the VS Code Pull Requests Repository to view release notes and download the latest release package. Don’t forget, you can always install or update the latest version directly from inside of VS Code.
meaghanlewis
It’s been over six months since we introduced GitHub for Unity 1.0, and we’ve been busy. Since launch, we’ve continued to improve the extension and fix bugs, focusing on maintenance and providing an overall smoother experience.
The GitHub for Unity team received multiple requests to support GitHub Enterprise. Most recently, a team wanted to use the Unity plugin for their gaming engine but needed Enterprise support. GitHub Engineer @stanleygoldman addressed the request and shortly after, we were able to release a beta for customers to use and share feedback on.
In this release, GitHub for Unity version 1.2.0 officially supports GitHub Enterprise. Now, even more developers will be able to use the GitHub for Unity extension.
We’re a small team. We’re still trying to figure out what our impact should be and what work we should focus on. In 2019, we’re excited to see what’s in store for GitHub for Unity—and we’d love to hear your thoughts.
If you have questions, feedback, or want to get involved in building the GitHub for Unity extension, reach out to us in the project repository or on Twitter. Or see what we’ve been up to—try GitHub for Unity.
meaghanlewis
In the latest release of GitHub for Visual Studio, the Editor Tools team has improved the pull request experience with check runs and annotations. Seeing annotations inline for a check run when reviewing a pull request provides the reviewer with more information in order to perform a more thorough review of their code.
The GitHub for Visual Studio team worked on a release to provide you with more information when reviewing pull requests. This past August, @stanleygoldman implemented checks and statuses so that pull requests show a status of pending, passing, or failing for each check. Taking it a step further, checks can be configured to run against changed files in a pull request to provide annotations and show details about the code including errors, warnings, and general information.
When a check run application is configured for a repository, annotations appear on each pull request if a certain condition is met. Looking at the list of changed files, it’s easy to see which files have annotations. Here’s an example where the indicator is beside the file name (represented by a symbol), and the number of annotations is linked.
When you click on the link, the file opens for you to view more details about the annotations. In the margin of the diff, lines with check run annotations are identified with a different color: red for errors, yellow for warnings, and blue for information.
When inline comments are on the same line as an annotation, two separate indicators appear: a diamond symbol for the annotations and a circle for comments. When clicking on the marker, both the annotation and comment are displayed.
GitHub applications can be integrated with checks to list annotations about lines of code that have been changed in pull requests. Here are a few awesome GitHub applications that can show annotations through check runs:
Build Cross Check creates checks and surfaces warnings, errors, and additional information.
Yamburger finds syntax errors in YAML files changed in pull requests.
Kubevalidator validates Kubernetes YAML files changed in GitHub Pull requests against a community-maintained set of schemas using kubeval.
Prosebot listens for changes to Markdown files and runs various checks against them to provide feedback on English spelling, prose, and inclusive verbiage.
Linter-Alex ensures your writing is sensitive and considerate before you merge your pull requests.
You can use existing GitHub applications to provide code annotations, or you can build your own. This option provides the flexibility to choose the exact annotations you want to show in your project.
Try the new check run annotations feature, and let us know what you think!
If you’re curious see what else we worked on, check out the latest release notes. As always, you can reach out to us in our repository or on Twitter.
meaghanlewis
Have you ever been in the middle of writing a code comment and find yourself needing to switch context for a single minute? When you returned to the diff, did you find that your comment disappeared while you were in the middle of writing it?
In the latest release of GitHub for Visual Studio, we added the ability to save drafts of comments. As they are written, comment drafts are saved to a SQLite database and displayed when a user comes back to them later. Now, in-progress comments will never be lost again.
A big thanks to @grokys for working on the save drafts feature!
When reviewing a pull request, it’s common to write inline comments in the file diffs. Sometimes it’s necessary to switch back and forth between files (and other views) within Visual Studio. Now the diff can be closed and reopened and the in-progress comment is restored right where you left it.
After reviewing a pull request, it’s time to submit your review. From this view, you can navigate away and come back to the summary later so you can easily complete your review.
For creating a pull request, you can close the Create Pull Request form and return to it later—the title and description are filled out just as you left them. Even better, Visual Studio can be restarted and the content will be restored.
This is the latest feature we have added as we continue to build out our pull request workflow. Download the latest version of GitHub for Visual Studio and try it out.
We’d love to hear what you think! Feedback is always welcome in our repository or on Twitter.
