Inform and Act

Read our official statements regarding recent executive orders and find resources to help you take action. Learn more

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.

Diversity and Inclusion at GitHub

At GitHub our goal is to help everyone build better software. To do that, we know we must create a company where anyone, regardless of what they look like or where they come from, can grow and thrive. When we deliberately seek different perspectives, life experiences, and identities, we can build better products for developers all around the world.

Over the past 18 months, diversity and inclusion have become a major focus for us. We’ve learned how diversity of life experiences makes a big difference in how we identify and solve problems, design software, and communicate. Today, we’re releasing our diversity data for the first time to show where we’ve made progress, where we haven’t, and to be transparent about how much further we have to go. We will also provide updates annually and share lessons we learn along the way.

This journey started for us in 2014, after we made some major mistakes and people got hurt. We were forced to re-evaluate our culture and our goals. We had to ask ourselves hard questions about where we fell short.

We started by looking at our own demographics—and they weren’t good. Our diversity was nowhere near industry standard, which is already too low. We also asked what we needed to do to make GitHub a place where everyone can do their best work, then started making changes.

So far, we’re seeing early signs of progress. For example, GitHub has grown from under 1% women of color at the end of 2014 to over 10% today. We’ve increased the number of women in leadership roles to 35% while the number of women overall has grown from 21% in 2014 to 36% today. Of our US employees, 6% are Latino and more than 1% of Hubbers identify as transgender, genderqueer, or nonbinary. We are proud that these are all growing segments of our company.

Still, we are falling short in obvious ways. There are no Black/African-American GitHubbers in management positions, which is unacceptable. Diversity in technical roles lags behind our overall organization. Our gender imbalance remains. And we still have a lot of work to do to ensure we are building an inclusive culture.

Specifically some of the areas we’re focusing on are:

  • Improving our recruitment processes to find candidates from all backgrounds, ensure that they meet a diverse slate of interviewers, and improve our hiring and onboarding practices so they are inclusive.
  • Institutionalizing our long-held belief that formal education is only one of many paths to success at GitHub and in tech overall. We want to hire great people based on their skills, which can be obtained in a multitude of ways.
  • Providing training for all Hubbers on building emotional intelligence, mitigating bias, and interpersonal communication as critical pieces of building inclusive culture.
  • Expanding our benefits to include transgender health care, fertility treatments, and ensuring that our maternity/paternity leave policies exceed the tech industry’s norms.
  • Modifying our San Francisco office to be more accessible. We’ve always intended our headquarters to be welcoming to our community by hosting events and are currently making changes to make it more inclusive. Hopefully we’ll see you here someday in the future.
  • Building partnerships with organizations that are successfully removing barriers to entry in tech like EveryoneOn, CODE2040, and Maven. This is a deliberate investment in the future workforce of our industry and in those who will increasingly use GitHub to build amazing things.

In looking at our data and the areas we're focusing on, there's a lot to be hopeful about—but we still have so much further to go. We are just at the beginning of making substantial changes and seeing their results.

I’ve personally learned a great deal over the past few years. One huge lesson for me has been learning that everyone has the potential to be a great developer, but not everyone has the opportunity. That's something we want to fix in our company and our community, and I invite you to join us in doing so.

I’ve also learned that increasing diversity isn’t a short term project but a lifelong journey. We want our company to reflect our world and I look forward to sharing updates on our progress with you in the future.

View the report

Repository invitations

Beginning today, repository admins must invite you to their repository and you must accept the invitation before you can start collaborating. Repository invitations let you decide whether or not you want to join as a contributor.

Collaborating with other developers is one of the best parts of open source on GitHub, but getting there hasn't always been a happy journey. Previously, anyone could automatically add other developers to their repositories without explicit permission. This model openly provided some users with opportunities to harass members of our community by inviting them to offensive or attention-seeking repositories.

New invitation acceptance page

With repository invitations, every GitHub user can accept or decline requests to collaborate on someone else's repository. Should those invites go too far—due to spam or malicious content—you have the option to block the user sending them. Blocked users cannot invite you, fork your repositories, or comment on your activity.

Repository invitations are a big step forward in providing you with more control of your experiences on GitHub. We're excited to encourage more positive and respectful interactions between our users and look forward to future opportunities to further improve our community.

