Inform and Act

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

New GitHub Terms of Service

We’re in the process of updating our Terms of Service, and we’d like to get your input on the draft of our new Terms.

Why the change?

In short, our current Terms of Service agreement could do a better job of answering your questions about how our service works. We've heard your feedback, and we're updating our Terms to make them less ambiguous and easier to read so that you know what you’re agreeing to.

An overview of the new Terms

In general, this update lets us do a better job of putting our current business practices in clearer terms for our users. Some of the changes you’ll find in the new Terms of Service:

  • Reading the Terms: You’ll find a table of contents, as well as a summary of every section in plain English.
  • Acceptable Use: We have clarified our Acceptable Use Policy, including our policy on scraping and misuse of GitHub Users’ personal information.
  • Ownership of Content: We don’t claim any ownership rights to the content you upload to GitHub. What’s yours is yours. In the new Terms, however, we have added an explicit license to clarify our right to store and serve it without violating your rights.
  • Default Contributor License: To address growing confusion over licensing and contributions to others’ projects, we added a simple default contributor license. If it does not suit your needs, you may add your own Contributor License Agreement to your repository.
  • GitHub Pages terms: We have clarified our rules regarding GitHub Pages.
  • Advertising on GitHub: Advertising is not prohibited on GitHub, but it is heavily scrutinized because we don’t want to become a spam haven. Our Terms now describe the kind of advertising that GitHub allows.

Taking action

We want your input. Please look over our new Terms, compare them to our old Terms if you want to, and tell us what you think via the new Terms of Service contact form. Let us know if you see anything you think should be different, whether it’s a typo we missed or a rule that might have implications we haven’t thought of.

We’ll leave comments open until 5:00pm (PST) Tuesday, February 21. Then, we’ll take a week to go through your comments, make whatever changes will improve the Terms, and we’ll enact the new Terms on Tuesday, February 28.

We look forward to hearing from you!

New and improved two-factor lockout recovery process

Starting January 31, 2017, the Recover Accounts Elsewhere feature will let you associate your GitHub account with your Facebook account, giving you a way back into GitHub in certain two-factor authentication lockout scenarios. If you've lost your phone or have otherwise lost the ability to use your phone or token without a usable backup, you can recover your account through Facebook and get back to work. See how the new recovery feature works on the GitHub Engineering Blog.

Image of recovery screen on Facebook

Currently, if you lose the ability to authenticate with your phone or token, you have to prove account ownership before we can disable two-factor authentication. Proving ownership requires access to a confirmed email address and a valid SSH private key for a given account. This feature will provide an alternative proof of account ownership that can be used along with these other methods.

To set up the new recovery option, save a token on the security settings page on GitHub. Then confirm that you'd like store the token. If you get locked out for any reason, you can contact GitHub Support, log in to Facebook, and start the recovery process.

Image of recovery option on GitHub

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.

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.


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.

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

Introducing GitHub Community Guidelines

Building software should be safe for everyone. The GitHub community is made up of millions of developers around the world, ranging from the new developer who created their first "Hello World" project to the most well-known software developers in the world. We want the GitHub community to be a welcoming environment where people feel empowered to share their opinion and aren't silenced by fear or shouted down.

Beginning today, we will be accepting feedback on proposed GitHub Community Guidelines. By outlining what we expect to see within our community, we hope to help you understand how best to collaborate on GitHub and what type of actions or content may violate our Terms of Service. The policy consists of four parts:

  1. Best practices for building a strong community - people are encouraged to be welcoming, assume no malice, stay on topic, and use clear and concise language at all times.
  2. What to do if something offends you - project maintainers are encouraged to communicate expectations and to moderate comments within their community — including locking conversations or blocking users when necessary.
  3. What behavior is not allowed on GitHub - the community will not tolerate threats of violence, hate speech, bullying, harassment, impersonation, invasions of privacy, sexually explicit content, or active malware.
  4. What happens if someone breaks the rules - GitHub may block or remove content and may terminate or suspend accounts that violate these rules.

As always, we will continue to investigate any abuse reports and may moderate public content on our site that we determine to be in violation of our Terms of Service. To be clear, GitHub does not actively seek out content to moderate. Instead, we rely on community members like you to communicate expectations, moderate projects, and report abusive behavior or content.

Additionally, we are releasing the guidelines under the Creative Commons Zero License in hopes of encouraging other platforms to establish similar norms to govern their respective communities.

