Skip to content

Save the Dates: GitHub Events in 2016

Mark your calendars. GitHub has a fresh lineup of events for 2016 – including two new European conferences, GitHub Satellite and CodeConf Copenhagen.


Git Merge: April 5, New York City

Git Merge is the pre-eminent Git conference: a full-day event featuring technical content and training workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices from the Git community and to showcasing the most thought-provoking projects from contributors, maintainers, and community managers around the world. Tickets are now on sale. Interested in speaking at Git Merge? Send us an overview of your talk by February 5th. We’d love to hear from you.

GitHub Satellite: May 11, Amsterdam

The first ever European conference in the GitHub Universe event series, GitHub Satellite is a celebration of the latest and greatest in software. Join us to learn how developers, founders, and activists work to create impactful technologies. Great software is about more than code; at Satellite, we'll showcase how the community is tackling the newest and most difficult challenges posed by the modern development workflow.

CodeConf Los Angeles: June 27-29

This year CodeConf, a two-day conference for the open souce community, moves to the West Coast. At CodeConf we will get together to discuss best practices in open source, documentation, community-building, and innovative technical hacks. Check out the lineup from last year's event in Nashville to get a taste of what you can expect.

GitHub Universe: September 14-15, San Francisco.

GitHub Universe is returning to Pier 70 for a two-day conference celebrating technologists and developers from across the GitHub community. Last year, we heard from people who are improving people's lives using technology and redefining how software is built. This year, you can look forward to an even better Universe.

CodeConf Copenhagen: October 24-25

CodeConf comes to Copenhagen for a conversation with the European open source community. Thought-provoking sessions and networking opportunities are just a few of the reasons we hope you’ll join us.

For updates on all of these events as they emerge, keep your eye on

Update on 1/28 service outage

On Thursday, January 28, 2016 at 00:23am UTC, we experienced a severe service outage that impacted We know that any disruption in our service can impact your development workflow, and are truly sorry for the outage. While our engineers are investigating the full scope of the incident, I wanted to quickly share an update on the situation with you.

A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to's operation. While we worked to recover service, was unavailable for two hours and six minutes. Service was fully restored at 02:29am UTC. Last night we completed the final procedure to fully restore our power infrastructure.

Millions of people and businesses depend on GitHub. We know that our community feels the effects of our site going down deeply. We’re actively taking measures to improve our resilience and response time, and will share details from these investigations.

Improved commenting with Markdown


You’ll notice there’s a new Markdown text-formatting toolbar on all the comment fields throughout GitHub. While you've always been able to use Markdown to format your text with links, headers, italics, and lists, the new toolbar allows you to do so without learning Markdown syntax.

The toolbar includes a limited set of tools that gets out of the way of experts, but helps those new to GitHub to write just as clearly, and expressively as anyone else. Neat.


In addition to standard Markdown formatting, the toolbar also includes GitHub-specific features. @mentions bring additional users or teams into the conversation, issue and pull request links allow you to cross-reference related discussions, and task lists track outstanding tasks. They’re now available to you with a single click.

New Year, new Git release

If your New Year's resolution was to update to a new version of Git, we've got good news. The Git community has just released Git 2.7.0, and we'd like to share some of its highlights with you.

More flexible naming for git bisect

git bisect is an awesomely powerful tool for figuring out how a bug got into your project. Just in case you're unfamiliar with it, we'll take this opportunity to give you a short introduction. If you already know about git bisect, feel free to skip the following section.

Review of git bisect

Suppose you get a bug report: "The hyperdrive is running backwards!" Sure enough, in the current master branch, the hyperdrive is running backwards:

$ git checkout master
$ ./test_hyperdrive
FAILURE: destination is getting farther away

"That's funny," you think to yourself, "I know it worked in version 4.2." You double-check:

$ git checkout v4.2
$ ./test_hyperdrive

The question is, how did it break? Some change between version 4.2 and master must have introduced a bug.

At this point you could open your debugger or start adding print statements to the hyperdrive module. But that's a lot of work. Luckily, there's an easier way to discover where the bug was introduced: git bisect.

You start by telling git bisect a good and a bad version:

$ git bisect start
$ git bisect good v4.2
$ git bisect bad master
Bisecting: 2 revisions left to test after this (roughly 1 step)
[8cc2d9b4f02ccc208bd9f6d6b01ac6ed57fbb606] Take advantage of available wormholes

As soon as you do so, git bisect chooses a revision roughly midway between the known-good and the known-bad revisions. Your job is to test this version then tell Git the result of your test:

$ ./test_hyperdrive
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[f97f670fb5303ea0097e4475ec8fcf3e2c7dde85] Hyperdrive: bypass the compressor

You continue like this, each time halving the gap between the newest known-good and the oldest known-bad revisions:

$ ./test_hyperdrive
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e0cbfe825a0285e58c59cefb9b78abff2ae0c369] Implement hyperdrive parity inverter
$ ./test_hyperdrive
FAILURE: destination is getting farther away
$ git bisect bad
e0cbfe825a0285e58c59cefb9b78abff2ae0c369 is the first bad commit
commit e0cbfe825a0285e58c59cefb9b78abff2ae0c369
Author: Some Developer <>
Date:   Thu Dec 31 14:05:09 2015 +0100

    Implement hyperdrive parity inverter

:100644 100644 a9562e3d7cea826ed52072e9b104bc9f7e870cf9 da2bc4f6d15943dcf4872641fae08d79d7696512 A  hyperdrive/parity.c

Congratulations! You now know that commit e0cbfe8 introduced the bug. Often, viewing the changes made by that commit makes it obvious what the mistake was and how to fix it. If not, at least you've dramatically narrowed down the amount of code that you have to debug.

When you're done, type git bisect reset to end the bisection session.

git bisect: not just for regressions anymore

Although git bisect is most often used to find software regressions, it should be clear that the same approach can find any change that was introduced into the software; for example,

  • When did a certain feature slow down?
  • When did the size of the images directory grow beyond 5 MB?
  • When was a particular bug fixed?

git bisect could always locate such changes. But regardless of what kind of change you were looking for, you always had to type good to mark revisions before the change and bad to mark revisions after the change. This could be very confusing, especially if you wanted to find the commit that fixed a bug1.

To better support such uses, git bisect now allows you to use different terms in place of good and bad. With no extra setup, you can now use the more neutral terms old and new to represent "the old state of affairs" and "the new state of affairs":

$ git bisect start
$ git bisect old v4.2
$ git bisect new master

You can even invent your own terms. Just specify them when you start the bisection:

$ git bisect start --term-old yucky --term-new yummy
$ git bisect yucky v4.2
$ git bisect yummy master


New configuration setting for --recurse-submodules

If you use Git submodules, you have probably made the mistake of pushing changes to your main module without first pushing the corresponding changes that you made in your submodules. What you should have done, of course, is use the --recurse-submodules option; for example,

$ git push --recurse-submodules=on-demand origin

Now there is a new configuration option that you can use to save the extra typing (and the embarrassment of pushing incomplete work):

$ git config push.recurseSubmodules on-demand

If you'd rather have Git just warn you about potential problems, then use

$ git config push.recurseSubmodules check

You can override this configuration setting by typing --no-recurse-submodules on the command line. [source]

Continued worktree improvements

Do you remember the git worktree command that was introduced in Git 2.5.0? It allows you to create multiple working copies that are connected to a single local Git repository.

In Git 2.7.0, git worktree continues to get better:

  • With the new git worktree list command, you can list the worktrees linked to the current repository and the branch checked out in each one. [source]
  • git bisect can now run in any worktree, or even in two worktrees simultaneously. [source]
  • You can now clone from a linked worktree. [source]
  • Submodules support for worktrees is improving. [source]

Git LFS support for git p4

git p4 is a bridge between Git and Perforce. It can fetch commits from Perforce into Git, and push commits from Git to a Perforce server. It allows you to use Git locally, even if you ultimately have to push your changes to a Perforce server. (There are similar tools to bridge between Git and Subversion, Mercurial, Bazaar, TFS, and others.)