Learn more about repository invitations and contact support with any questions or feedback.

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.

Migrate your repositories using ghe-migrator

Sometimes customers find themselves needing the unique advantages of GitHub Enterprise and decide to move their private repositories there. Now it's easier than ever to move repositories to GitHub Enterprise from or instances of GitHub Enterprise using ghe-migrator. In fact, it's helped more than 120 organizations migrate more than 2,500 repositories in the last nine months alone.

The advantage of using ghe-migrator instead of manually cloning and pushing repositories is that it includes GitHub data with the repository, including its issues, pull requests, user data, and wiki.

Completed migration to GitHub Enterprise

Before getting started

First off, using the ghe-migrator utility requires GitHub Enterprise version 2.3 or greater. If your version is not recent enough to use ghe-migrator, please refer to the documentation for upgrading GitHub Enterprise. The migration process also requires two other servers to be running. You will need a unix-based server running GitHub Enterprise's backup-utils and another instance of GitHub Enterprise (running the same version as your production instance) to perform dry runs of the migration.

If you are using authentication mechanisms such as LDAP or SAML, or want to enforce user naming conventions, you should also compile a CSV of username mappings. The CSV should look like this (substituting with the URL of your GitHub Enterprise instance):


Where source_url refers to the URL of a given user, and target_url contains the desired username in GitHub Enterprise. Use the map action if the target user already exists on GitHub Enterprise, and rename if the user needs to be created. You can learn more about custom mappings in the GitHub Enterprise Documentation.

All of the commands below will run directly on the GitHub Enterprise instance. Start by logging in to the administrative shell using SSH.

Note: All of the steps below should be performed on the sandbox instance of GitHub Enterprise before running them on the production instance.

You will need a personal access token from with the admin:org permission selected. The token must be generated by an owner of the organization that contains the repositories you wish to migrate. Once obtained, set an environment variable on your GitHub Enterprise instance for easy reference.

export GITHUB_TOKEN=[your personal access token]

You will also need a personal access token from your GitHub Enterprise instance from a site admin user. This will be the user performing the import to GitHub Enterprise.

It is important to make frequent backups of your GitHub Enterprise instance using backup-utils in between each step of the migration process. This affords flexibility in trying different migration strategies.

Exporting from

From your GitHub Enterprise instance, run the following cURL command to start an export job on Substitute your organization name and list of repositories to export.

curl -H "Authorization: token ${GITHUB_TOKEN}" -X POST \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  -d'{"lock_repositories":false,"repositories":["githubschool/example-repository"]}' \

From the response body, we want to capture the migration url, denoted by the url key in the JSON. Save it to an environment variable.


Note: When running this command on your sandbox instance, set "lock_repositories" to false. When you do your production migration, set it to true, and it will prevent users from creating commits, pull requests, issues, etc on the repository on

The previous command will send a response immediately, indicating that the export of your repositories has begun on You'll need to send a request to the migration status endpoint to monitor the status of the export. This command will poll the migration API every thirty seconds then output exported when it's complete.

unset STATE
until [[ $STATE == *"exported"* ]]
  STATE="$(curl -s -H "Authorization: token ${GITHUB_TOKEN}" \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  | grep -E '"state": ".*"')"
  echo $STATE
  sleep 5

When the job is complete, it will display "state": "exported" then exit.

Note: If you prefer to check the status of the export manually, and review more information about the export, you may simply send a simple cURL request to the migration API.

curl -s -H "Authorization: token ${GITHUB_TOKEN}" \
-H "Accept: application/vnd.github.wyandotte-preview+json" \

This next command will download the exported archive.

ARCHIVE_URL=`curl -H "Authorization: token ${GITHUB_TOKEN}" \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  $MIGRATION_URL/archive`; \
  curl "${ARCHIVE_URL}" -o migration_archive.tar.gz

The archive is stored on GitHub's servers, and will automatically be deleted after seven days. However, you can run this command to delete it immediately.

curl -H "Authorization: token ${GITHUB_TOKEN}" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \

Preparing to import

Next, you want to unpack the archive and prepare GitHub Enterprise for the import. In this step, GitHub Enterprise makes note of the objects that will be imported by saving references to them in a database table.

