The GitHub Blog: New Features

Milestones and labels are a handy way to group and organize your issues, but sometimes it’s helpful to indicate which ones you or your team want to focus on first. You can now reorder issues and pull requests and indicate priority by moving them higher up or lower down the list.

Re-ordering Issues

Once you’ve grouped issues and pull requests within a milestone, drag-and-drop to place them in whatever order you need, or use keyboard commands to select and move items up or down the list.

Learn more about Milestones and issue prioritization in our help guide.

When you enable email notifications, GitHub sends you messages about everyone's issues, pull requests, comments, and commits except your own. For many people that leaves email threads feeling incomplete. For this reason, we have added a configuration setting so that you can receive emails about your own activity, too.

These emails contain the address your_activity@noreply.github.com in the CC field so you can filter them in different ways. For instance, you can mark these emails as read automatically and only receive notifications about others' actions—all while keeping the complete conversation in your inbox. You can also star or tag emails, so they'll stand out among all the other updates you might receive.

We've also added a few more configuration settings that let you get notifications on the actions that interest you most. Now you can choose to receive email updates for comments on issues and pull requests, pull request reviews, and pull request pushes, too.

You can now showcase the repositories that best represent your work on your GitHub profile. Using the "Pinned repositories" list, you can pin any public repository you have contributed to. Once you have chosen up to five repositories, you can then drag-and-drop to place them in whatever order you like.

If you don't customize your pinned repositories, we'll continue to show your most popular repositories. Learn more in our help guide.

Together with our new profile bios, pinned repositories allow you to create a GitHub profile that's the best representation of you and your work. We can't wait to see what you pin.

Millions of people rely on GitHub Pages to host their websites and millions more visit these websites every day. To better protect traffic to GitHub Pages sites, as well as to encourage the broader adoption of HTTPS across the internet, GitHub Pages now officially¹ supports HTTPS for all <username>.github.io sites. HTTPS provides a layer of encryption that prevents others from snooping on or tampering with traffic to your Pages site.

You can now visit *.github.io sites using HTTPS and configure HTTPS enforcement for your site. With HTTPS enforcement enabled, any HTTP requests to your github.io site will be transparently redirected to HTTPS.

Starting next Wednesday (June 15, 2016, 12pm PDT), HTTPS enforcement will be required for all new GitHub Pages sites. To enable HTTPS enforcement for your existing *.github.io site, visit the settings page for your site's repository. Check out the Pages HTTPS documentation for more information.

¹ You have been able to request Pages sites over HTTPS for some time, but we refrained from officially supporting it because the traffic from our CDN to our servers wasn't encrypted until now.

We've rolled out several changes to our email notifications. Now you have more ways to filter your email notifications and each email will contain more information about why you received it.

Updates to the footer

The footer of every email now indicates why you've received a specific correspondence. It contains the same subscription reasons that are available on GitHub.com—for example, whether you or your team were directly mentioned.

If you no longer want to follow a thread, you can mute any new conversations directly from the email. (Note that this will only work for email clients configured to receive HTML emails).

Notification reason as the CC email address

In addition, the same notification reasons exist as a CC email address. This should help with labelling and filtering emails you receive for services like GMail and iCloud that don't support filtering by our X-GitHub-Reason header.

Our Help documentation provides a full list of the subscription reasons.

We hope these changes enhance your email notification experience!

You can now move checklist items around just by dragging and dropping them. Reorder items quickly and easily without editing the original comment's Markdown.

How to re-order task list items

Create a task list item using - [ ] at the start of a new line. When you hover over the left-hand side of an item's checkbox, you'll see the option to drag and drop it into a new location.

Learn more from our our documentation.

Issues and pull requests often need to be assigned to more than one person. Multiple Assignees are now supported, allowing up to 10 people to be added to a given Issue or Pull request.

Using multiple assignees

Assignees can be added and removed on the web UI by clicking on the assignees dropdown in the sidebar and adding multiple users.

Check out the documentation for more information on this feature.

As promised, GitHub Pages has moved to the Jekyll 3.1 branch with an upgrade to Jekyll 3.1.6. Jekyll 3.1 brings significant performance improvements to GitHub Pages. By using Liquid::Drops, rather than Ruby Hashes, Jekyll now calculates document and site metadata on demand, rather than calculating every possible value at build time.

While this should be a seamless transition for most GitHub Pages users, we recommend that all users test locally using the GitHub Pages Gem before pushing. This ensures that your site will continue to build as expected. Three things to note as you upgrade:

1. All front matter defined in layouts are now accessible only via {{ layout }}. In you define a variable width: full in your layout's YAML front matter, access it with layout.width.

2. The inheritance of front matter values properly merges a child layout's front matter over its parent's front matter. If you define a variable color: purple in a layout called post which has a parent layout of default, and you define color: blue in the default layout, then {{ layout.color }} will be purple. For more on this, read the pull request that made the change.

3. If you are using the Jekyll Bootstrap theme, you must update the contents of _includes/JB/setup to use {{ layout.theme.name }} instead of {{ page.theme.name }}.

