Skip to content

Adding a billing manager to your organization

With the new billing manager role, you can invite individuals to manage the billing details of your organization without giving them access to code. The new role enables a user to:

  • Upgrade or downgrade the organization’s plan.
  • Update payment details like the credit card on file.
  • View history of past transactions and download receipts.
  • Receive receipts via email.

Billing managers won’t:

  • Be able to create or access repositories in your organization.
  • See private members of your organization.
  • Be seen in the list of organization members.


Leave the payment details to your wonderful finance team, and get back to your code!

For more information on adding a billing manager to your organization, check out the help article.

CodeConf 2015: Speakers, Workshops and Hotel Discount

We thought you'd like a preview of what we have in store for CodeConf 2015 in June before discounted ticket sales end on May 25th. We're beyond excited to be welcoming speakers from all over the globe and from companies and organizations of all sizes, who work on every facet of open source technology and represent many different parts of the community. Here's a sneak peak at some of the excellent speakers who will be presenting at CodeConf this year:

  • Eric Levine of Airbnb
  • Casey Rosenthal of Netflix
  • Christine Abernathy of Facebook
  • Corinne Warnshuis of Girl Develop It

This is just a sampling of the amazing line-up. Check out the full preview over at the CodeConf site.

But wait there's more!

  • Reserve a spot in one of our hands-on workshops led by expert trainers. Space is limited, so register early.
  • Join us the evening before the conference to enjoy the company of the Nashville open source community and grab your badge early. You won't want to miss the food from legendary Hattie B's.
  • Register for a discounted room at the Gaylord Opryland Hotel. Shuttles will depart at convenient intervals so you can easily get to and from the conference. By booking a room at the Opryland instead of a downtown hotel, you save about $100.
  • There are still a few sponsorship opportunities left, including our scholarship program. Check out the prospectus and drop us a line at
  • Find more details about everything we have in store for you on the new

Lastly, we'd like to thank everyone who took the time to send us their ideas. We were overwhelmed by the quality and creativity of the 300+ proposals submitted. You are the heart of CodeConf.

Ticket prices go up to $399 on May 25th and we can't wait to see you in Nashville, so what are you waiting for?

Celebrate Pride with GitHub

Pride week is coming early to GitHub! We're throwing two LGBTQ-focused events on Tuesday June 2nd and Wednesday June 3rd, and will also be launching our 2015 Pridetocat shirt.


  • Tuesday June 2nd
  • 6:30pm-9:30pm
  • GitHub HQ, 88 Colin P. Kelly Jr. St, San Francisco

Join us for a special LGBTQ edition of Patchwork! No coding experience is needed to participate in this free hands-on workshop with support and talks from GitHubbers and Teagan Widmer from Refuge Restrooms. All LGBTQ folks welcome.

Register yourself here, or learn more about our Patchwork events.

Pride Celebration

  • Wednesday June 3rd
  • 6:00pm-9:00pm
  • GitHub HQ, 88 Colin P. Kelly Jr. St, San Francisco

We're hosting a celebration of the great things happening in the LGBTQ tech community! Celebrate Pride with old friends, make new ones, and learn about some amazing initiatives from organizations like Trans*H4CK, Lesbians Who Tech, Maven, GaymerX, and oSTEM!

We will also be launching our 2015 Pridetocat shirts, which will be available on site, with all proceeds going to Trans*H4CK, Lesbians Who Tech, and Maven.

Register now to attend! Open to all LGBTQ-identified folks and allies.

GitHub Enterprise, now on AWS GovCloud

GitHub is used by government agencies to collaborate on all sorts of interesting things, from software that aids first responders to White House policy, but sometimes agencies require a level of assurance that can only be afforded by a platform running on their own infrastructure.

Starting with version 2.2.2, released yesterday, AMIs for GitHub Enterprise, GitHub's self-hosted offering, are available in the AWS GovCloud (US) region, allowing US customers with specific regulatory requirements to run GitHub Enterprise in a federally compliant cloud environment.

What is GovCloud?

GovCloud is an isolated Amazon Web Services environment used by US government agencies at the federal, state, and local levels, along with contractors, researchers, educational institutions, and other US customers.

