Skip to content

Two-factor Authentication

Today we're adding two-factor authentication to GitHub.

When you enable this feature, it adds an additional layer of security to your account. When logging in to GitHub, after providing your username and password, you will be asked for a two-factor authentication code that is delivered to your mobile device via SMS or a free two-factor application. This additional step ensures that a malicious person who has discovered your password will not be able to log in to GitHub as you.

How do I enable it?

You can find a link in your account settings.

Settings link

You can find more information about setting up two-factor authentication on the documentation page.

Enabling this feature will affect more than just your login experience. Visit this help article to learn how two-factor authentication works with HTTPS Git, GitHub for Mac, GitHub for Windows, and the API.

How does it work on

After entering your username and password, you will be prompted for a two-factor authentication code.


This code can obtained from your mobile device through one of two methods:

After entering the code, you will be logged in.

How does it work for command-line Git?

If you are using SSH for Git authentication, rest easy: you don't need to do anything. If you are using HTTPS Git, instead of entering your password, enter a personal access token. These can be created by going to your application settings page.

Personal Access Tokens

How does it work in GitHub for Mac and GitHub for Windows?

After entering your username and password, you will be prompted for a two-factor authentication code.

GitHub for Mac GitHub for Mac

GitHub for Windows GitHub for Windows

What if I lose my mobile device?

We provide a number of recovery options, including recovery codes and backup SMS numbers. See this help article for more information.

Recovery Codes

Enjoy the newer, more-secure GitHub!

Explore what is Trending on GitHub

trending repositories-1

GitHub is a great place to find interesting projects. From the White House open data policy to Chicago bike routes, GitHub has become a place for collaboration on more than just code. Today we're making these interesting projects easier to find through the new trending page.

Time boxed by day, week, month

Eight times a day we calculate trending data into three time buckets: daily, weekly, and monthly. You can change the time periods by selecting one from the drop-down.


Filter by languages

You can also filter the trends by language. By default you will see trending items in any language.

You'll also see "unknown languages" as a filter. Our language library can't always determine the language for the repository, but that won't keep the repository from trending.

Next up, you will see languages that you find interesting based on your top starred repositories. If you haven't starred any repositories, you'll see trends based on the top languages on GitHub. Of course, we also provide a drop-down for all the rest of the languages.

Languages are always computed based on repositories. When on the repositories tab, you will see repositories with the primary language of the language filter you selected. When looking at the developers tab, you will see developers that have a trending repository in the selected language.


Trending Repositories


For each trending repository, you'll see the owner/repository name, primary language name, repository description, a star button, and a list of the top five contributors for the project.

Trending Developers


In all parts of these new pages, we showcase the smart people creating these great projects. On the developers tab, you'll find both developers and the organizations of developers that have trending repositories on GitHub.

Alongside each trending developer, we highlight their most popular repository.


What makes repositories or developers trend? We look at a variety of data points including stars, forks, commits, follows, and pageviews, weighting them appropriately. It's not just about total numbers, but also how recently the events happened.

Why isn't there more than one page? We want to surface just the top 25. Any more than that dilutes the effectiveness of trending and takes a lot to compute.

How can I see more? Try our search. You can do more interesting things than you think.

With 7.8 million projects, there's even more to explore on GitHub!

Checking out Pull Requests

For all of the pull request reviewers out there, we're excited to announce a new feature in GitHub for Mac and GitHub for Windows to make your lives easier!

On any pull request that you have permission to merge, you'll see this new button:

Check out this branch in GitHub for Mac

