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

Announcing Git Large File Storage (LFS)

Distributed version control systems like Git have enabled new and powerful workflows, but they haven't always been practical for versioning large files. We're excited to announce Git Large File Storage (LFS) as an improved way to integrate large binary files such as audio samples, datasets, graphics, and videos into your Git workflow.

Git LFS is a new, open source extension that replaces large files with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.


Git LFS is easy to download and configure, works on all major platforms, and is open sourced under the MIT license.

Early access to Git LFS support on GitHub.com

We're ready to roll out Git LFS support to a select group of users. If you'd like to be one of the first to try it out on GitHub.com, sign up for early access using your GitHub account.

In the next few months, every repository on GitHub.com will support Git LFS by default.


Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file storage and a monthly bandwidth quota of 1 GB. If your workflow requires higher quotas, you can easily purchase more storage and bandwidth for your account.

Want to start working with large files on GitHub.com? Sign up for early access.

Create Pull Requests in GitHub for Windows

Just like our Mac client, you can now use GitHub for Windows to submit pull requests to GitHub or GitHub Enterprise, right from your desktop.

Create a pull request

We didn't forget forks, either! If you fork a repository and then want to contribute changes to the upstream repository, GitHub for Windows will keep track of upstream branches. This means less hassle when you're ready to contribute your changes back.

Upstream branches

Download GitHub for Windows and start sending pull requests now!

The new face of committing in GitHub for Mac

We’ve just redesigned GitHub for Mac’s Changes tab to make it even easier to review lots of changes, and to see what will be shared before clicking Sync:

A long list of changes in GitHub for Mac A long list of unsynced commits in GitHub for Mac

This means that you can focus solely on what’s most important to you: your changes.

We’ve also simplified and improved the process for fixing up a commit you’ve just made. Just click the “Undo” button in the pane that appears:

Recent commit pane with Undo button

And if you don’t want to worry about manually syncing your changes after committing, you can enable “Automatically Sync after Committing” from the Edit menu:

Automatically Sync after Committing in the Edit menu

This is yet another step toward our grand vision for GitHub for Mac, with plenty more to come, so give it a shot! If you already have GitHub for Mac installed, it will update itself to the latest version automatically.

As always, we’d love to know what you think. If you have any comments, questions or bug reports, please let us know.

Git 2.3 has been released

The Git developers have just released a major new version of the Git command-line utility, Git 2.3.0.

As usual, this release contains many improvements, performance enhancements, and bug fixes. Full details about what's included can be found in the Git 2.3.0 release notes, but here's a look at what we consider to be the coolest new features in this release.

Push to deploy

One way to deploy a Git-based web project is to keep a checked-out working copy on your server. When a new version is ready, you log into the server and run git pull to fetch and deploy the new changes. While this technique has some disadvantages (see below), it is very easy to set up and use, especially if your project consists mostly of static content.

With Git 2.3, this technique has become even more convenient. Now you can push changes directly to the repository on your server. Provided no local modifications have been made on the server, any changes to the server's current branch will be checked out automatically. Instant deploy!

To use this feature, you have to first enable it in the Git repository on your server by running

$ git config receive.denyCurrentBranch updateInstead

When shouldn't you use push-to-deploy?

Deploying by pushing to a Git repository is quick and convenient, but it is not for everybody. For example:

  • Your server will contain a .git directory containing the entire history of your project. You probably want to make extra sure that it cannot be served to users!
  • During deploys, it will be possible for users momentarily to encounter the site in an inconsistent state, with some files at the old version and others at the new version, or even half-written files. If this is a problem for your project, push-to-deploy is probably not for you.
  • If your project needs a "build" step, then you will have to set that up explicitly, perhaps via githooks.

See how this feature was implemented

Faster cloning by borrowing objects from existing clones

Cloning a remote repository can involve transferring a lot of data over the network. But if you already have another local clone of the same repository, it probably already has most of the history that the new clone will need. Now it is easy to use those local objects rather than transferring them again:

$ git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git

The new --dissociate option tells Git to copy any objects it can from local repository ../oldclone, retrieving the remainder from the remote repository. Afterwards, the two clones remain independent; either one can be deleted without impacting the other (unlike when --reference is used without --dissociate).

See how this feature was implemented

More conservative default behavior for git push

If you run git push without arguments, Git now uses the more conservative simple behavior as the default. This means that Git refuses to push anything unless you have defined an "upstream" branch for your current branch and the upstream branch has the same name as your current branch. For example:

$ git config branch.autosetupmerge true
$ git checkout -b experimental origin/master
Branch experimental set up to track remote branch master from origin.
Switched to a new branch 'experimental'
$ git commit -a -m 'Experimental changes'
[experimental 43ca356] Experimental changes
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:master

To push to the branch of the same name on the remote, use

    git push origin experimental


The new default behavior is meant to help users avoid pushing changes to the wrong branch by accident. In the case above, the experimental branch started out tracking master, but the user probably wanted to push the experimental branch to a new remote branch called experimental. So the correct command would be git push origin experimental.

The default behavior can be changed by configuring push.default. If you want to go back to the version 1.x behavior, set it to matching:

$ git config --global push.default matching

See how this feature was implemented

More flexible ssh invocation

Git knows how to connect to a remote host via the SSH protocol, but sometimes you need to tweak exactly how it makes the connection. If so, you can now use a new shell variable, GIT_SSH_COMMAND, to specify the command (including arguments) or even an arbitrary snippet of Shell code that Git should use to connect to the remote host. For example, if you need to use a different SSH identity file when connecting to a Git server, you could enter

$ GIT_SSH_COMMAND='ssh -i git_id' git clone host:repo.git

See how this feature was implemented

The credential subsystem is now friendlier to scripting

When Git needs a password (e.g., to connect to a remote repository over http), it uses the credential subsystem to query any helpers (like the OS X Keychain helper), and then finally prompts the user on the terminal. When Git is run from an automated process like a cron job, there is usually no terminal available and Git will skip the prompt. However, if there is a terminal available, Git may hang forever, waiting for the user to type something. Scripts which do not expect user input can now set GIT_TERMINAL_PROMPT=0 in the environment to avoid this behavior.

See how this feature was implemented


Some other useful tidbits:

  • Now Git is cleverer about not rewriting paths in the working tree unnecessarily when checking out particular commits. This will help reduce the amount of redundant work done during software builds and reduce the time that incomplete files are present on the filesystem (especially helpful if you are using push-to-deploy). See how this feature was implemented
  • Now git branch -d supports a --force/-f option, which can be used to delete a branch even if it hasn't been merged yet. Similarly, git branch -m supports --force/-f, which allows a branch to be renamed even if the new name is already in use. This change makes these commands more consistent with the many other Git commands that support --force/-f. See how these features were implemented

Additional resources

Don't forget: an important Git security vulnerability was fixed last December. If you haven't upgraded your Git client since then, we recommend that you do so as soon as possible. The new release, 2.3.0, includes the security fix, as do the maintenance releases, 1.9.5, 2.0.5, and 2.1.4, which were released in December.

Announcing GitHub Enterprise 2.1.0


It's a new year and we couldn't think of a better way to start it off than with a new release of GitHub Enterprise. We've included a number of highly-requested features, along with some of the best stuff recently shipped on GitHub.com - all to give developers and admins the best tools to build and ship software at work.

Let's talk about some of the features you'll find in this release.

Automate user and team management with LDAP Sync

Many of you have told us that you want it to be easier to use GitHub Enterprise with LDAP, especially for organizations managing lots of users. With this release, GitHub Enterprise integrates with your LDAP directory more deeply than ever before, automating identity and access management for your organization. This means you can provision and deprovision user accounts in GitHub Enterprise directly from LDAP with user sync, and automatically grant users access to repositories with team sync. While we were at it, we also improved LDAP performance across the board, increasing reliability and throughput.