In terms of boxes checked, GovCloud has received a federal authority to operate (ATO), and conforms with U.S. International Traffic in Arms Regulations (ITAR) restrictions, Federal Risk and Authorization Management Program (FedRAMP) requirements, and Department of Defense (DoD) Cloud Security Model (CSM) Levels 3-5.

Getting started

You can begin using GitHub Enterprise in GovCloud today by requesting a free, 45-day trial, and customers that are already using GitHub Enterprise can migrate from other GitHub Enterprise deployment platforms to GovCloud by following these instructions.

If you have any questions about using GitHub in GovCloud, or GitHub + Government in general, please visit the AWS GovCloud page, or feel free to reach out to at any time — we'd love to hear from you.

Happy (compliant) collaborating!

New Atom Shirt in the Shop

Prepare yourself for the future with the new Atom shirt and Atom Coasters.

Atom Shirt

Atom Coasters

Available in the GitHub Shop

The GitHub Engineering Blog

We are happy to introduce GitHub's Engineering Blog to the world. Starting today, you can read details about our infrastructure, learn about our development practices, and hear about the knowledge we've gained while running the world's largest code collaboration platform.

You can also get updates by following our Engineering Twitter account @GitHubEng.

Happy reading!

Git Merge 2015: Session Videos Now Available


On April 8-9, Git Merge returned to Europe, this time to La Gaite Lyrique in Paris. Over 200 people attended to celebrate ten years of Git, and with your help we raised over $15,000 in ticket sales, which was then donated entirely to the Software Freedom Conservancy.

Head over to to check out recorded sessions from expert speakers representing Google, Microsoft, SAP, Twitter, GitHub, Atlassian, and Amazon. These excellent talks focus on how teams use Git, as well as the implementation challenges of large Git deployments.

Thanks to everyone who attended! Make sure to follow @github on Twitter for announcements about Git Merge 2016.

New Octicons Shirt in the Shop

We love all the awesome little Octicons. Now you can wear Octicons...tons of Octicons!

Octicons Shirts

Available in the GitHub Shop

GitHub + Jupyter Notebooks = <3

Communicating ideas that combine code, data and visualizations can be hard, especially if you're trying to collaborate in realtime with your colleagues.

Whether you're a researcher studying Wikipedia, an astronomer investigating the movements of galaxies in our cosmic neighborhood or a data-scientist at fashion retailer Stitch Fix, producing insights from data and sharing is a common challenge.

Jupyter notebooks solve this problem by making it easy to capture data-driven workflows that combine code, equations, text and visualizations and share them with others. From today Jupyter notebooks render in all their glory right here on GitHub.

Jupyter Notebook toggle

With Git Large File Storage and Jupyter notebook support, GitHub has never been a better place to version and collaborate on data-intensive workflows. With more than 200,000 Jupyter notebooks already on GitHub we're excited to level-up the GitHub-Jupyter experience.

Looking to get started? Simply commit a .ipynb file to a new or existing repository to view the rendered notebook. Alternatively if you're looking for some inspiration then check out this incredible gallery of Jupyter notebooks.

Atom 1 Year Open Source Anniversary

One year ago today, Atom went from private alpha to open source software in hopes that the sunshine would help it reach its true potential.

Thanks to you, our users and contributors, Atom has had an incredible year. The number of contributors has skyrocketed, and with your support, the Atom team has hurdled significant technical challenges. Every day, the editor gets better, and its performance and stability improves. Take a look at how far Atom has come:


The future

With the help of many developers around the world, Atom 1.0 is in sight. We have been rapidly knocking items off of our 1.0 feature list, and plan on releasing 1.0 next month. It's been a very exciting year, and we look forward to many more as the Atom community grows.


Releases metadata for GitHub Pages

Last year, we exposed repository and organization metadata to help you showcase your open source efforts on GitHub Pages. We're adding releases metadata to that list, allowing you to more easily display information about your project's latest version (including release notes) and link directly to download the most recent releases.

