The GitHub Blog: New Features

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.

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!

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.

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.

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.

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.

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.

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.

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:

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.

Today I welcomed more than 1,500 people to our second annual Universe conference in San Francisco, an event designed to celebrate the people building the future of software. It’s an important reminder about who we’re here for—whether it’s the open source maintainer whose project is transforming healthcare, an automotive company building a self-driving car, or a teenager teaching herself how to program after she finishes her homework.

Our goal is to make building software easier for you. And with that goal in sight, we’re announcing our biggest update to the platform yet. We’re making it easier for you to work together to ship high-quality code through improved code review tools, and we’re giving our profiles an update to better show who you are as a developer. We’re making integrating with GitHub a first class experience through major API improvements. And we’re taking steps toward making GitHub a better place for businesses to get work done with added security measures for organizations.

I’m proud of our team for coming together to ship so many improvements to the platform, and I hope you’ll find them useful as you continue to build amazing things. Read on for more specifics, and keep an eye out for continued improvements to your GitHub experience in the coming months.

Manage your ideas with Projects

Taking projects from idea to launch isn’t easy. There’s a lot to coordinate behind the scenes, and so many tools out there to help you organize and distribute work. To help you integrate project management into your development cycle without skipping a beat (or even opening a new browser tab), we’re introducing Projects.

With Projects, you can manage work directly from your GitHub repositories. Create cards from Pull Requests, Issues or Notes and organize them into custom columns, whether it’s "In-progress," "Done," "Never going to happen" or any other framework your team uses. Drag and drop the cards inside a column to prioritize them or move them from one column to another as your work progresses. And with Notes, you can capture every early idea that comes up as part of your standup or team sync, without polluting your list of issues. For more on what's changed, watch this quick overview.

Although we’ll quickly be adding to Projects, our initial release currently supports:

• A New Projects tab–at the same level as Code, Issue, Pull Requests within a repository–that lists all of your projects
• Workflow columns that you can name and reorder
• Cards that you can drag and drop between columns pointing to issues, Pull Requests, or notes
• Tools built on top of Projects by some fantastic partners, including Waffle.io and ZenHub

Code better with Reviews

Collaboration is the core of building great software—and code review is critical to collaboration. When another person looks at your code and gives it the same level of critique that you did while writing it, your work gets better. We’re improving code review on GitHub to help you share the weight of building software and improve the software you build.

Designing the best way for you to review code is a continuous process, but our first step is now available on all pull requests—Reviews. In addition to commenting on specific lines of code, Reviews let you formally “approve” or “request changes” to pull requests. You can also leave a review summary and delete, edit, or bundle comments before you submit them.

To streamline conversations and cut down on noise, you can reply to inline comments without drafting a formal review or starting a new conversation. This also means you can have multiple conversations per line of code—creating more explicit feedback loops, smarter conversations, and better code review.

Finally, administrators can require Reviews before merging via protected branches. When Reviews are required, you must have a least one approval and no changes requested before you can merge.

These changes are only the first step of a much greater roadmap toward faster, friendlier code reviews. We’re working on a handful of follow-up feature improvements—including the ability to request reviews from your peers. For more information on Reviews, including what we’ve shipped today, check out the documentation or a quick tutorial video on Reviews.

Integrate seamlessly with GitHub

Developers use a variety of tools to ship their software and we’ve seen hundreds of integrations built to work with GitHub. Now we’re shipping some major improvements to our API and adding new ways to collaborate transparently not only with GitHub engineers but also the broader community of integrators. As host to the largest community of developers, we want to make the GitHub platform uniquely enjoyable for integrators to build applications that change how people work. Here’s what we’re launching right away:

• A public Platform Roadmap that demonstrates what GitHub Platform Engineers are launching next and why
• A formalized process to solicit feedback and launch updates to our platform
• Early-access and pre-release programs that let you access new features and APIs and provide you with the support you need to ensure launch readiness for the software you build on top of GitHub
• The GitHub Platform Forum which provides a direct communication channel between ecosystem developers and GitHub engineers.

With that, we are excited to announce two new projects that aim to make our platform more flexible:

Integrations Early Access

We’re rethinking our integrations model to provide better ways for tools to extend and integrate with GitHub. We’ve added the ability for an integration to act on its own behalf instead of impersonating a user—making it a first class actor on GitHub without using a paid seat. Admins will have the ability to configure integrations directly on Organizations and control which repositories they allow access to. Read more about Integrations on our Developer Blog or check out the documentation.

The GitHub GraphQL API Early Access

The GraphQL API simplifies your product development by letting developers access all the data they need, and only the data they need, with one API call. With the GitHub GraphQL API, you get the same API we use to build GitHub features. To learn more and see how it works, check out our Engineering Blog.

Have a friendlier business experience on GitHub.com

Organizations on GitHub are the best way for teams of developers to build and ship software together, and with the added security of two-factor authentication enforcement and upcoming product enhancements, they’ve never been better.

Easily enforce security

Now Organization administrators can require two-factor authentication for all members—making it easier to support security policies.

Admins will be asked to confirm the two-factor authentication requirement and a confirmation modal will list members and forks that will be removed as a result. GitHub will notify members if they’re being removed from an organization with email and in-product notifications. Finally, as always, admins can invite members back with their forks and settings intact once their security is up to speed. Read more about requiring two-factor authentication in your organization.

Take greater control over your permissions