ghe-migrator prepare migration_archive.tar.gz

It's important to capture the Migration GUID from the previous command's output. Save that to an environment variable.

export MIGRATION_GUID=e9ebc5fe-9694-45af-925c-376651d933d7

It's possible that users, repositories, organizations, or other entities will have conflicting names. ghe-migrator comes with a utility to detect and output these conflicts to a CSV file.

ghe-migrator conflicts -g $MIGRATION_GUID > conflicts.csv

conflicts.csv will contain the naming collisions for the import and their suggested actions to resolve those collisions. You may need to rename some models, map them from to their GitHub Enterprise counterpart, or merge them together, as in members of a team. You can read about how to resolve migration conflicts in our GitHub Enterprise documentation.

Once you're satisfied with the mappings you've set in conflicts.csv, you can send that file back to ghe-migrator to be interpreted.

ghe-migrator map -i conflicts.csv -g $MIGRATION_GUID

This is also a good point to include any username mappings you may have set up earlier.

ghe-migrator map -i username_mappings.csv -g $MIGRATION_GUID

Import and audit

With mappings in place, you can now import our archive into GitHub Enterprise.

ghe-migrator import migration_archive.tar.gz -g $MIGRATION_GUID -u AdminUser

Where AdminUser is the username of a Site Admin on the GitHub Enterprise Appliance. After entering this command, you will be prompted to enter the GitHub Enterprise personal access token you set up during preparation.

Tip: To see what records are going to be imported or mapped before importing, you can run ghe-migrator audit -g $MIGRATION_GUID

After the import is complete, you can use ghe-migrator audit to see what was imported. Typically, you'll want to filter for records that failed to import.

ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g $MIGRATION_GUID

Once you are satisfied that the migration has completed successfully, you need to unlock the repositories on the GitHub Enterprise instance to allow users to access it. They are locked by default to prevent anyone from using them before you're sure you're happy with the import.

You may choose to unlock all repositories from this migration at once from the command line:

ghe-migrator unlock -g $MIGRATION_GUID -u YOUR-USERNAME -p YOUR-TOKEN

Or you may choose to unlock repositories individually using the Site Admin tools:

  1. Go to Admin Tools (stafftools) for each repository that was migrated.

    stafftools shortcut

  2. Click on Admin in the left sidebar.

    Admin link
  3. Click Unlock in the Single Repository Lock area.

    Unlock repo button


Now you'll be able to use your repositories that were once on in your company's instance of GitHub Enterprise. Important related information, such as issues and pull requests, will accompany your repositories. Should you require guidance with the ghe-migrator utility, GitHub Professional Services is here to help by offering on-site and remote migration assistance.

Other Resources

  • To learn more about ghe-migrator's capabilities, you can consult the GitHub Enterprise Migration documentation.
  • A guided video demonstration of the steps in this article is available on our YouTube channel.
  • For importing repositories to, read our blog post about the GitHub Importer.

Introducing unlimited private repositories

unlimited private repositories

We couldn’t be more excited to announce that all of our paid plans on now include unlimited private repositories. GitHub will always be free for public and open source projects, but starting today there are just two ways to pay for

  • Personal: $7/month
  • Organization: $9/user/month, $25/month for your first five users

One of the very best things about Git and other distributed version control systems is the ability to create a new repository without asking permission or getting approval. While this has always been true for our public plans, it hasn’t been the case for individuals and teams working together in private. All that changes today.

If you’re new to GitHub, you can sign up to start using unlimited private repositories. If you’re already using, read on to learn how these changes will impact you.

Individual developers

If you’re using GitHub for private projects, now there’s just one paid plan—unlimited private repositories for $7/month. No matter what you were paying before, your plan now includes as many repositories as you need to work on projects in private—you can even invite collaborators.

Over the next few days, we will automatically move all paid accounts, from Micro to Large, to the new plan. If you’re currently paying for one of those larger plans, look out for a prorated credit on your account.


If you’re currently paying for one of our organization plans, you’ll have the option to upgrade to unlimited private repositories at any time. For many of you, this change will mean immediate freedom from repository limits and a better way to grow and pay for GitHub.