Releases are exposed in the site.github.releases namespace within Jekyll, and contain all the information exposed through the releases API. For more information, see the Repository metadata on GitHub Pages help article.

Happy releasing!

Exporting Your Organization Audit Log

The Organization audit log allows you to quickly review actions performed by members of your organization on GitHub. You may need to look for specific activity or even through your organization's entire audit log to help aid in legal cases or keep record of suspicious activity.

To do just that, you now have the tools to export your organization's audit log in either JSON or CSV format.

Audit log export

Improving the GitHub workflow for the Microsoft Community

At Microsoft Build 2015, we announced deep GitHub integration in Visual Studio 2015, along with GitHub Enterprise 2.2.0. This release will help developers who work with the Microsoft stack make GitHub Enterprise a seamless part of their existing workflow. If you'd prefer to skip the summary, you can see a full list of new features in the release notes. If you're interested in the highlights, read on.

GitHub Enterprise now supported on Hyper-V and available on Microsoft Azure

It's important to be able to deploy and run GitHub Enterprise wherever you want. If your team works on the Microsoft stack, we have great news. With the 2.2.0 release, you can now host GitHub Enterprise in the Windows ecosystem using Hyper-V for local hosting or Azure for cloud hosting.

Powerful Collaboration - GitHub Enterprise

To request a 45-day trial of GitHub Enterprise on Azure just let us know.

GitHub Extension for Visual Studio

The new GitHub Extension for Visual Studio lets you work on GitHub repositories within Visual Studio 2015. Once you download the latest version of Visual Studio, you can log in to GitHub, clone and create repositories, and publish your local work without leaving your IDE. To see a walkthrough of the features, check out this video on Microsoft's Channel 9.


Microsoft Developer Assistant

In case you missed it, Microsoft also announced the availability of the Microsoft Developer Assistant for Visual Studio 2015—a way for developers to search for code on from Visual Studio. Just enter your query and you will see links to public code on, along with information about the project.

Wait, there’s more!

Beyond the Microsoft integration you’ll find lots more to like in Enterprise 2.2.0 including:

  • PDF rendering
  • Mobile web notifications
  • Quick pull requests
  • Xen hypervisor support

For a full list of what’s new, check out the release notes.

If you already use GitHub Enterprise, you can download the latest release from

If you are attending Build 2015 and want to learn more, visit the GitHub booth on the third floor.

Eight lessons learned hacking on GitHub Pages for six months

Believe it or not, just over a year ago, GitHub Pages, the documentation hosting service that powers nearly three-quarters of a million sites, was little more than a 100-line shell script. Today, it's a fully independent, feature-rich OAuth application that effortlessly handles well over a quarter million requests per minute. We wanted to take a look back at what we learned from leveling up the service over a six month period.

What's GitHub Pages

GitHub Pages is GitHub's static-site hosting service. It’s used by government agencies like the White House to publish policy, by big companies like Microsoft, IBM, and Netflix to showcase their open source efforts, and by popular projects like Bootstrap, D3, and Leaflet to host their software documentation. Whenever you push to a specially named branch of your repository, the content is run through the Jekyll static site generator, and served via its own domain.

Eating our own ice cream

At GitHub, we're a big fan of eating our own ice cream (some call it dogfooding). Many of us have our own, personal sites hosted on GitHub Pages, and many GitHub-maintained projects like Hubot and Electron, along with sites like, take advantage of the service as well. This means that when the product slips below our own heightened expectations, we're the first to notice.

We like to say that there's a Venn diagram of things that each of us are passionate about, and things that are important to GitHub. Whenever there's significant overlap, it's win-win, and GitHubbers are encouraged to find time to pursue their passions. The recent improvements to GitHub Pages, a six-month sprint by a handful of Hubbers, was one such project. Here's a quick look back at eight lessons we learned:

Lesson one: Test, test, and then test again

Before touching a single line of code, the first thing we did was create integration tests to mimic and validate the functionality experienced by users. This included things you might expect, like making sure a user's site built without throwing an error, but also specific features like supporting different flavors of Markdown rendering or syntax highlighting.