Deploy GitHub Enterprise on OpenStack KVM

One of our goals with last year's rebuild of GitHub Enterprise was to make it available in more of the environments where you want to run it, whether you're managing your infrastructure on servers you own or on an internal cloud-based platform. That's why we're excited to announce that with this release, GitHub Enterprise is available on OpenStack KVM, in addition to Amazon Web Services and VMware. If your tech stack is built on KVM, you can now easily set up GitHub Enterprise and integrate with other parts of your internal system.

Audit all user actions across your instance

The Organization Audit Log that shipped with the November release of GitHub Enterprise has now been expanded to the instance level, giving administrators a skimmable and searchable record of every action performed across GitHub Enterprise in the past 90 days. Events like repository creation, team deletion, the addition of webhooks, and more are surfaced in a running log, along with information about who performed the action and when it occurred. These events can be filtered for deeper analysis, and you can create a wide range of custom search queries to make sure you're always aware of what's taking place on your instance.


Monitor the performance of GitHub Enterprise

If you're administering GitHub Enterprise, you should be able to identify whether your instance is performing correctly and quickly locate what's wrong when it isn't. With the new Instance Monitoring Dashboard, you now can. With data displayed for things like data disk usage, memory, CPUs, and more, you'll be able to answer questions like:

  • Are my users experiencing errors?
  • Are things fast or slow for my users?
  • What is a typical traffic pattern? What is abnormal?
  • Should I upgrade CPU, memory, or IO to improve the performance of my instance?
  • When should I plan to increase my disk space given my current growth rate?


Even more betterness

GitHub Enterprise 2.1.0 also includes:

To see the full list of features and bug fixes, check out the release notes for GitHub Enterprise 2.1.0.

Take 2.1.0 for a spin

If you're an existing GitHub Enterprise customer, you can download the latest release from the GitHub Enterprise website. If you want to give GitHub Enterprise a try, start a 45-day free trial on OpenStack KVM, AWS, or VMware.

Organization-approved applications

Applications integrate with GitHub to help you and your team build, test, and deploy software. But not all apps are created equal. By adopting a list of approved applications, organization admins can better manage which apps can be given access to their organization's data.

Approve trusted applications

If you're administering an organization on GitHub.com, you can set up a whitelist of trusted third-party applications.


With this protection in place, all applications need your explicit approval before they can access your organization's resources. You can grant access to your favorite continuous integration service (for example), while ignoring other applications that you may not trust or need.

Request your favorite tools

If you're a member of an organization and have a third-party application that you want to use, simply ask your organization's admins to approve access. They can then review the requested application to decide whether it should have access to your organization's data.


For more information on setting up a list of approved applications for your organization, be sure to check out the docs.

If you develop an app that integrates with GitHub, check out the Developer Blog for our latest recommendations on working with organizations and their data.

Create Pull Requests with GitHub for Mac

Pull requests are fantastic. We use them every day to review and discuss code, documentation, and designs. Now you can create pull requests without leaving the warm embrace of GitHub for Mac.

Create pull requests

We've also made forks easier to work with. Forked repositories now automatically fetch their upstream repository, and its branches can be checked out or merged. No more futzing with the command line or multiple remotes!

Check out the upstream's branch

Download GitHub for Mac and start sending pull requests!

Quick Pull Requests

Starting conversations around changes is what pull requests and GitHub Flow are all about, so we’re excited to introduce a powerful shortcut that gets you there even faster.

When using your browser to edit a file on GitHub.com, the web-based commit composer lets you quickly propose a change to a new branch and then immediately open a pull request for discussion and review:

Selecting the new branch option to open a quick pull request

Reducing the time it takes to open a pull request lowers the contribution barrier, and having this workflow available entirely within the browser makes collaboration more approachable for people with all technical skill levels.