Over the last few years, we’ve rolled out LDAP and CAS to securely and efficiently manage permissions on GitHub Enterprise. Now we’re making sure businesses on GitHub.com have the tools they need to automate identity and access management. Our first public launch is a SAML-based Single Sign-on (SSO) option. Administrators will have the ability to manage their GitHub users through the identity provider that already manages access to the host of applications they use in their current workflow. This option isn’t ready quite yet, but it will launch as a beta in the coming months. Sign up to try it out when it does.

Get help from the GitHub Community

We’re grateful to have a community of more than 16 million developers. While developers gain experience implicitly on GitHub as they work alongside other developers, we know that’s not enough. To help, we’re creating a dedicated space for you to learn from each other—and to have conversations about GitHub itself.

The GitHub Community Forum will become a place where developers can talk shop, get help, and learn together. It will also help us introduce new features and improvements and give developers the ability to share thoughts and feedback with us directly. Look out for the GitHub Community Forum in 2017.

See what’s behind your green squares

Your profile now contains your entire history of work on GitHub, from your first commit to your most recent pull request. And a per-repository breakdown reveals where you're spending your time each month. You can see special events in your history—the day you signed up for GitHub, opened your first pull request, or joined an organization—and showcase your best work by pinning favorite projects to your profile. For more on what’s changed, take a look at the documentation or watch the video.

While I’m really excited about these improvements to GitHub, I’m more excited to see what you’ll create with them.

If you'd like to start using GitHub or just see what it's all about, we're kicking off a new way for you to learn the basics. Introduction to GitHub is a self-paced, online class designed to help you:

• Get started using GitHub.com in 30 minutes or less.
• Make new friends while collaborating on a fun project.
• Dive into the worlds of GitHub and open source.

Unlike many self-paced training classes where you are completely alone, this one has a thriving Gitter community where GitHub Trainers drop in several times a day to answer questions and help those who are stuck. During the course, you are encouraged to complete an activity where you will drop a pin on our map representing your current location. Check out our current pins here to see where people are learning.

This course is 100 percent free forever and uses several popular open source projects to create a seamless learning experience. Here are a few of the projects we would like to thank:

• GitHub Classroom
• Jekyll
• Minimal Mistakes: A Jekyll theme
• Travis CI

Even if you've been using GitHub for a while, we hope you will try out the course and share your feedback in the class survey. If you think it's a good introduction to GitHub, we hope you will share the class) with others who'd like to learn.

If you've ever wanted to make minor changes before merging a pull request, now you can. When a user opens a pull request from a fork, they'll be given a new option that allows the upstream repository contributors to collaborate with them on their new branch.

Simply clone the contributor's fork and, if you've been granted permission, you'll be able to push changes to the head branch on the open pull request, even if you don't normally have permission to push to the fork.

Pull requests created before the option was available will default to not allowing collaboration, but contributors can also enable or revoke permission, by using the new checkbox in the pull request sidebar.

Learn more about collaborating with forks in our help guide.

As promised, GitHub Pages has been upgraded to Jekyll 3.2. The move to Jekyll 3.2 brings over 100 improvements including the introduction of Gem-based themes.

You can begin using the Minima theme, starting today, by adding theme: minima to your site's config, a move which eliminates the need to manually copy templates or stylesheets into your repo. While Minima is the only theme supported today, we're working to make more themes available for use on GitHub Pages. Check out the GitHub help documentation for more information on adding a theme to your GitHub Pages site.

This should be a seamless transition for all GitHub Pages users, but if you have a particularly complex Jekyll site, we encourage you to get in touch with us. For more information on these changes, see the Jekyll changelog.

You've been able to block users for a while now, but you can now see who you've blocked from your account settings page. You can also search and add new users to your blocked list, as well as unblock any user that you've blocked by accident.

Of course, if a user is bothering you, you can always block them from their profile page directly.

Check out the GitHub Help documentation for more information about blocking a user from your personal account or how to block a user from your organization.

We're making it easier to publish a website with GitHub Pages. Now you can select a source in your repository settings and GitHub Pages will look for your content there.

1. Selecting master branch will publish your site from the master branch. This is useful for repositories dedicated to website content.

2. Selecting master branch /docs folder will publish from the /docs folder of your master branch. This lets you maintain documentation and code together on one branch, and open source maintainers can accept contributions for both in a single pull request.

Rest assured that existing project pages which use a gh-pages branch will keep working just like before, as will user and organization pages published from the master branch.

Check out the documentation to learn more.

You can now change the base branch of an open pull request. After you’ve created a pull request, you can modify the base branch so that the changes in the pull request are compared against a different branch. By changing the base branch of your original pull request rather than opening a new one with the correct base branch, you’ll be able to keep valuable work and discussion.

Learn more in our help guide.

You can now search for wiki pages from either the main search page, or within a repository. Quickly discover how to use the exec command of your Redis client, or find that one page which mentioned how Guard interacts with Vim.

Check out the GitHub Help documentation for more information on how to search wiki pages, including ways to improve your results.

Organization owners are able to reinstate members that have been removed from an organization.

Reinstating a member will restore organization and team memberships, forks of private repositories, issue assignments, repository subscriptions, repository stars, and custom email routing settings.

You can reinstate a former member by inviting them through the standard organization invitation flow.

Restored members will receive an email inviting them back to the organization, and their previous settings will be reinstated.