Skip to content

Drag-and-drop tasks in Markdown task lists

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.

Multiple assignees on Issues and Pull requests

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.

GitHub Pages now runs Jekyll 3.1

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 {{ }} instead of {{ }}.

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.

More contributions on your profile

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.

GitHub contribution graph settings

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.

Better discoverability for GitHub Pages sites

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!

Import repositories with large files

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

detecting and importing

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.

opting in or out of LFS

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

Preview GitHub Pages metadata locally

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:

 - 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.

GPG signature verification

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.

screenshot 2016-04-04 08 44 43

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.

screenshot 2016-04-04 10 35 33

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

Organizations can now block abusive users

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.

Screenshot of organization settings

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

Screenshot of organization audit logs

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

Squash your commits

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:

Merge commits create accurate, but more complex history

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.

New merge button settings

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.

Squash and merge

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

Protected Branches Improvements

Over 100,000 people push to protected branches nearly 300,000 times every week. We’ve been listening to how we can make protected branches even better and we’re happy to introduce two workflow improvements.

Merging out-of-date pull requests

Required status checks currently provide a strong guarantee of compatibility between a pull request’s base and head branches. Not only must the status checks be passing, the head branch must also be up to date with the protected base branch in order to be merged. This catches hard-to-spot incompatible changes that don’t cause merge conflicts but result in broken code nonetheless.

The extra status check runs required by this policy can be a burden for teams where many changes are being made to a protected branch. To make this easier for those teams, we’ve added a setting which will still enforce required status checks but will no longer require a pull request to be up to date before merging.

Toggle whether a branch has to be up to date with a protected branch

User and team restrictions

Sometimes merges to a protected branch are best left to a release manager or a team of people responsible for the stability of that particular branch. Organizations can now specify which members and teams are able to push to a protected branch. Note that organization and repository administrators are always able to push.

Choose which users and teams can push to a protected branch

Protected branches help you keep your codebase safe from force pushes and buggy code. These changes give you better control over whom can push to your protected branches and make the experience for very active repositories much smoother. Check out the documentation for more information or get in touch with any questions or feedback.

Saved replies

We know from community feedback and open source projects (like @notwaldorf’s Chrome extension) that replying with the same response to Issues and Pull requests over and over can be tedious. Saved replies allow you to create a response to Issues and Pull requests and reuse it multiple times, saving you a ton of time typing and posting the replies you use most frequently. It’s available on all repositories starting today.

Using Saved replies

To get started, go to your personal settings and click “Saved replies”. Here, you can add custom replies based on the types of responses you use most frequently. You can edit and update these anytime.

Add a saved reply

You can access your Saved replies when composing or replying to an Issue or Pull request.

Insert a saved reply

Check out the documentation for additional information on the feature.

More code review tools

Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. We’re adding new features to make code review on GitHub faster and more flexible.

Find what you’re looking for, faster

Pull requests with many changes sometimes require review from several people with different areas of expertise. If you’re a Ruby expert, for example, you might want to focus just on the Ruby code and ignore any changes made to HTML and CSS files. You can use the new files list to search by extensions like .rb, .html, etc. You can also filter by filename if you know what you’re looking for.

Find files you’re looking for, faster

More flexible review

Not all teams review code the same way. The most popular style on GitHub is reviewing all changes in a pull request at once, making the pull request the unit of change. Some teams choose to use a commit-by-commit workflow where each commit is treated as the unit of change and is isolated for review.

Page through commits easily

For teams using this style, you’ll now have access to the new commits list in the review bar which can help you quickly find the commit you want to review. We’ve also added pagination and new keyboard shortcuts to make navigating through commits in a pull request even easier. Use the ? key when viewing a pull request to view the list of keyboard shortcuts.

Use previous and next buttons to navigate through commits

View comments with more context

Every day, developers have interesting conversations and debates about code during the review process. These conversations can help new and future developers gain context quickly and better understand how and why a codebase has evolved over time. To ensure these conversations and the accompanying diffs are never lost we’ve made it easier to get deeper context on any line comment, even if it has been outdated by newer changes.

Use the “view outdated diff” button for more context

Pick up where you left off

While code review is essential for high quality code, it can be a long and tiring process, especially for projects with many incoming pull requests. It’s often most helpful to view just the new changes that have occured after you have reviewed a pull request, so we’ve added a timeline indicator to help you get to those changes, faster.

New changes are now marked in the timeline

Today’s changes are all about making code review on GitHub faster and more flexible for you and your teams. Check out the documentation for more information on working with pull requests. As always, get in touch with us for any questions or feedback. We’d love to hear how we can make code review even better.

Add Reactions to Pull Requests, Issues, and Comments

Every day, thousands of people are having conversations on GitHub around code, design, bugs, and new ideas. Sometimes there are complex and nuanced points to be made, but other times you just want to :+1: someone else's comment. We're adding Reactions to conversations today to help people express their feelings more simply and effectively.

While people have been able to include emoji in responses for a long time, using them as reactions resulted in a lot of noise. In many cases, especially on popular projects, the result is a long thread full of emoji and not much content, which makes it difficult to have a discussion. With reactions, you can now reduce the noise in these threads.

We decided to choose reactions that are relevant to the conversations people have on GitHub. :+1::-1::smile::confused::heart::tada: cover the range of reactions our users typically express through comments on GitHub. We’re looking forward to seeing how the GitHub community uses this set of reactions.

Reactions are available on all Issues and Pull Requests on GitHub today. So go ahead…:+1: or :tada: to your :heart:s content.

Issue references and @mentions for GitHub Desktop

GitHub Desktop on both Windows and Mac now provides suggestions when mentioning team members, referencing Issues, and adding more :tada: to your commit messages and Pull Requests.

Just as you would on the website, you can bring another collaborator into the conversation by prefacing their username with @, reference any Issue by hitting #, and include any emoji by putting : around its name. Happy shipping! :sparkles:

demonstration of Issue lookup, @ mentions, and emoji lookup

Something went wrong with that request. Please try again.