Clicking it will open GitHub for Mac or GitHub for Windows, clone the repository (if you don't have it), then automatically switch to the branch containing the changes.

Or, if the pull request was opened from a fork, we'll automatically create a local branch like pr/123:

Local pull request branch from a fork

Although changes can't be pushed back to the fork, this is still a handy way to test out a pull request locally.

Happy reviewing!

Cutting the GitHub Pages Gem

Building and testing GitHub Pages sites on your computer just got a whole lot easier with the release of the GitHub Pages Gem.

Running Jekyll (the engine that powers GitHub Pages) locally can be a big help when you'd like to preview a site on your computer before pushing changes, or if you are trying to diagnose a troubled build.

Starting today, you can bootstrap an environment that mirrors the GitHub Pages servers as closely as possible by simply running the command gem install github-pages from your project's directory.

Or if you've got Bundler installed, simply add gem 'github-pages' to a file named Gemfile in the project's root directory, then run the bundle install command.

Better yet, we're using the Gem here at GitHub, so as our servers update, you can more easily update your local environment, ensuring what you see on your computer matches what others see once the site is published. Just run gem update github-pages or bundle update github-pages and everything will be :sparkles:.

You can begin adding the Gem to your sites immediately, or for more information see the Using Jekyll with Pages help article.

Happy versioning! :gem: :gem: :gem:

Keep Your Email Private

Good news for folks who want to get their web-based GitHub Flow on while remaining cloaked in secrecy: Today we're :ship:ing the ability to make your email address private!

Until today, all web-based GitHub Flow used your primary email address. This included creating, editing, and deleting files, as well as merging pull requests.

But now you can keep your email address private. To do so, visit your email settings page:

email settings

With this turned on, web-based operations will use a email address.

Think of this as git config for the website. You should still use git config for configuring your email address for commits done via the command line, though. For more information, see the help document.

Big :thumbsup: to all the folks who suggested this feature, and happy [REDACTED] GitHubbing!

Code Search API

Humans have enjoyed our :sparkles: new code search for a while, and today we're ready to share that joy with the machines. :mag:

With the new code search API, we've taken the full power of GitHub's search and made it available in the API. You can search by file extension and language, filter by number of forks or stars, and use all the other search qualifiers you've come to know and love.


In addition to finding specific files that match your search, you often want to find the exact location of your search terms inside that file. On, we present code snippets for each file, and we highlight the matching text.


We want API consumers to have access to that information as well. The API provides the same snippets, along with metadata identifying the exact location of each matching search term.

Improved Search API for Repositories, Issues, and Users

Search isn't just about code. We're also launching a more powerful search API for repositories, issues, and users. With its more extensive set of query operators, and snippets showing the specific text that matched your search, you can quickly zero in on the items you're looking for.

For full details, check out the announcement on the Developer Blog.

Happy searching finding!

GitHub's on your phone

Today we’re excited to ship mobile web views on GitHub.


Repositories, Issues, Pull Requests, blobs, history views, and Pulse are now much easier to use from a phone.

GitHub is a great tool for building and shipping software, but most of that building still requires a laptop or desktop computer. Our phones, on the other hand, aren’t great for creating things but they’re perfect for browsing and reading content. That’s what we focused on with the mobile site.

Mobile web

We find ourselves using GitHub from our phones more every day. Instead of opening a native app, we are clicking through from other apps like Twitter, Facebook, or our email client. These are perfect situations to build a site optimized for mobile devices.


With the mobile site we’ve tried to make it easy to explore new repositories and keep up with repositories that we’re active in every day.

Less fancy, more fast

A responsive interface is one of the most important parts of creating a great user experience. Like we did with Repository Next, we’ve put a huge emphasis on speed with our mobile site. By using very little JavaScript and writing CSS and markup specifically for mobile, we were able to reduce page sizes dramatically and make the site feel very fast.


To check it out, visit on your phone and tap around.

Choosing an Open Source License

It’s easy to get caught up in code. Sharing your code isn’t everything, though: it’s also important to tell people how they can use that code.

Choosing an open source license can be confusing. We’ve created to help you make that decision.


You can see a breakdown of what’s required, what’s permitted, and what’s forbidden for each license:


When you’ve made your choice, copy it to your clipboard with one click:


Have any suggestions? itself is open source. Send us a Pull Request with your changes.

Licenses on

Now that we have all these licenses in one happy home, we want to help people choose their licenses on GitHub, too. When you create a new repository you’ll see a new license picker:


To get started, simply point your browser at, or for more information, you can dive into the full documentation. Happy licensing!

GitHub Flow in the Browser

Now that you can delete files directly on GitHub we’ve reached a very exciting milestone—the entire GitHub Flow™ is now possible using nothing but a web browser.

What is GitHub Flow?

A little while ago our very own @schacon wrote an article outlining the workflow we use here at GitHub to collaborate using Git. It’s a deceptively simple workflow, but it works brilliantly for us across a huge range of projects, and has adapted extremely well as our team has grown from being only a handful of people to our current size of 183 GitHubbers.

Since we use this workflow every day ourselves, we wanted to bring as many parts of the workflow to our web-based interface as possible. Here’s a quick outline of the how the GitHub Flow works using just a browser:

  1. Create a branch right from the repository.
  2. Create, edit, and delete files, rename them, or move them around.
  3. Send a pull request from your branch with your changes to kick off a discussion.
  4. Continue making changes on your branch as needed, updating the pull request automatically.
  5. Once the branch is ready to go, the pull request can be merged using the big green button.
  6. Branches can then be tidied up using the delete buttons in the pull request, or on the branches page.
  7. Repeat.

Even before some of these steps were possible in the browser, this simple workflow made it possible for us to iterate extremely quickly, deploy dozens of times each day, and address critical issues with minimal delay. Probably the most compelling aspect of GitHub Flow however is that there is no complicated branching model to have to wrap your head around.

Now that this workflow is available entirely via the web interface though, a whole new set of benefits start to emerge. Let’s dive into a few of them.

Lowering barriers to collaboration

Perhaps the most interesting consequence of having these tools available in the browser is that people don’t have to interact with Git or the command-line at all—let alone understand them—in order to contribute to projects in meaningful ways. This makes for a much easier learning curve for anyone new to Git and GitHub, whether they’re non-technical team members, or experienced developers learning something new.

Lowering barriers to learning

These web-based workflows have been especially helpful for our training team too. For some classes they’ve been able to have people begin learning the basic concepts of Git and GitHub using just the browser, saving students the complexity of installing Git and learning their way around the terminal commands until after they’ve got their heads around the fundamental ideas. When a browser is all you need, hallway demos and super-short classes can also more effectively convey the GitHub Flow to people in less time, and without the distractions of preparing computers with all the necessary software.

Less disruptive workflows

Even if you are a command-line wizard, there are always times when you just need to make a quick tweak to a project. Even if it’s just a single typetypo, doing this in the terminal requires a crazy number of steps. So now, instead of:

  • Switching contexts from your browser into your terminal.
  • Pulling down the code to work on.
  • Making the change.
  • Staging the change.
  • Committing the change.
  • Pushing the change.

…you can simply make the change right there without leaving your browser, saving you time and maintaining your zen-like frame of mind. What’s more, if you have any kind of continuous integration server set up to integrate with our Status API, you’ll even see that your typo fix built successfully and is ready to go!

Writing documentation

When editing Markdown files in repositories, being able to quickly preview how your change will look before you commit is very powerful. Combining that with things like the ability to easily create relative links between Markdown documents, and the availability of fullscreen zen mode for enhanced focus when composing content which isn’t code, the end result is a set of tools which make creating and maintaining documentation a real pleasure indeed.

Working with GitHub Pages websites

For projects that make use of GitHub Pages for their websites, tasks like writing new blog posts, or adding pages to an existing site are incredibly simple now that these workflows are possible in the browser. Whether you use Jekyll or just regular static HTML for your GitHub Pages site, these new workflows mean that you’re able to make changes using GitHub in your browser, have your site rebuilt and deployed automatically, and see your changes reflected live on <username> or your custom domain before you know it.

To learn more about building websites using GitHub Pages, you should check out these articles.

Get your GitHub Flow on!

In using them ourselves, we’ve found that these web-based workflows have come in handy on an increasingly regular basis, and we’re noticing real benefits from the reduced barrier to contributing. We hope you find these workflows useful too, and we can’t wait to see the interesting ways we know you’ll put them to good use.

Improved SVN Here to Stay, Old SVN Going Away

About a year and a half ago we announced Improved Subversion Client Support - an improvement to the original service that provided better write access, partial checkouts, and access to branches and tags using the Subversion trunk/branches/tags convention.

Now, it's time to shut down the old SVN support.

The old service is currently running on, and will be turned off on July 31. If you have any SVN checkouts of GitHub repositories from, you should recreate them using the new URL. Since only checked out the default (usually 'master') branch, you should change checkouts that use URLs like this:

To this:

Deleting files on GitHub

You know all those files you’ve been creating, editing, moving, and renaming? Well, you’ll be glad to know that you can now remove them using the web-based interface too! Simply view any file in your repository, click the delete button at the top, and commit the removal just like any other web-based edit.

Delete a file using GitHub

Commit removal of a file using GitHub

And just like that, :kissing::dash:, it’s gone.

For help with these features, be sure to read our help articles on creating, moving, renaming, and deleting files.

Note: Since it’s a version control system, Git always has your back if you need to recover the file later. If you really, really need to completely delete a file from a repository for some reason, say a secret key or other sensitive file that was accidentally commited, you may need to consider :skull::fire:the nuclear option:fire::skull:.

New History Tab in GitHub for Mac

Today, we're happy to announce an all-new look for the History tab in GitHub for Mac:

The new history tab

This new design has a far more efficient way of viewing your repository's history than its predecessor. Not only that, but it's fast. Really fast.

Specifically, we used libgit2 to massively improve the performance of diffs, and ReactiveCocoa to achieve a tab which loads faster and is more responsive than ever before.

This is just the first step in our new vision for GitHub for Mac. We can't wait to bring this level of awesomeness to the rest of the app.

Release Your Software

Today, we're excited to announce Releases, a workflow for shipping software to end users. Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:


Releases are accompanied by release notes and links to download the software or source code.


Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.


We recommend projects use Semantic Versioning, but it is not required.

Creating Releases

As a repository collaborator, you can draft up a changelog in a release's notes. Any non-production releases (alphas, betas, release candidates) can be identified through the pre-release checkbox.


You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.


Happy shipping! :ship:

GeoJSON rendering improvements

Nearly two weeks ago, we announced support for rendering geographic data. Today, we're excited to roll out several improvements:

  • GitHub now supports rendering TopoJSON, an extension of GeoJSON that encodes topology and can be up to 80% smaller than its GeoJSON equivalent.

  • Starting today, you don't have to rename geo files with a new extension. GitHub will now render GeoJSON (and TopoJSON) in all .geojson, .topojson, and .json files.

  • Complex geographic datasets can often be difficult to visualize, especially if points are grouped close together. We now automatically cluster nearby markers, allowing us to better support larger datasets.

Embed Support

Want to make your geoJSON map available someplace other than GitHub? Simply modify this template, and place it in any HTML page that supports javascript, such as GitHub Pages, and you'll have a beautiful, portable map:

<script src="<username>/<repo>/<ref>/<path_to_file>"></script>

For more information, including how to customize the embed code, see the help article Mapping geoJSON files on GitHub. Of course, you can always embed STL files as well.

Task Lists in Gist

Task Lists are a great way to organize and break down Issues and Pull Requests into small, feasible tasks. Naturally, we want to use Task Lists to track our personal endeavors, too.

Today we're happy to make Task Lists available in Gist.

Task Lists in your Gist

Task Lists work in any Markdown file in your Gist and in any comment. Read the docs for Task Lists in GitHub-flavored-Markdown for more information.

Something went wrong with that request. Please try again.