These guidelines are first and foremost community guidelines and we'd like to hear your thoughts on them before they're finalized. Please get in touch with us with any feedback or questions prior to November 20th, 2016. Together, we can make the open source community a healthy, inclusive place we can all be proud of.

Updates to our Privacy Statement

When you check your GitHub account today, you’ll see an announcement letting you know that we’ve updated our Privacy Statement. Check it out!

Before we get into what’s new, rest assured that your information is still safe and sound. We have not made any substantive changes to the way we handle your information. For example, we still . . .

  • don’t sell your personal information to any third parties for their commercial purposes;
  • don’t have advertising on GitHub;
  • only require a small amount of information; and
  • only use your information for the purpose of providing services to you.

What’s changed

The new Privacy Statement clarifies quite a few things about how GitHub uses data, and how we permit third parties to use your information. For example, the new Privacy Statement describes how people such as researchers or archivists can use your public information on, and it explains that third parties using public information must respect our users’ choices. The new Privacy Statement now also includes a statement regarding tracking—we don’t track your web browsing off our site, and we don’t let third parties track you on GitHub.

Privacy Shield compliance

With this updated Privacy Statement, we’ve also applied for certification with the new EU–US Privacy Shield Framework. Privacy Shield is an agreement between the US Department of Commerce and the European Commission that provides companies in both the United States and the European Union a mechanism to comply with EU data protection requirements when transferring personal data from the EU to the US. We expect to receive our certification shortly, and we currently comply with the Privacy Shield Principles to protect all our users’ information.

Protecting our users

Although the Privacy Shield is only directed to users in the European Union, GitHub is committed to protecting all our users equally, regardless of where you live. So we are extending Privacy Shield’s benefits to all our users, including access to a free independent arbitration provider for privacy disputes.

Please take a few minutes to look over the new Privacy Statement, and please reach out if you have any questions.

GitHub Extension for Visual Studio 2.0 is now available

We're pleased to announce that version 2.0 of the GitHub Extension for Visual Studio is now available. You can install it directly from the Tools and Extensions gallery in Visual Studio, as well as from our releases page and our website.

This release allows you to list your existing pull requests and create new ones directly from Visual Studio. You can also create gists directly from your code, making it even easier to share your code and collaborate. It also includes a slew of other enhancements and fixes, available in our release notes.

Screenshot of Visual Studio with GitHub pane open

As we focus our efforts on building workflows targeted towards maintainers and contributors, we'd love to hear your thoughts on how we can improve our tools. Let us know what works and what doesn't and how to make your coding and collaboration workflows easier.

Reorder issues within a milestone

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.

keyboard shortcuts

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

GitHub Security Update: Reused password attack

What happened?

On Tuesday evening PST, we became aware of unauthorized attempts to access a large number of accounts. This appears to be the result of an attacker using lists of email addresses and passwords from other online services that have been compromised in the past, and trying them on GitHub accounts. We immediately began investigating, and found that the attacker had been able to log in to a number of GitHub accounts.

GitHub has not been hacked or compromised.

What information was involved?

For affected accounts, usernames and passwords are involved. Additionally, for some accounts, other personal information including listings of accessible repositories and organizations may have been exposed.

What we are doing:

In order to protect your data we’ve reset passwords on all affected accounts. We are in the process of sending individual notifications to affected users.

What you can do:

If your account was impacted, we are in the process of contacting you directly with information about how to reset your password and restore access to your account.

We encourage all users to practice good password hygiene and enable two-factor authentication to protect your account.

These attacks often evolve, and we’re continuing to investigate and monitor for new attack vectors. Please keep an eye on our blog and on Twitter for pertinent updates, or contact Support if you have any questions.

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.

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.

Expanded webhook events

Webhooks are one of the more powerful ways to extend GitHub. They allow internal tools and third-party integrations to subscribe to specific activity on GitHub and receive notifications (via an HTTP POST) to an external web server when those events happen. They are often used to trigger CI builds, deploy applications, or update external bug trackers.

Based on your feedback, we've expanded the kinds of events to which you can subscribe. New events include:

  • Editing an issue or pull request's title or body
  • Changing a repository's visibility to public or private
  • Deleting a repository
  • Editing an issue comment, pull request comment, or review comment
  • Deleting an issue comment, pull request comment, or review comment

When the action in question was an edit, the webhook's payload will helpfully point out what changed.

changed payload

These expanded webhook events are now available on For more information, check out the developer blog and take a look at the documentation for a full list of webhook events.