This meant that as we made radical changes to the code base, like replacing the shell script with a fully-fledged Ruby app, we could move quickly with confidence that everyday users wouldn't notice the change. And as we added new features, we continued to do the same thing, relying heavily on unit and integration tests, backed by real-world examples (fixtures) to validate each iteration. Like the rest of GitHub, nothing got deployed unless all tests were green.

Lesson two: Use public APIs, and when they don't exist, build them

One of our goals was to push the Pages infrastructure outside the GitHub firewall, such that it could function like any third-party service. Today, if you view your OAuth application settings you'll notice an entry for GitHub Pages. Internally, we use the same public-facing Git clone endpoints to grab your site's content that you use to push it, and the same public-facing repository API endpoints to grab repository metadata that you might use to build locally.

For us, that meant adding a few public APIs, like the inbound Pages API and outbound PageBuildEvent webhook. There's a few reasons why we chose to use exclusively public APIs and to deny ourselves access to "the secret sauce". For one, security and simplicity. Hitting public facing endpoints with untrusted user content meant all page build requests were routed through existing permission mechanisms. When you trigger a page build, we build the site as you, not as GitHub. Second, if we want to encourage a strong ecosystem of tools and services, we need to ensure the integration points are sufficient to do just that, and there's no better way to do that than to put your code where your mouth is.

Lesson three: Let the user make the breaking change

Developing a service is vastly different than developing an open source project. When you're developing a software project, you have the luxury of semantic versioning and can implement radical, breaking changes without regret, as users can upgrade to the next major version at their convenience (and thus ensure their own implementation doesn't break before doing so). With services, that's not the case. If we implement a change that's not backwards compatible, hundreds of thousands of sites will fail to build on their next push.

We made several breaking changes. For one, the Jekyll 2.x upgrade switched the default Markdown engine, meaning if users didn't specify a preference, we chose one for them, and that choice had to change. In order to minimize this burden, we decided it was best for the user, not GitHub, to make the breaking change. After all, there's nothing more frustrating than somebody else "messing with your stuff".

For months leading up to the Jekyll 2.x upgrade users who didn't specify a Markdown processor would get an email on each push, letting them know that Maruku was going the way of the dodo, and that they should upgrade to Kramdown, the new default, at their convenience. There were some pain points, to be sure, but it's preferable to set an hour aside to perform the switch and verify the output locally, rather than pushing a minor change, only to find your entire site won't publish and hours of frustration as you try to diagnose the issue.

Lesson four: In every communication, provide an out

We made a big push to improve the way we communicated with GitHub Pages users. First, we began pushing descriptive error messages when users' builds failed, rather than an unhelpful "page build failed" error, which would require the user to either build the site locally or email GitHub support for additional context. Each error message let you know exactly what happened, and exactly what you needed to do to fix it. Most importantly, each error included a link to a help article specific to the error you received.

Errors were a big step, but still weren't a great experience. We wanted to prevent errors before they occurred. We created the GitHub Pages Health Check and silently ran automated checks for common DNS misconfigurations on each build. If your site's DNS wasn't optimally configured, such as being pointed to a deprecated IP address, we'd let you know before it became a problem.

Finally, we wanted to level up our documentation to prevent the misconfiguration in the first place. In addition to overhauling all our GitHub Pages help documentation, we reimagined as a tutorial quick-start, lowering the barrier for getting started with GitHub Pages from hours to minutes, and published a list of dependencies, and what version was being used in production.

This meant that every time you got a communication from us, be it an error, a warning, or just a question, you'd immediately know what to do next.

Lesson five: Optimize for your ideal use case, not the most common

While GitHub Pages is used for all sorts of crazy things, the service is all about creating beautiful user, organization, and project pages to showcase your open source efforts on GitHub. Lots of users were doing just that, but ironically, it used to be really difficult to do so. For example, to list your open source projects on an organization site, you'd have to make dozens of client-side API calls, and hope your visitor didn't hit the API limit, or leave the site while they waited for it to load.

We exposed repository and organization metadata to the page build process, not because it was the most commonly used feature, but because it was at the core of the product's use case. We wanted to make it easier to do the right thing — to create great software, and to tell the world about it. And we've seen a steady increase in open source marketing and showcase sites as a result.