We want everyone to have a plan with unlimited private repositories, but don’t worry—you are welcome to stay on your current plan while you evaluate the new cost structure and understand how to best manage your organization members and their private repository access. And while we're currently not enforcing a timeline to move, rest assured that you'll have at least 12 months notice before any mandated change to your plan.

A better way to work

We’ve heard from developers across our community that this new model is a better way to work. We agree—through years of building our business and developing GitHub for you, we've seen first hand the advantages of working without private repository limits. We hope you’ll create more repositories, write more code, and keep doing amazing things with GitHub.

As always, we’re here to help. Take a look at our new plans, learn how to update your personal or organization plan, or get in touch—we’d love to hear from you.

Frequently asked questions

For a paid organization on what kind of users will be charged?

You must purchase a seat for each user in your organization. These users fill a seat:

  • Organization members and owners
  • Pending invitations
  • Outside collaborators with access to 1 or more private repositories

These users do not fill a seat:

  • Outside collaborators with access to only public repositories
  • Billing managers

Will GitHub force me to move to per-user pricing after 12 months?

No. At this time we are not enforcing a timeline to move and if in the future we do decide to set a timeline we are committing to giving you at least 12 months.

I am an existing organization customer and prefer the per-repository plans. Can I remain on my current plan?

Yes, you can choose to continue paying based on the number of repositories you use. You can also upgrade or downgrade in the legacy repository structure based on the number of repositories you need.

Can there be collaborators on private repositories for the personal plan?

Yes. A paid personal account allows you to invite collaborators directly to your private repositories. If you need more granular permissions beyond full access, an organization plan is recommended.

Electron 1.0 is here

For two years, Electron has lowered the barrier to developing desktop applications—making it possible for developers to build cross-platform apps using HTML, CSS, and JavaScript. Now we’re excited to share a major milestone for Electron and for the community behind it. The release of Electron 1.0 is now available from

New to Electron? Electron is an open source framework that can help you build apps for Mac, Windows, and Linux. See how:

What’s new in Electron 1.0

Electron 1.0 comes with API stability and usability improvements, and makes it simpler than ever to explore and learn about Electron APIs with a new app, Electron API Demos. We’re also releasing and improving upon a couple tools that help developers along the way.

Read the full story on the Electron blog

Built on Electron

In just the last year, we’ve seen 1.2 million downloads and a growing community of hundreds of developers, open source maintainers, and companies who use the framework as the foundation of their apps. They’ve built everything from email, chat, and Git apps to SQL analytics tools, torrent clients, and robots. Take a tour of even more Electron apps to see what’s possible.

Electron downloads

Electron 1.0 is the result of a community effort by hundreds of developers, building amazing things. Are you ready to build your first Electron app? Get started with our quick start guide—we can’t wait to see what you create.

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!

GitHub Desktop now has a dark side

GitHub Desktop on Windows is a nice complement to developer tools such as Atom and Visual Studio. Now it visually complements those tools too! The latest update adds the ability to select a new dark theme.

GitHub Desktop with dark theme enabled

You can access this setting from the Options menu in GitHub Desktop.

GitHub Pages to upgrade to Jekyll 3.1.4

GitHub Pages will upgrade to the soon-to-be-released Jekyll 3.1.4 on May 23rd. The Jekyll 3.1.x branch brings significant performance improvements to the build process, adds a handful of helpful Liquid filters, and fixes a few minor bugs.

This should be a seamless transition for all GitHub Pages users, but if you have a particularly complex Jekyll site, we recommend building your site locally with the latest version of Jekyll 3.1.x prior to May 18th to ensure your site continues to build as expected.

For more information, see the Jekyll changelog and if you have any questions, we encourage you to get in touch with us.

Edit: To ensure a smooth transition for users, the upgrade has been rescheduled to May 23rd.

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.

GitHub Pages drops support for RDiscount, Redcarpet, and RedCloth (Textile) markup engines

Back in February, we announced, that GitHub Pages would be dropping support for the RDiscount, Redcarpet, and RedCloth (Textile) markup engines, and today we're making it official.

For the vast majority of users, making the switch should be easy, as kramdown supports all of RDiscount and Redcarpet's most popular features. If you're making the transition from Textile, follow these instructions to upgrade your site to Markdown.