To learn how GitHub Flow works, and whether it might be a good workflow to use on your projects, check out our guide on Understanding GitHub Flow.

Syntax Highlighted Diffs

Unified and split diffs now feature syntax highlighting, which adds colors to your code to make its meaning and structure clearer. Now you can more easily understand the code that was changed in a commit, pull request, or review comment.

A diff with and without syntax highlighting

See it in action at dotnet/corefx or your favorite repository.

See results from all pull request status checks

Since we introduced the Status API, you've been able to improve the quality of your code by including the status of a pull request within the conversation timeline, for every push. Before today, you've only been able to see results from one service. Now you can see all your results at once, from multiple CI systems that test your code against different platforms to simultaneous security testing and code coverage analysis.

screenshot of status area with a few statuses

You can also see how the status of a pull request has changed over its history by clicking the icons listed next to individual commits.

screenshot of a commit with multiple statuses

If you're interested in how to set up your own statuses, take a look at our Status API docs along with this guide to building your own CI service. You can also check out some the services that use the Status API to help you keep your code clean, confirm your tests are passing, and make sure contributors have agreed to your CLA.

Introducing organization webhooks

Webhooks are now available at the organization level on GitHub.com. Organization webhooks send events for all repositories in an organization. They also include new events for repository creation, team membership, and more.

org hooks

If you're extending GitHub into your internal systems, organization webhooks save you time by helping you configure integrations across multiple repositories in one place. The addition of organizational-level events, like team membership, open up new possibilties for integrators building applications that work with GitHub.

For all the details, check out our updated webhook developer guide.

GitHub Pages legacy IP brownout

This week we will be conducting a "brownout" of all misconfigured GitHub Pages sites. If your GitHub Pages site's DNS is pointed at an out-of-date IP address, we will intermittently serve a warning page in place of your site's content. We will update our status site before we do so, and normal functionality will resume at the conclusion of the brownout.

If you use a custom domain with GitHub Pages, please verify that your domain's DNS settings are properly configured to point to the most up-to-date GitHub IP addresses. This will ensure that your site remains available this week and continues to remain available after December 1st, 2014.

For information on how to tell if your site is affected and what to do to fix it, see the original GitHub Pages Legacy IP Deprecation announcement or the setting up a custom domain with GitHub Pages documentation.

Of course, if you have any questions, we're here to help.

A faster, more flexible GitHub Enterprise

jetpack octocat

Today, we’re releasing an all-new GitHub Enterprise designed to make it even easier for developers and businesses around the world to use GitHub at work.

Now available on Amazon Web Services (AWS)

Since GitHub Enterprise launched in 2011, AWS's popularity has grown. Many companies want to host code in their AWS-powered cloud and with good reason. Using AWS reduces hardware costs, provides immediate access to a highly scalable infrastructure, and addresses a wide variety of compliance standards, from healthcare's HIPAA standards to government's FedRAMP. And now you can run GitHub Enterprise on AWS too! We like to think it feels a little bit like this:

Infrastructure improvements, high availability, & backups

We've rewritten the infrastructure behind GitHub Enterprise, improving stability and redundancy regardless of how you choose to deploy it. Some highlights:

  • GitHub Enterprise now utilizes Ubuntu 12.04 LTS, taking advantage of long-term updates and security fixes for the base components provided by Ubuntu.
  • Online backup utilities give you a number of advanced capabilities for backing up and restoring your data. With these utilities your appliance doesn't need to be put in maintenance mode for the duration of the backup run, meaning there's no downtime for your development team.
  • Achieving redundancy with GitHub Enterprise is much easier. With replication mode enabled, you can configure a second, identical instance (failover with warm standby) to jump into action should anything happen to your primary instance.

HA/DR image

SAML support & security audit log

With our improved organization audit log, admins can now see a running list of events as they're generated across each organization and search for specific activities performed by users. This data provides your company with better security insights and gives you the ability to audit account, team, and repository access over time as needed.