Beyond the performance improvements, Jekyll 3.1.6 includes over 100 changes, including many bug fixes, both to the rendering process and to the experience of previewing Jekyll locally.

For a full list of changes, see the Jekyll changelog and of course, if you have any questions, please get in touch with us.

Earning green squares on your contribution graph means celebrating the work you do in open source and public projects. Starting today, you can also celebrate the work you do in private by sharing anonymized contributions from private repositories.

We think including your work in private repositories is a more accurate representation of your contributions, but your privacy is important too. Private contributions are not shown by default and, when enabled, are completely anonymized to the general public. You can opt into sharing your private contributions in your profile settings. Details of the issues, pull requests, and commits you have made on private repositories are only visible to your fellow repository collaborators.

As part of this update, code streaks are no longer featured on your contribution graph. The simplified interface focuses on the work you're doing rather than the duration of your activity.

Now that every paid plan includes unlimited private repositories, you can experiment all you want in private and still add to your contribution graph. For more information, read our help guide for toggling private contributions on your profile.

Ensuring that your GitHub Pages site appears in search engines and is shareable via social media is now easier with the introduction of the Jekyll SEO Tag plugin.

By simply adding the {% seo %} tag to your site's template Jekyll will automatically add the appropriate search engine metadata to each page, including the page title, description, canonical URL, next and previous URLs for posts, and JSON-LD site and post metadata to help your site get properly indexed by search engines.

Additionally, the SEO tag plugin adds open graph and summary card metadata, ensuring properties like the title, description, and any featured images are displayed richly when your content is shared on Facebook, LinkedIn, Twitter, and other social networks.

While you've always been able to add the various metadata tags yourself, the plugin provides a battle-tested template of crowdsourced best-practices, which along with the Jekyll sitemap plugin, will help your site appear in major search engines.

For more information, see using Jekyll SEO Tag on GitHub Pages.

Happy Search Engine Optimizing!

You can now import repositories from Subversion, Mercurial, and TFS that include files larger than 100 MB using the GitHub Importer.

This new ability is powered by Git LFS. When the repository you are importing has files larger than 100 MB you can opt-in to using LFS to store those large files or opt-out and the files will simply be removed from your repository during the import.

You can learn more about our LFS feature and working with large files on our help site.

A year ago, Jekyll sites on GitHub pages gained access to repository and organization metadata with the introduction of the site.github namespace.

We recently moved our own site.github implementation to use the community-driven GitHub metadata Jekyll plugin, meaning it's now easier to preview sites locally that rely on repository or organization metadata using the exact same process GitHub Pages uses to build your site in production.

To recreate the site.github namespace when previewing your site locally, assuming you're using the GitHub Pages gem, simply add the jekyll-github-metadata gem to your site's config:

gems:
 - jekyll-github-metadata

For more information on using repository and organization metadata, when previewing locally or on GitHub Pages, see the plugin and repository metadata documentation.

When you're building software with people from around the world, sometimes it's important to validate that commits and tags are coming from an identified source. Git supports signing commits and tags with GPG, and starting today GitHub will show you when commits and tags are signed.

When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor's GPG keys uploaded to GitHub. You can upload your GPG keys by visiting the keys settings page.

Many open source projects and companies want to be sure that a commit is from a verified source. GPG signature verification on commits and tags makes it easy to see when a commit or tag is signed by a verified key that GitHub knows about.

To learn more about how to generate a GPG key and start signing your work, read our GPG documentation articles.

Community is one of the most important aspects of open source, but sometimes a few bad actors can ruin the experience for the group. To help address the problem, organization owners now have the ability to block abusive users from public repositories. This feature allows project owners to block users, and prevents blocked users from opening or commenting on issues or pull requests, forking repositories, and adding or editing wiki pages.

All records of blocked activity are available in the organization's audit log for your reference.

To learn more about encouraging positive contributions in your organization, read our community documentation articles.

Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits, resulting in a style of history that didn’t necessarily match your own workflow.

Merge commits

For years, the merge button on GitHub has created merge commits (i.e. git merge --no-ff) which retain all of the commits in your branch and interleaves them with commits on the base branch. The result of a merge commit is a visually complex, but more accurate log that depicts how changes from a feature branch came to be on the base branch. Here’s what that looks like today:

Enter commit squashing

Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch. Here’s what squashing on merge looks like:

What’s changing?

Repository administrators now have a few options to choose from when deciding how to handle history.

Allow merge commits and commit squashing

This option will leave the decision to create a merge commit or squash up to the user doing the merging. This lets repository administrators stay flexible when deciding whether or not to retain all history from a feature branch.

Only allow merge commits

This is the default behavior and is exactly how the merge button worked before this change. Collaborators won’t have the option to squash their commits via the merge button.

Only allow squash commits

This is a new option which lets you force commit squashing on all pull requests merged via the merge button.

Check out the documentation or get in touch with any questions or feedback. Enjoy!