The Wayback Machine - https://web.archive.org/web/20170131191902/https://github.com/blog/category/ship
Skip to content

Filter pull request reviews and review requests

Pull request reviews are a great way to share the weight of building software, and with review requests you can get the exact feedback you need.

To make it easier to find the pull requests that need your attention, you can now filter by review status from your repository pull request index.

A screenshot showing the reviews filter menu in a repository pull request index

Use the Reviews filtering menu to see the pull requests still awaiting review, unreviewed pull requests on protected branches that require a review, approved pull requests that are ready to merge, and pull requests that have a review requesting changes.

You can also filter pull requests that have been reviewed by a specific user and quickly locate those that have required your review in the past to decide which needs your attention first.

A screenshot showing the global review requests dashboard

Finally, we've also added review requests to the global pull request dashboard so you can see all pull requests awaiting your feedback across all of your repositories and organizations.

You're welcome to drop any questions, comments, or feedback into our help form.

Manage pull requests with the GitHub Extension for Visual Studio

No need to toggle between windows, you can now manage pull requests without leaving Visual Studio. The GitHub Extension for Visual Studio includes a new pull request window that lets you review code, make changes, and push those changes back to GitHub. This release also provides support for upstream repository contributors to collaborate on a forked branch.

A Pull Request shown in the GitHub Extension

You can install the extension directly from the Visual Studio gallery or download it from visualstudio.github.com.

Last year we introduced the GitHub Extension for Visual Studio as an open source project under the MIT license. We welcome you to log issues and contribute in the extension repository.

Navigate file history faster with improved blame view

Whether you're debugging a regression or trying to understand how some code came to have its current shape, you'll often want to see what a file looked like before a particular change. With improved blame view, you can easily see how any portion of your file has evolved over time without viewing the file's full history.

use-the-improved-blame-view-to-see-what-the-file-looked-like-before-a-particular-change

Check out the GitHub Help documentation for more information on using git blame to trace the changes in a file.

Visualize your project's community

A new graph is available in the Graphs tab to visualize your repository's data. With the dependents graph, you can now explore how repositories that contain Ruby gems relate to other repositories on GitHub.

If you're an open source maintainer, this means you can find out more about the community connected to your project in addition to projects that depend on your repository and its forks.

Screenshot of dependents page

The page starts with a list of the latest repositories to depend on your repository, making it easier to discover the newest members of your community. It also allows you to filter by either packages, which are other repositories that are gems, or applications, which are other public repositories that aren't gems themselves but use your gem.

The dependency graph works for Ruby gems today, and we plan to expand support to other package ecosystems in the future. For more on what graphs can tell you about your project, check out our Help guide on Graphs.

Search commit messages

You can now search for commits from either the main search page or within a repository. Quickly discover who removed set -e or find commits that involved refactoring.

Commit search

Check out the GitHub Help documentation for more information on how to search commits.

Resolve simple merge conflicts on GitHub

You can now resolve simple merge conflicts on GitHub right from your pull requests, saving you a trip to the command line and helping your team merge pull requests faster.

Demonstrating how to resolve a merge conflict

The new feature helps you resolve conflicts caused by competing line changes, like when people make different changes to the same line of the same file on different branches in your Git repository. You'll still have to resolve other, more complicated conflicts locally on the command line.

For more on merge conflicts and how to make them disappear on GitHub and on the command line, check out the GitHub Help documentation.

Publishing with GitHub Pages, now as easy as 1, 2, 3

Publishing a website or software documentation with GitHub Pages now requires far fewer steps — three to be exact:

  1. Create a repository (or navigate to an existing repository)
  2. Commit a Markdown file via the web interface, just like you would any other file
  3. Activate GitHub Pages via your repository's settings