We've also added support for SAML, including OneLogin, PingIdentity, Okta, and Shibboleth. Single sign-on with these identity providers allows you to manage your organization's users from one place or manage app access for groups of users at a time, rather than individually.

...and more!

This release also includes a number of features to help your company build and ship high-quality software, including:

To see a full list of features, check out the release notes for GitHub Enterprise 2.0.0.

Give GitHub Enterprise a whirl

If you're an existing GitHub Enterprise customer, you can download the latest release from the Enterprise website. If you want to give GitHub Enterprise a try, you can start a 45-day free trial on AWS or VMware.

Come visit us at AWS re:Invent

We’ll be demoing the all-new GitHub Enterprise this week at AWS re:Invent in Las Vegas. Stop by booth #1229 to say hi, check out this release in action, and grab some stickers and other great stuff. If you're attending re:Invent and would like a more in depth look at how this release of GitHub Enterprise might help your company, sign up for a meeting with our GitHub Enterprise sales team.

GitHub Pages Legacy IP Deprecation

Update: We've extended the deprecation deadline to February 2, 2015 to give Pages users more time to update their DNS records.

If you use a custom domain with GitHub Pages, please verify that your domain's DNS settings are properly configured to point to the most up-to-date GitHub IP addresses. This will ensure that your site remains available after December 1st, 2014.

GitHub Pages allows you to set up a custom domain by adding the domain to a CNAME file, and pointing your domain's DNS record to GitHub's servers. If you don't use this feature, for example, if your GitHub Pages site is published as username.github.io, you don't need to take any action at this time. Please enjoy this animated GIF for being awesome.

Why the change?

Nearly a year ago, we announced improvements to how we serve GitHub Pages sites. Today we're making that change permanent by deprecating our old GitHub Pages infrastructure. If your custom domain is pointed at these legacy IPs, you'll need to update your DNS configuration immediately to keep things running smoothly.

How long do I have to make the switch?

Starting the week of November 10th, pushing to a misconfigured site will result in a build error and you will receive an email stating that your site's DNS is misconfigured. Your site will remain available to the public, but changes to your site will not be published until the DNS misconfiguration is resolved.

For the week of November 17th, there will be a week-long brownout for improperly configured GitHub Pages sites. If your site is pointed to a legacy IP address, you will receive a warning message that week, in place of your site's content. Normal operation will resume at the conclusion of the brownout.

Starting December 1st, custom domains pointed to the deprecated IP addresses will no longer be served via GitHub Pages. No repository or Git data will be affected by the change.

How do I know if I'm affected?

If you have a GitHub Pages site pointed at one of the old IP addresses, you will receive an email from us this week letting you know that you need to make the change (and should have been receiving an email on each push for the past several months). If the suspense is killing you, there's a few ways to check yourself:

  1. If you're using the GitHub Pages Gem, update to the latest version, and run github-pages health-check from your site's root directory. That'll make sure your site's DNS is in ship-shape.

  2. Don't have the GitHub Pages Gem?

    • If you're on a Mac or Linux machine, simply paste this command into a terminal window, replacing your-domain.com with, your site's domain. dig your-domain.com | grep -E '(||' || echo "OK". If you see the word "OK", you're all set.
    • On a Windows machine, you'll want to run nslookup your-domain.com and ensure that the output does not include any of the deprecated IP addresses (207.97.227.XXX, 204.232.175.XX, or 199.27.73.XXX).
  3. From your domain registrar's web interface, head on over to your domain's DNS settings. Your domain should either be a CNAME record to username.github.io, an ALIAS record, or an A record pointing to an IP address that begins 192.30.252.XXX.

Okay, I'm sold. What do I need to do?

If one of the methods above indicate that your DNS is misconfigured, or if you just want to be sure, please follow the instructions for setting up a custom domain with GitHub Pages.

Questions? We're here to help.

Happy publishing!