git p4 now has support for storing large files in Git LFS ("Git Large File Storage"). This allows you to store large files from Perforce (e.g., media files) outside of your Git repository to avoid bloating the repository on disk. (Note that this feature doesn't yet support git p4 submit.) [source]

More uniform commands for listing references

Git has three main ways to list references: git branch, for listing branches; git tag, for listing tags; and git for-each-ref, for listing references of any kind. But these commands, despite their overlapping functionality, had differing capabilities and options.

Now, thanks to the work of Google Summer of Code student Karthik Nayak, these commands now have a more uniform interface, and have also gained some features along the way. Now all three commands support the following options:

  • --points-at <object>: list any references that point at the specified object
  • --merged [<commit>]: only list references that have been merged into commit (HEAD by default) :
  • --no-merged [<commit>]: only list references that have not been merged into commit (HEAD by default) :
  • --contains [<commit>]: only list references that contain the specified commit (HEAD by default)

They have also gained new formatting and sorting options. [source] [source]

Other changes

  • git stash show now supports two configuration settings, stash.showPatch and stash.showDiff, that select how it should display stash entries by default. [source]

  • git blame now works correctly with the --first-parent option, and also when --reverse and --first-parent are used together. [source] [source]

  • The appearance of gitk on high-DPI monitors has been improved. [source]

  • Security fixes:

    • Avoid integer overflow when computing diffs. [source]
    • Limit submodule recursive fetches to safe protocols. [source]

    We recommend that everybody upgrade to a version of Git with these fixes, namely Git 2.3.10+, 2.4.10+, 2.5.4+, 2.6.1+, or of course 2.7.0+.

The rest of the iceberg

As usual, if you would like to know more details about what is new in Git 2.7.0, please refer to the full release notes.

This Git release has more than 800 commits from 81 contributors. Here's to a great 2015 and an even better 2016!

[1] It might seem that git bisect shouldn't care whether the change you are looking for was from bad to good or from good to bad. But in fact, if the first two commits that you mark are not direct ancestor/descendant of each other, git bisect has to examine some common ancestors of those commits. In that case, the logic is different depending on the direction of the transaction that you are looking for.

How the Services team uses GitHub

If you're writing code, a repository is an obvious place to manage your work. But what about when the team's primary deliverable is not software? At GitHub, the Professional Services team helps customers get set up with GitHub Enterprise and trains people how to use Git and GitHub. We use GitHub extensively to efficiently and transparently communicate, schedule and prioritize. We hope how we use GitHub will help your team use the platform for more than just code.

Services team repository as our main interface for interaction

Most teams at GitHub have a team repository with a file that introduces the team and explains the team's main responsibilities. Our Services team's repository shows our offerings and introduces the members of our team.


Our README provides a clear path forward for teams who want to utilize our services by listing our offerings and showing who to reach out to if help is needed. We provide specific team handles for people to mention us with GitHub's @mention feature. By mentioning a specific team they can reach the subset of the team they need.


This way, different team members can respond to their respective team handles. Some teams at GitHub rotate who is responsible for checking their team's mentions on a weekly basis. This lets some team members have stretches without distraction while the team is still responsive to GitHubbers outside of their team. We have streamlined many processes to utilize @mentions with GitHub's notifications instead of relying solely on email correspondence.

In our README, we also have linked Markdown files that document our services. We have files that document how we work, including everything from checklist-formatted Markdown files for onboarding new team members to guides on how to configure LDAP for our customers on GitHub Enterprise. Our team repository provides ample information for people to do their jobs.

Coordinating customer engagements

GitHub Issues, Pull Requests and Notifications are at the heart of coordinating, delivering, and reviewing the Services team's engagements with customers. We use a link that has our engagement Issue template as the body parameter of the URL. This creates a checklist as the top comment of a newly created issue. We coordinate with Sales, Finance, and Legal by opening issues in their team's respective repositories.

Once an engagement is set and ready to be delivered we open a Pull Request to track delivery tasks and notes. We create a file called in a /engagements folder in the repository to open the Pull Request. We then use the top comment of our Pull Request to track any bugs, follow-up tasks for after the engagement, and leave notes for sales to take over. We add comments to the Pull Request for each day's notes to keep everyone on the team in the loop.

When we complete the engagement we write our retrospective. Many different teams at GitHub know about this folder and check in on customer feedback by visiting this /engagements folder and reviewing the retrospective files. We use Pull Request comments to add final details like our expenses and mention the teams needed to close out any outstanding tasks. The process lets us have a great historical document of our conversations instead of the details getting lost in people's email.

Team decisions and transparency

On the GitHub Professional Services team, we try to ensure the decision-making process and our team's initiatives are as collaborative and transparent as possible. We open an issue to discuss any topic that needs our attention. We try to default to having conversations in the open and with a URL.

Transparent conversation is especially necessary as a geographically-distributed team. This pattern permits others who are on Services engagements to get context when they finish their engagements and catch up on their notifications. It also lets people understand the why of a decision even years after the decision occurred.


We often have lengthy discussions about which path to chose, and because we're a diverse team, we hear many different approaches. Our internal focus is to get to a point where we can move forward with an option to test, and refine the path forward as we get more information about what works best.

Weekly radar meetings (standup)

Each Monday, we create an issue that we use as our standup meeting. We add our availability for the week and the main items we will be focusing on. We get together for a 30-minute video chat session to collaborate on the week's activities and to spend some face-to-face time together. People add updates to their activities throughout the week in the radar issue. This helps us stay connected as a distributed team.


How we use pull requests for non-code related changes

The Services team's uses of Pull Requests are varied. We tend to think of a pull request as shipping some change or accomplishment into our organization. We open pull requests to change our README, to track an engagement we are on and to propose future plans for the team. The pull request process enables us to get feedback from our team members while also tracking our major accomplishments. We use GitHub's checklist feature to track outstanding tasks for any deliverable (including this blog post).

Pull requests do a great job of showing how a document evolved as well as making that evolution a collaborative process. By editing files in a pull request, we can see how our thinking has changed over time or how our organization has grown. I attended a great session at OSCON Amsterdam about how New Relic uses Pull Requests for non-code deliverables as varied as discussing company policy changes to documenting infrastructure. Many of the companies that use GitHub discover how the simple @mention and notification tools can transform workflows and company culture.

Collaboration is at the heart of GitHub

At the heart of GitHub is a toolset that empowers developers through tracking change and enabling collaboration. The Services team at GitHub uses these tools as an integral part of their work to help move the company forward. How does GitHub help your team be more collaborative and productive?

The Services team is hiring for multiple positions. Check out the job board and see how you can help us enable companies to create great things with GitHub. If your team needs help getting the most out of GitHub you can visit our website to see our offerings.

Learn Ruby programming with GitHub and Udacity

We love the Ruby programming language for its natural, human-focused design philosophy and think you will too. That's why we teamed up with Udacity to bring you three new Ruby Nanodegrees, starting with Beginning Ruby.

Udacity Beginning Ruby Nanodegree

Beginning Ruby is open for enrollment now, with Ruby on Rails and Senior Ruby on Rails becoming available in 2016.

In each of the Nanodegree programs you will learn from Udacity's expert instructors, with supplemental interviews and content from GitHub Ruby instructors Jesse Toth and John Britton.

With a commitment of 10-15 hours per week, students complete a Nanodegree in an average of 4-9 months, at a cost of $200 per month with 50% returned upon graduation in some cases.

Partnering with Udacity to create the Ruby Nanodegree series is a step to help close the talent gap and empower aspiring developers to gain new skills.

Doubling Down on ConnectHome

b3344c2a-6c44-11e5-9c85-3c25fdda436c Today GitHub is proud to host the Secretary of Housing and Urban Development, Julián Castro, at our SF office. We are thrilled to welcome him, his senior staff, community organizations, tech company workers, and representatives from EveryoneOn, the national non-profit leader of ConnectHome.

ConnectHome stands alone as the first project of its kind. A public-private sector partnership, ConnectHome will initially connect more than 102,000 low-income households – and nearly 200,000 children – living in public housing with high speed broadband wireless Internet and tech tools for digital innovation.

As Chike Aguh from EveryoneOn stated at GitHub Universe, “Talent is universal, but opportunity is not.”

Growing up, many of us working in tech had a home Internet connection and a computer which jump-started our ability to be part of this sector: Currently, 1 in 4 US households do not have a home internet connection. This digital divide primarily affects low-income residents of color and has devastating effects on education and job attainment. Bridging the digital divide is a necessary ingredient to break generational cycles of poverty. GitHub understands this and we’re proud to be in on the ground floor of ConnectHome.

An investment in ConnectHome is an investment in the future of innovation. We will all reap the benefits of a country where everyone is connected and one in which those most impacted by systemic inequity will be the engineers, creators, leaders, and innovators of the tech sector. We fully expect to hire from this talent pool, and are ready and excited to support the genius on the ground.

Today we are proud to announce that we are doubling down on our financial commitment to ConnectHome - now $500,000 - along with $3 million in product and thousands of hours of staff time to help make this a reality. But we need your help: Join us in being part of this historic initiative.

Donate to the individual giving campaign to help every ConnectHome household with children get a device. Spread the word through your networks.

Today GitHub’s CEO, Chris Wanstrath, is issuing a challenge to our friends in the tech sector: Join us in putting dollars behind this momentous project. Contact us ( to become a company sponsor of ConnectHome.

Get involved in Hour of Code and Computer Science Education Week

Every year during Computer Science Education Week, we have the opportunity to give back for an hour to teach students how to code. We're following the example of, whose initiative is to break down the stereotype that only a certain kind of person can program. Collectively our goal is to deconstruct the barrier of "can't" and turn it into "can."

This global movement is introducing computer science across the globe, reaching tens of millions of students in more than 180 countries with a simple a challenge: code for just one hour.

Tutorial Announcements

Every year Hour of Code works with top developers and industry leaders to create fun programming tutorials for students with the hope that they will be inspired to keep learning. The videos introducing these tutorials made us excited about volunteering, so maybe they will motivate you too. Check them out:

Star Wars producer Kathleen Kennedy discusses how to use code to make BB-8 come to life. Watch what else Kathleen has to say about the Star Wars tutorial.

Are you or your kids Minecraft fans? Take a look at the introduction to the Minecraft Hour of Code tutorial featuring Mojang's Lead Developer, @jebox.

screen shot 2015-12-03 at 8 17 16 am

How to Volunteer for Hour of Code

You can get involved by donating an hour of your time to a classroom in your area. This donation can be your physical presence or a video chat with one of many classes around the world. More information can be found in the How-to-Guide for volunteers.

If you're unable to participate in Hour of Code, consider other opportunities to give back during Computer Science Education Week, December 7-13. You can advocate for computer science in the classroom or help your own kids walk through the tutorials.

Continuing the Movement after Computer Science Education Week

We're hosting another workshop on December 12th from 9:00am-4:00pm, teaching K-5 educators how to encourage kids to code. Additional details are available on the workshop page.

Apple open-sources Swift on GitHub

Swift is open-source

Swift, Apple's powerful new programming language, is now open source on GitHub. Developers can submit bug fixes and enhancements, and help bring the language to new platforms.

Open Source has been an important part of Apple's platform for a long time. The iOS and OS X operating systems are powered by the Darwin kernel and hundreds of UNIX utilities. Apple has also played a vital role in advancing open web standards with WebKit, made significant contributions to the LLVM compiler infrastructure, and released ResearchKit earlier this year.

We warmly welcome Swift to GitHub and can't wait to see what you build with it. Check out the showcase of projects built with Swift, and head over to the Swift repository to find out how you can get involved.

Atom mug and annual Monday sale

Let everyone around you know that your daily 1,3,7-Trimethylpurine-2,6-dione (C8H10N4O2) / 3,5 Dicaffeoylquinic acid (C25H24O12) fix just might be radioactive with this new Atom mug. Only you will know the truth.

Stay positively charged in the GitHub Shop. Note that this mug color and style is limited edition. When they're gone, they're gone.

Atom Mug

This Cyber Monday (November 30th), take advantage of free shipping on orders over $30 and use the code OCTOCYBER2015 to take 30% off the new Atom Mug, Octocat Figurine, and the rest of the GitHub Shop.

Don’t forget, the last day to order for delivery by Christmas for international shipping using Priority Mail International shipping rate is December 8th and domestic shipping is December 18th.

A new look for repositories

Repositories on GitHub are about to get a brand new look. The new design improves navigation and simplifies page layout, all while improving the code and performance under the hood. Over the course of the next two weeks, we'll be rolling out the option to opt-in to the new design from any of your repositories with the click of a button.

New GitHub repository screenshot

The collapsing side menu is now a single, always present navigation at the top of every page within a repository. This improves accessibility, makes navigating more coherent, and allows you to always see the labels for each tab without requiring tooltips.

New clone toolbar screenshot

The Code tab now more prominently emphasizes cloning. Clone with confidence using the redesigned protocol switcher, which now contains explicit menu items with explanatory text for each cloning method instead of simple text links.

Example GitHub issue

With the navigation at the top, it's easier to focus on what matters most to you: your content on the page. For example, with the extra horizontal space, issues and pull requests are simpler with a wider and more legible sidebar.

Large changes like this one can be disruptive. To help make the transition as smooth as possible for you, the new design is opt-in for the next two weeks, and after that, you'll switch over automatically.

We're super excited to share the new design with you and can't wait to keep iterating on it moving forward. Enjoy, and happy collaborating!

Introducing: 3" Octocat figurine

From the makers of the 5" Octocat figurine comes the adorably small 3" Octocat figurine. Find yours in the GitHub Shop.

Start Learning Git and GitHub Today with Self-Paced Training

Can't wait for the next live course to get started with Git and GitHub? If so, we have an on-demand training option designed just for you.

GitHub for Developers is a self-paced course that distills best practices and documentation into a focused series of interactive lessons and covers the two most important things you need to know:

  1. Using Git to confidently manage your source code
  2. Using GitHub to collaborate with your team

GitHub for Developers is designed for command-line users who are new to Git and GitHub. This course will help you master the basics of both, from performing essential Git operations to dealing with merge conflicts in Pull Requests. You will even rewrite a bit of project history and learn how to undo almost anything with Git. The course will cover the following sections:

  • Section 1: Introducing Git and GitHub
  • Section 2: Getting Started with Collaboration
  • Section 3: The GitHub Workflow: Branching and Committing
  • Section 4: The GitHub Workflow: Pull Requests
  • Section 5: Setting up Git
  • Section 6: Using GitHub Locally
  • Section 7: The Workflow End-to-End
  • Section 8: Working with Local Files
  • Section 9: Fixing Common Issues with Git
  • Section 10: Creating Shortcuts

We've chosen the Wheelhouse education platform to deliver realistic, hands-on projects for an immersive learning experience. You will watch short videos from the GitHub training team, complete exercises to put your new knowledge to work, and receive immediate feedback on the tasks you complete. You will even be guided in practicing skills within your personal account.

For a limited time, we're teaming up with Wheelhouse to offer complimentary access to the GitHub for Developers self-paced course in exchange for your feedback.

To get started, go to and click the On Demand tab.

Managing large files with Git LFS

We recently announced that Git Large File Storage, our open source project for managing large assets with Git, had reached a 1.0 milestone and would be available to all repositories on If you use GitHub Enterprise, we are happy to share the news that support for Git LFS is now officially available in our version 2.4 release. In this post, we'll take a look at how Git LFS fits into your current workflow, whether you use GitHub's web interface, the command line, or even the GitHub Desktop application.

For more background or to learn the basics about Git LFS, click here.

Seamless integration with GitHub

If you work on a project with assets that you're using Git LFS to manage, one of the first things you may notice is that, despite residing in a separate environment, these large files still show up alongside your other files on GitHub. Rather than showing the text pointers that Git LFS stores in your repository, GitHub uses the pointers to retrieve the asset from the LFS server so you can view them just as you would if they lived in your repository. For renderable content, such as images, this means you have access to the same rich diffing tools available for other in-repository content.

First-class LFS support in GitHub Desktop

If you use GitHub Desktop to collaborate on projects configured for Git LFS, you can use the same flow you are used to. Git LFS support is baked in, so you can make changes, commit, and sync just as you normally would. To change the list of paths Git LFS is managing, use the Git LFS tab in your repository settings to add, edit, or delete tracking rules.


Git-centric command line flow

If most of your Git work takes place in a terminal window, integrating Git LFS into your workflow is as simple as adding a few extra commands to your proverbial tool belt. In addition to utilizing built-in Git functionality as part of its interface, Git LFS implements a Git-like syntax that helps it feel less like an add-on and more like a subset of topical commands.

Getting started

After you download and install Git LFS, you can start managing large files in a Git repository by running git lfs track <your-file>, where <your-file> is a command-line glob specifying a particular file, extension, directory, or any combination thereof. Git LFS writes these globs to a .gitattributes file in your repository that Git uses to pre-process files as they move back and forth from your working directory to your index and commit history.


Once you tell Git LFS which files and paths to manage, you can stage, commit, and push just like you normally would; Git LFS handles all of the details for you. When you run git push, you'll notice a progress indicator showing the transfer status of each file as Git LFS uploads it to the LFS server.


Keeping track of things

If you ever need to find out which paths Git LFS is managing, you can run git lfs track with no arguments. You'll get an output of all the tracking rules from the globs listed in the .gitattributes file. For a deeper view of which specific files these globs are catching, you can run git lfs ls-files to see a listing of all the files in your project that Git LFS is managing.

Other resources

  • The 1.0 release of Git LFS includes a collection of new features and enhancements, such as batch uploading and selective asset fetching, that extend and optimize it to help your workflow.
  • For a deeper dive into the internal workings of Git LFS, you can consult the Git LFS documentation.
  • A guided video demonstration of the features outlined in this video is available on our YouTube channel.
  • To learn more about the history of Git LFS or the latest features, take a look at this recording of a talk from GitHub Universe featuring the project's core contributors.

GitHub Enterprise 2.4 is now available

GitHub Enterprise is the on-premises version of GitHub, which you can deploy and manage in your own, secure environment. The GitHub Enterprise 2.4 release offers users and administrators greater control over their instance—and their workflows. From protected branches to simplified asset management, our latest release includes features and updates that make GitHub more flexible.

Protected branches and required statuses

With protected branches, administrators now have the ability to disable force pushes to specific branches. Required status checks on protected branches make integrations that use our Status API enforceable, and you can disable the merge button until they pass.

Improved organization permissions

Improved permissions give your organization the flexibility to work the way you want. New customizable member privileges, fine-grained team permissions, managed access, and transparent communication with team mentions make it even easier for your team to work together. Learn more about GitHub’s improved organization permissions.

Easier asset management with Git Large File Storage

With the inclusion of Git LFS you can integrate large binary files into your Git workflow. Large files are stored on your server and the custom API allows you to transfer any number of files with ease. Learn more about Git LFS.

More flexibility with GitHub Pages

Your GitHub Pages sites can be public even if your Enterprise instance is private. With the new jekyll-feed plugin, you can automatically generate an Atom (RSS-like) feed of your most recent posts, making it easier for people to subscribe. Learn more about easier feeds for GitHub Pages.

Keep your instance current

Ensure your GitHub Enterprise instance is up-to-date with new features, security patches, and bug fixes by opting in to automatic downloads of new releases, which you can then apply from the management console.

Render map data within GitHub Enterprise

With GeoJSON support, any GeoJSON file in a GitHub repository will now be automatically rendered as an interactive, browsable map, annotated with your geographic data. You can even customize the way your data is displayed, such as coloring and sizing individual markers, or specifying a more descriptive icon.

Merge with confidence

The area above the merge button now contains information on automated status checks, making it easier to see if your proposed changes are ready to go or need more work.

Universal 2nd Factor authentication

Earlier this month we announced that we expanded GitHub's authentication system to support FIDO Universal 2nd Factor (U2F), and this security feature is now available with the GitHub Enterprise 2.4 release. Read more about how U2F keys work or take a look at the documentation to learn how to associate a U2F key with your instance.

For the full list of features and updates, check out the release notes. If you're currently using GitHub Enterprise, you can download this release now. If you want to give GitHub Enterprise a try, request a 45-day free trial.

Something went wrong with that request. Please try again.