And that's it — you now have a website. If you're already familiar with GitHub Pages, you may be interested to know that behind the scenes, we're now doing a few things to simplify the publishing experience and bring it more in line with what you may expect from authoring Markdown content elsewhere on GitHub:

  1. All Markdown files are now rendered by GitHub Pages, saving you from needing to add YAML front matter (the metadata at the top of the file separated by ---s) to each file.
  2. We'll use your README file as the site's index if you don't have an index.md (or index.html), not dissimilar from when you browse to a repository on GitHub.
  3. If you don't specify a theme in your site's config (or don't have a config file at all), we'll set a minimal, default theme that matches the look and feel of Markdown elsewhere on GitHub.
  4. If a given file doesn't have a layout specified, we'll assign one based on its context. For example, pages will automatically get the page layout, or the default layout, if the page layout doesn't exist.
  5. If your page doesn't have an explicit title, and the file begins with an H1, H2, or H3, we'll use that heading as the page's title, which appears in places like browser tabs.

These improvements should allow you to quickly and easily publish your first (or 100th) website with just a few clicks, or to document your software project by simply adding Markdown files to a /docs folder within your repository. Of course, you can continue to control the look and feel by opting in to additional customizations (such as overriding the default theme with your own layouts or styles).

While these changes shouldn't affect how most existing sites build, there are two potential gotchas for some more advanced Jekyll users:

  1. If your site iterates through all pages (e.g., for page in site.pages), you may find that there are now additional pages (such as the README of a vendored dependency) in that list. You can explicitly exclude these files with your config file's exclude directive.
  2. If you don't specify a page's layout or title, and expect either to be unset (e.g., if you need to serve unstyled content), you'll need to explicitly set those values as null.

And if for any reason you don't want these features, you can disable them by adding a .nojekyll file to your site's root directory.

So that the GitHub Pages build process can be as transparent and customizable as possible, all the above features are implemented as open source Jekyll plugins, namely Jekyll Optional Front Matter, Jekyll README Index, Jekyll Default Layout, and Jekyll Titles from Headings.

Again, these changes shouldn't affect how most existing sites build (although you can safely begin to use these features), but if you have any questions, please get in touch with us.

Happy three-step publishing!

Introducing review requests

You can now request a review explicitly from collaborators, making it easier to specify who you'd like to review your pull request.

You can also see a list of people who you are awaiting review from in the pull request page sidebar, as well as the status of reviews from those who have already left them.

gif of requesting review from sidebar

Pending requests for review will also show in the merge box. They do not affect mergability, however, so you can still merge your pull request even if you are still awaiting review from another collaborator.

image of merge box showing a requested review

Learn more about requesting reviews in our Help docs.

Relative links for GitHub pages

You've been able to use relative links when authoring Markdown on GitHub.com for a while. Now, those links will continue to work when published via GitHub Pages.

If you have a Markdown file in your repository at docs/page.md, and you want to link from that file to docs/another-page.md, you can do so with the following markup:

[a relative link](another-page.md)

When you view the source file on GitHub.com, the relative link will continue to work, as it has before, but now, when you publish that file using GitHub Pages, the link will be silently translated to docs/another-page.html to match the target page's published URL.

Under the hood, we're using the open source Jekyll Relative Links plugin, which is activated by default for all builds.

Relative links on GitHub Pages also take into account custom permalinks (e.g., permalink: /docs/page/) in a file's YAML front matter, as well as prepend project pages' base URL as appropriate, ensuring links continue to work in any context.

Happy (consistent) publishing!

GitHub Extension now supports Visual Studio 2017 RC

The GitHub Extension for Visual Studio now supports Visual Studio 2017 RC, including support for cloning repositories directly from the Visual Studio Start Page. We've also improved our startup time to get you productive as fast as possible.

This release, version 2.1.1.0, is available as an optional installation component in the installer for both Visual Studio 2015 and Visual Studio 2017 RC. You can also install it directly from the Visual Studio gallery or download it from visualstudio.github.com.

Last year we introduced the GitHub Extension for Visual Studio as an open source project under the MIT license. You can log issues and contribute to the extension in the repository.

Clone from GitHub on Start Page

What's new in GitHub Pages with Jekyll 3.3

GitHub Pages has upgraded to Jekyll 3.3.0, a release with some nice quality-of-life features.

First, Jekyll 3.3 introduces two new convenience filters, relative_url and absolute_url. They provide an easy way to ensure that your site's URLs will always appear correctly, regardless of where or how your site is viewed. To make it easier to use these two new filters, GitHub Pages now automatically sets the site.url and site.baseurl properties, if they're not already set.

This means that starting today {{ "/about/" | relative_url }} will produce /repository-name/about/ for Project Pages (and /about/ for User Pages). Additionally, {{ "/about/" | absolute_url }} will produce https://baxterthehacker.github.io/repository-name/about/ for Project Pages (and https://baxterthehacker.github.io/about/ for User Pages or http://example.com/about/ if you have a custom domain set up).

Second, with Jekyll 3.3, when you run jekyll serve in development, it will override your url value with http://localhost:4000. No more confusion when your locally-modified CSS isn't loading because the URL is set to the production site. Additionally, site.url and absolute_url will now yield http://localhost:4000 when running a server locally.

Finally, to make it easier to vendor third-party dependencies via package managers like Bundler or NPM (or Yarn), Jekyll now ignores the vendor and node_modules directories by default, speeding up build times and avoiding potential errors. If you need those directories included in your site, set exclude: [] in your site's configuration file.

For more information, see the Jekyll changelog and if you have any questions, please let us know.

Happy publishing!

Introducing Projects for Organizations

You can now use GitHub Projects at the Organization level. All users in your Organization will have access to its Projects, so you and your team can plan and manage work across repositories. With organization-wide Projects, everyone can see what's already in motion and work together without duplicating efforts.

Projects for Organizations

Organization-wide projects can contain issues and pull requests from any repository that belongs to an organization. If an organization-wide project includes issues or pull requests from a repository that you don't have permission to view, you won't be able to see it.

Projects launched in September 2016. Check out the documentation to see how you can use them, and stay tuned—there's more to come.

Dismissing reviews on Pull Requests

Dismiss reviews on GitHub

Pull request reviews are a great way to share the weight of building software. Using protected branches to block merging when pull requests have reviews that request changes helps your team maintain quality, bug-free code. However, this requirement can sometimes block your team’s progress without good reason. If someone leaves a review that requests changes and then goes on vacation or runs into computer problems, your pull request could be blocked for days, even after you’ve addressed the reviewer’s concerns.

To improve this workflow, we’re adding the ability for pull request collaborators to dismiss reviews. When someone leaves a review that requests changes, dismissing the review changes it from a review that requests changes to a review comment. This will unblock your pull request, freeing you up to merge it!

You can also dismiss an approving review. This is useful when your pull request has changed significantly since the approval, and you think it’s important to get another review.

When one of your team members dismisses a review, they’ll have to leave a reason why. This keeps people from simply bypassing the protected branch review requirement out of convenience.

Rebase and merge pull requests

The merge button on pull requests supports two great workflows
with merge commits and commit squashing.
Now you can use the merge button to rebase and merge your changes, too.

Rebase

How does it work?

When you select the new "Rebase and merge" option,
the commits from the pull request's branch are rebased on to the tip
of the base branch, and then the base branch itself is fast forwarded
to this newly rebased head. Rebases automatically set the committer of
the rebased commits to the current user, while keeping authorship
information intact.
The pull request's branch will not be modified by this operation.

If a rebase can't be performed due to conflicts, we'll let you know so
you can manually resolve them as necessary.

Rebase with conflicts

As with "Squash and merge", repository administrators can decide whether they
want to allow this new option on the repository settings page.

Learn more about rebase and merge in our Help docs.

License now displayed on repository overview

Licenses are now displayed in the repository overview, allowing anyone to easily see if a project has an open source license. This change is immediately available on GitHub, and will also ship with the upcoming Enterprise 2.8 release.

A shortened license name, linking to the repository’s license file, is displayed on the repository page:

screenshot

We use an open source Ruby gem called Licensee to compare the repository's LICENSE file to a short list of known licenses. This is the same code we use to provide the Licenses API and understand how repositories on GitHub are licensed.

We don’t detect every open source license, nor complicated situations such as projects with multiple licenses. For those situations you can still find and read the project’s license(s) as before.

Open source is a fundamental part of GitHub’s community. Adding an open source license to your repository ensures that others can use, copy, modify, and contribute back to your project. It's an important step when creating an open source project. If your repository doesn’t have an open source license and you want others to get involved, consider adding one now.

You can't perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Morty Proxy This is a proxified and sanitized view of the page, visit original site.