Lesson six: Successful efforts are cross-team efforts

If we did our job right, you didn't notice a thing, but the GitHub Pages backend has been completely replaced. Whereas before, each build would occur in the same environment as part of a worker queue, today, each build occurs in its own Docker-backed sandbox. This ensured greater consistency (and security) between builds.

Getting there required a cross-team effort between the GitHub Pages, Importer, and Security teams to create Hoosegow, a Ruby Gem for executing untrusted Ruby code in a disposable Docker sandbox. No one team could have created it alone, nor would the solution have been as robust without the vastly different use cases, but both products and the end user experience are better as a result.

Lesson seven: Match user expectations, then exceed them

Expectations are a powerful force. Everywhere on GitHub you can expect @mentions and emoji to "just work". For historical reasons, that wasn't the case with GitHub Pages, and we got many confused support requests as a result. Rather than embark on an education campaign or otherwise go against user expectations, we implemented emoji and @mention support within Jekyll, ensuring an expectation-consistent experience regardless of what part of GitHub you were on.

The only thing better than meeting expectations is exceeding them. Traditionally, users expected about a ten to fifteen minute lag between the time a change was pushed and when that change would be published. Through our improvements, we were able to significantly speed up page builds internally, and by sending a purge request to our third-party CDN on each build, users could see changes reflected in under ten seconds in most cases.

Lesson eight: It makes business sense to support open source

Jekyll may have been originally created to power GitHub Pages, but since then, it has become its own independent open source project with its own priorities. GitHubbers have always been part of the Jekyll community, but if you look at the most recent activity, you'll notice a sharp uptick in contributions, and many new contributors from GitHub.

If you use open source, whether it's the core of your product or a component that you didn't have to write yourself, it's in your best interest to play an active role in supporting the open source community, ensuring the project has the resources it needs, and shaping its future. We've started "open source Fridays" here at GitHub, where the entire company takes a break from the day-to-day to give back to the open source community that makes GitHub possible. Today, despite their beginnings, GitHub Pages needs Jekyll, not the other way around.

The numbers

Throughout all these improvements, the number of GitHub Pages sites has grown exponential, with just shy of a three-quarters of a million user, organization, and project sites being hosted by GitHub Pages today.

GitHub Pages sites over time

But the number of sites tells only half the story. Day-to-day use of GitHub Pages has also seen similar exponential growth over the past three years, with about 20,000 successful site builds completing each day as users continuously push updates to their site's content.

GitHub Pages builds per day

Last, you'll notice that when we introduced page build warnings in mid-2014, to proactively warn users about potential misconfigurations, users took the opportunity to improve their sites, with the percentage of failed builds (and number of builds generating warnings) decreasing as we enter 2015.

GitHub Pages is a small but powerful service tied to every repository on GitHub. Deceivingly simple, I encourage you to create your first GitHub Pages site today, or if you're already a GitHub Pages expert, tune in this Saturday to level up your GitHub Pages game.

Happy publishing!

CodeConf 2015: Early Bird Tickets and Call for Proposals

codeconf header 1

CodeConf 2015, GitHub's premiere open source event, will take place on June 25-26 in Tennessee. We hope you'll join us for what is sure to be a special community experience at the Bell Tower, in the heart of downtown Nashville.

We're pleased to announce that CodeConf is accepting proposals for talks beginning today. For guidelines around submissions, please take a look at the detailed form. The call for proposals ends May 10th at 11:59pm PDT.

CodeConf is dedicated to amplifying new voices from the amazing open source community. We will feature thoughtful and compelling sessions that will leave all attendees thinking differently about the open source ecosystem. We will also be celebrating the unique American city of Nashville by featuring local cuisine and artists throughout the conference. CodeConf will culminate in a party at the historic Country Music Hall of Fame, only a few blocks away from the Bell Tower.

Get your early bird ticket now!. On May 25, ticket sales will increase by $100. Follow @codeconf on Twitter for regular updates on content, training sessions, and more.

Come with an open mind, and leave a better contributor.

Something went wrong with that request. Please try again.