In standardizing on a single Markdown engine, we're able to simplify and improve the publishing experience, by removing much of the confusion and complexity associated with the differences between various markdown interpretations, bringing things more closely in line with what you'd expect from Markdown rendering on See last month's blog post on the subject, for more context behind our decision.

If you're still using RDiscount, Redcarpet, or RedCloth, next time you push to your GitHub Pages site, you will receive an email from us with instructions on how to upgrade. We highly recommend you test building your site locally with kramdown prior to pushing. If you're a GitHub Enterprise user, this change will affect GitHub Enterprise versions 2.7 and later.

In most cases, upgrading to kramdown should be a matter of updating your site's configuration. If in the off chance you do run into any trouble, please get in touch with us, or if you have questions about what this change means for your GitHub Enterprise appliance, please contact GitHub Enterprise support. We're here to help.

Get insights from GitHub customers, community, and leaders at Satellite


Join the European developer community at GitHub Satellite in Amsterdam on May 11 to hear how organizations like Facebook, Heroku, GOV.UK, and Spotify are building software and contributing to open source. 

We’ll also share the latest on GitHub products and services, beginning with a keynote from GitHub CEO Chris Wanstrath. Check out talks from GitHub engineers and executives, including inside stories about projects like scaling GitHub, DevOps workflows, and Electron.




To close out the day, GitHub's VP of Social Impact, Nicole Sanchez, will lead a session featuring the amazing stories of nonprofits Fred Hutch and Code to Inspire, which are using technology to pave the way to a more inclusive society and a healthier world.

Hands-on Help

While you're at Satellite, you can also get your Git and GitHub questions answered personally by experts from our Services team! Schedule your one-on-one session here.

Grab tickets now, before we sell out!

GitHub Enterprise 2.6 is here with faster, more approachable workflows

A new release of GitHub Enterprise is now available—and includes features requested by developers across the GitHub community. With GitHub Enterprise 2.6, we’re introducing tools and updates that will provide teams with even more options to create efficient, flexible, and friendly processes at every step of their development cycles.

All teams work differently, so it’s important that GitHub Enterprise supports the effort they put into creating efficient, effective tooling. In this release, administrators will find tools that save time throughout their development processes, including Issue templates and support for pre-receive hooks.

GitHub Enterprise 2.6 will also help teams have productive conversations. Developers can more efficiently review code and comments with new ways to view the history of their pull requests. And to make GitHub a better communication tool for all team members, we’ve added the option to drag and drop files into repositories using the GitHub interface and an editor to style issues and comments without markdown.

Ready to upgrade? Upgrade now.

Build a workflow that works for your team

The latest release adds features and support to help you and your team create even more tailored, efficient workflows. Administrators can now:

Protect branches with greater flexibility

With more than 100,000 people pushing to nearly 300,000 Protected Branches every week, we've found a few ways to make them better. Administrators now have more flexibility over their Protected Branches with the option to merge out-of-date pull requests and set restrictions on which users and teams can merge branches. Check out the documentation to learn how.

Let your team know what's happening, fast

From GitHub Enterprise 2.6 onwards administrators can set up custom messages to share with developers on their GitHub Enterprise sign-in page. Administrators can also write custom messages for suspended users to appear when anyone with a suspended account tries to log in. See how you can use custom messages to communicate with your team.

Flexibly review pull requests

Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. Since our last release, we've worked to make reviewing pull requests faster and more flexible. With GitHub Enterprise 2.6, you can:

  • Quickly find files to review, and filter them by name or extension
  • Filter changes by commit to see how a pull request has evolved through time
  • Pick up where you left off, and view new changes to pull requests since your last visit

Choose how you commit

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. Now you also have the option to squash merge—squashing all of your commits into a tidy, easy-to-digest history. Learn more about squash merging.

Communicate better across GitHub, across teams

To help everyone on your team share their ideas, we've added features to streamline feedback and open up your development process to even more team members. Your team can now:

Upgrade today

GitHub Enterprise 2.6 is driven by developer and community feedback and includes some of our most requested improvements. Upgrade today, so your team can start taking advantage of them. You can also check out the release notes to see what else is new or enable update checks to automatically update your instance whenever there is a new release.