The GitHub Blog

A course organized around users, not exams

In his Startup Programming course at the University of Victoria, Alexey Zagalsky asks students to design products based on user needs.

Working together in teams of four to six, students deliver pieces of the project at key milestones:

• Milestone 0: Generate ideas and select a product
• Milestone 1: Present a proof of concept
• Milestone 2: Release a live demo
• Milestone 3: Launch public beta with user feedback integrated

He ties the course to the software industry by inviting experienced mentors from local startups to evaluate student work. Alexey says:

While the end-products are terrific, the larger goal is understanding the process of collaborative software development. Students learn how to listen to users and incorporate their feedback in a thoughtful way.

User testing as assessment

After students ship a working prototype, the next milestone requires user testing with their target audience. And of all the challenges over the semester, students wrestle the most with addressing user feedback:

The most frequent point of failure is not understanding their users. And they wouldn’t see where they’ve failed until they try to get people to use their product.

But being able to listen to feedback, and implement it as part of the design process, is quite important. First, to learn, but also to get a job, because it’s not about writing code but actually understanding what needs to be built and how. One student now works at Amazon. Two or three work at Microsoft. One has gone on to become a UX designer. So many students really benefitted from this approach.”

Feedback through GitHub issues

Alexey admits:

You’d be surprised how often students get stuck and never ask for help

So occasionally he pops into student repositories to see what’s going on, test the code himself, and spot mistakes before it’s too late.

If he spots a bug, he’ll open an issue, outline what’s amiss and upload screenshots of the behavior.

From the fall 2016 student project DayTomato.

Next, he works with the team to think about potential solutions:

One team wasn’t sure which metrics they should track using Mixpanel. I suggested they track certain metrics at the prototyping, release, and iteration phases of their project. I gave them some perspective on how to prioritize and implement.

From another student group, who made a borrowing and lending application called Bümerang.

Iteration for intrinsic motivation

In an Agile classroom, the goal is not the right answer to the problem, but knowing which problem to take on first, and how to solve it in the right increments.

This course isn’t about assessing a final product and saying, ‘You did that wrong.’ Our in-progress ‘checks’ show the students we care about their work; it’s not just some assignment they need to submit for a grade. The way we care makes them more motivated in turn.”

Another student project, SmirkSpace, reflecting on its user feedback for Milestone 3.

A collaborative classroom practice

Alexey’s research focuses on how to use industry tools to build software together, to help his students develop the social ties, trust and curiosity to sustain a successful software career.

So he uses GitHub to enable discovery, design, and collaboration:

It’s about changing the way people work: students and educators, students among themselves, and education’s relationship to industry.

I am working from the hypothesis that software built collaboratively, with many voices and opinions, will improve the collective good of future software, period.

How to implement this classroom practice

Alexey documents all of his course designs and publishes the results of his research on student experiences with GitHub, Slack, Stack Overflow and other real-world tools.

Here’s a recent talk on his course design that discusses the benefits (and drawbacks) of using social tools in the classroom:

This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:

• Invest in tools students can grow with: GitHub and RStudio for data science at Duke University, featuring Mine Çetinkaya-Rundel
• How CS50 at Harvard uses GitHub to teach computer science, featuring David Malan
• GitHub Classroom for AP Computer Science at Naperville North High School, featuring Geoff Schmit
• Real-time feedback for students using continuous integration tools, featuring Omar Shaikh

Join this week’s discussion in the community forum: How do you use issues in your class?

General admission tickets for GitHub Satellite 2017 are now on sale. Join us at Printworks in London May 22-23 for the regional extension of our flagship product and user conference, GitHub Universe.

This year, Satellite is inspired by the way teams work. You'll learn how to bring together the people and tools you need to build great software. Find out what we've been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.

You’ll also experience digital art installations and eat delicious food while exchanging experiences with developers from all over the world.

Confirmed Speakers

• Chris Wanstrath, Founder & CEO at GitHub
• Kir Shatrov, Developer Infrastructure Engineer at Shopify
• Lauri Apple, Open Source Evangelist/Agile Project Manager at Zalando
• Jacob Tomlinson, Lead Engineer at the Met Office Informatics Lab
• Phil Haack, Director of Engineering for Client Apps at GitHub

Workshops
Workshops cost €99 and will take place on Tuesday, May 23. Take away hands-on experience, and advance your Git and GitHub Skills with our Training Team in the following workshops: GitHub and the Internet of Things: Automate IoT Hardware, Electron: Start to Finish, Creating an InnerSource Culture, and Build a ChatBot. Space is limited.

Dark Matter
An evening event on Tuesday, May 23, Dark Matter is part mini-conference and part after-party dedicated to the intersection between technology and other domains. Your Satellite conference ticket gets you free entry to Dark Matter.

Sponsorships
Event sponsorships are all about engaging attendees in memorable ways: art installations, lounges, delectable food, and entertaining auxiliary events are just a few examples. Get in touch for more information.

Tickets
General Admission tickets cost €349 and include entry to the After Party (May 22) and Dark Matter (May 23). Workshops are not included in the general admission ticket.

Get Tickets

See you in London!

Earlier today, Microsoft announced the shutdown plans for CodePlex. We're working with the CodePlex team to streamline the experience of importing projects to GitHub for CodePlex users. As always, we will continue to support SVN clients for those who'd prefer to stick with SVN over Git.

Microsoft has made significant contributions to open source on GitHub over the years. With more than 16,000 open source contributors, these contributions continue to positively impact both the Microsoft ecosystem and the open source community.

We welcome CodePlex projects to their new GitHub home!

Not every team manages their work on GitHub in the same way. Now you can disable Projects on a repository if you're not using them.

Users with admin privileges can disable Projects by navigating to a repository's settings and unchecking the "Projects" box. This hides the Projects tab from the repository navigation and removes Projects from Issue and Pull request sidebars, as well as Issue timeline events. Disabled projects are also inaccessible via API requests. Projects can be re-enabled at any time, at which point all projects in the repository will be restored to the state they were in when disabled.

Check out the documentation and the Projects API page to learn more.

At GitHub, we recognize that running a great business over the long term requires a measure of "work/life balance" – and that includes recognizing that developers and other knowledge workers have creative lives outside of work. Whether that free time creativity involves contributing to open source projects, art, or activism, we want to encourage our employees, not put up legal barriers. We've codified this approach in our employee intellectual property (IP) agreement. We've made this agreement reusable and have open sourced as the Balanced Employee Intellectual Property Agreement.

By making the agreement an open source project, we hope to lower barriers to and learn more about innovation in this space. The project FAQ includes further background on related law, policies, and projects. Pull requests are welcome.

If you're in the tech industry, you've probably come across some version of an employee IP agreement before. Typically they assign control over your creativity to your employer, to the extent law allows – sometimes even after you've left a job, through non-compete covenants. These agreements and underlying laws impact worker mobility, innovation, and regional competitiveness. Most non-compete covenants are not enforceable in California, which researchers have long cited as a key reason the computer industry took off in California instead of another contender such as Massachusetts.

GitHub's employment agreement goes a bit further than the California default (and applies to employees outside of California). If you're a GitHub employee, you maintain control over your creation unless it is something "you create, or help create as its employee or contractor" and it is "related to an existing or prospective Company product or service at the time you developed, invented, or created it" or "developed for use by the Company" or "developed or promoted with existing Company IP or with the Company's endorsement." It doesn't matter whether you've used company equipment or not.

Sound interesting? We're always hiring, or we would love to see you start taking the same approach at your company. Check out the repository to learn more.

A few weeks ago, researchers announced SHAttered, the first collision of the SHA-1 hash function. Starting today, all SHA-1 computations on GitHub.com will detect and reject any Git content that shows evidence of being part of a collision attack. This ensures that GitHub cannot be used as a platform for performing collision attacks against our users.

This fix will also be included in the next patch releases for the supported versions of GitHub Enterprise.

Why does SHA-1 matter to Git?

Git stores all data in "objects." Each object is named after the SHA-1 hash of its contents, and objects refer to each other by their SHA-1 hashes. If two distinct objects have the same hash, this is known as a collision. Git can only store one half of the colliding pair, and when following a link from one object to the colliding hash name, it can't know which object the name was meant to point to.

Two objects colliding accidentally is exceedingly unlikely. If you had five million programmers each generating one commit per second, your chances of generating a single accidental collision before the Sun turns into a red giant and engulfs the Earth is about 50%.

Why do collisions matter for Git's security?

If a Git fetch or push tries to send a colliding object to a repository that already contains the other half of the collision, the receiver can compare the bytes of each object, notice the problem, and reject the new object. Git has implemented this detection since its inception.

However, SHA-1 names can be assigned trust through various mechanisms. For instance, Git allows you to cryptographically sign a commit or tag. Doing so signs only the commit or tag object itself, which in turn points to other objects containing the actual file data by using their SHA-1 names. A collision in those objects could produce a signature which appears valid, but which points to different data than the signer intended. In such an attack the signer only sees one half of the collision, and the victim sees the other half.

What would a collision attack against Git look like?

The recent attack cannot generate a collision against an existing object. It can only generate a colliding pair from scratch, where the two halves of the pair are similar but contain a small section of carefully-selected random data that differs.

An attack therefore would look something like this:

1. Generate a colliding pair, where one half looks innocent and the other does something malicious. This is best done with binary files where humans are unlikely to notice the difference between the two halves (the recent attack used PDFs for this purpose).

2. Convince a project to accept your innocent half, and wait for them to sign a tag or commit that contains it.

3. Distribute a copy of the repository with the malicious half (either by breaking into a hosting server and replacing the innocent object on disk, or hosting it elsewhere and asking people to verify its integrity based on the signatures). Anybody verifying the signature will think the contents match what the project owners signed.

How is GitHub protecting against collision attacks?

Generating a collision via brute-force is computationally too expensive, and will remain so for the foreseeable future. The recent attack uses special techniques to exploit weaknesses in the SHA-1 algorithm that find a collision in much less time. These techniques leave a pattern in the bytes which can be detected when computing the SHA-1 of either half of a colliding pair.

GitHub.com now performs this detection for each SHA-1 it computes, and aborts the operation if there is evidence that the object is half of a colliding pair. That prevents attackers from using GitHub to convince a project to accept the "innocent" half of their collision, as well as preventing them from hosting the malicious half.

The actual detection code is open-source and was written by Marc Stevens (whose work is the basis of the SHAttered attack) and Dan Shumow. We are grateful for their work on that project.

Are there Git collisions?

Not yet. Git's object names take into account not only the raw bytes of the files, but also some Git-specific header information. The PDFs provided by the SHAttered researchers collide in their raw bytes, but not when added to a Git repository. The same technique could be used to generate a Git object collision, but like the generation of the original SHAttered PDFs, it would require spending hundreds of thousands of dollars in computation.

What future work is there?

Blocking collisions that pass through GitHub is only the first step. We've already been working with the Git project to include the collision detection library upstream. Future versions of Git will be able to detect and reject colliding halves no matter how they reach the developer: fetching from other hosting sites, applying patches, or generating objects from local data.

The Git project is also developing a plan to transition away from SHA-1 to another, more secure hash algorithm, while minimizing the disruption to existing repository data. As that work matures, we plan to support it on GitHub.

Data science is a melting pot of disciplines: students from Anthropology to Political Science to Education all sign up for the same course. It’s a challenge to keep the material engaging for everyone.

At the same time, teachers want the next generation of data scientists to be able to analyze any dataset they come across in the future with the same level of rigor used in the classroom. That outcome requires a consistent level of training, across diverse datasets.

Mine Çetinkaya-Rundel, Director of Undergraduate Studies and an Associate Professor at Duke University, tackles these problems head-on. She quite literally wrote the book on the subject, and her open, online course Master Statistics with R certifies thousands of students a year. She edits the Citizen Statistician blog and offers the annual Duke DataFest, a hackathon for working with data.

Her data science course emphasizes “reproducible computation”, a documented process of how data is treated in order to replicate the results in the future. She meets that learning goal using R Markdown and R Studio, as well as by requiring students to incrementally commit their changes using Git and GitHub.

Students learn the concept and the real-world tool, at the same time

Some instructional products have a high learning curve in-and-of themselves. Çetinkaya-Rundel would rather students learn a language in the discipline that they can later build upon:

They learn a limited bit of R syntax that allows them to analyze and visualize data in R. While the goal of the course is not to make each student a proficient R programmer, they learn enough R to be able to build on in their second or third classes. Teaching software designed to be used only in an introductory class would not have this benefit.

Editing an R Markdown file in RStudio by Chester Ismay, MIT License

She wants her students to ship their first visualization project quickly and get started “like a knife through butter” without errors. To bootstrap their efforts quickly, she has them access RStudio Pro using her department’s server.

Best practices for scaffolding collaboration

Sta112FS introduces Git on day one to help students learn about version control gradually and in increments. Her GitHub structure is one organization for the course, one repository per team, and one per assignment. She recommends starting out with an individual assignment first, so students can get used to Git’s mental model before adding the complexity of collaboration.

Mine has students access their projects through RStudio, which she integrates with Git. These slides are from her talk, A first-year undergraduate data science course.

On group projects, Mine creates one repository per team, and everyone on the team can push. Knowing that students will encounter merge conflicts when they’re working asynchronously, she provokes the error messages early on in the semester.

In the first exercise, students clone a demo repository and are asked to edit the README in two tools, first on GitHub and then again in the RStudio editor. The conflicting changes throw an error, which she teaches students to resolve calmly, and by reading the messages.

I show them how I would resolve [the conflict], and then they do the same thing... I tried to create a situation in the classroom that could be frustrating for them later, and say, "This is about to happen. It's important to read the message that it sends you, and this is how you would resolve it.”

The setup pays off in engagement and curiosity

For Mine’s course, using a computation tool prompts students to engage with data directly—an important pedagogical choice to make their analysis both personal and real. There’s a freedom in exploring and tinkering with the real-world tool that professionals use.

Using a computational tool means that you can give the dataset to the students, and they can play around with it. They might be playing around with it in a way that you have designed the assignment or the assessment, but still it gives them the flexibility to look at another variable, make a different plot, than what was assigned for them to do.

Git and GitHub expertise after students leave the classroom

While she keeps student repositories private, merely using GitHub gives her students an edge later in their careers. They can also choose to make their repositories public after they are done with the course.

A lot of students have said to me later, even first-year undergraduates, that using GitHub has helped them a lot when they went for an internship or a research position interview.

They are able to say, "Oh, I already have worked with GitHub. I'm familiar with it. I know how it works.” So I think they are at least able to put that on their CVs and go into a situation where there's a research or data analysis team and say, "Yeah, sure. I am actually familiar with the same tools that you use."

Creating RStudio projects from GitHub repositories

To see an example of Git and RStudio in action, check out this tutorial from Dr. Nicholas Reich at UMASS-Amherst:

This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:

• GitHub Issues and user testing as authentic assessment at the University of Victoria featuring Alexey Zagalsky
• GitHub Classroom for AP Computer Science at Naperville North High School, featuring Geoff Schmit
• Real-time feedback for students using continuous integration tools, featuring Omar Shaikh
• How CS50 at Harvard uses GitHub to teach computer science, featuring David Malan

Join this week’s discussion in the community forum: What are your favorite Statistics/R/ GitHub Resources?

Back in September we added open source licenses to repository overview pages. Now, when you view a repository's license, we'll tell you a bit more about it.

If a project is licensed under a popular open source license like MIT, Apache, or GPL, you'll see a brief description of the license, along with an overview of what you can and can't do with the project.

Interested in incorporating the license metadata in your own project? The license descriptions and metadata are themselves open source, pulled from choosealicense.com and made available via the license API.

We hope the additional license metadata helps you make informed choices, but please keep in mind that we’re not lawyers (at least most of us aren't). If you have any questions regarding the right license for your code or any other legal issues relating to it, of course, it’s always best to consult with a professional.

Happy open source licensing!

Humans need at least 3.5 contribution mugs worth of water every day. This 18-ounce mug can help contribute to even the most demanding of hydration habits. Mix the contribution graph with coffee, tea, water, ice cream, cereal, soup or even your pet goldfish. You decide what goes in the mug, we won't judge. Get the Contribution Mug in the GitHub Shop.

In honor of our Bug Bounty Program's third birthday, we kicked off a promotional bounty period in January and February. In addition to bonus payouts, the scope of the bug bounty was expanded to include GitHub Enterprise. It may come as no surprise that including a new scope meant that the most severe bugs were all related to the newly included target.

There was no shortage of high-quality reports. Picking winners is always tough, but below are the intrepid researchers receiving extra bounties.

First prize

The first prize bonus of $12,000 goes to @jkakavas for their GitHub Enterprise SAML authentication bypass report which allowed an attacker to construct a SAML response that could arbitrarily set the authenticated user account. You can read more about the story on their blog.

Second prize

The second prize bonus of $8,000 goes to @iblue for their remote code execution bug found in the GitHub Enterprise management console. This was due to a static secret mistakenly being used to cryptographically sign the session cookie. The static secret was intended to only be used for testing and development. However, an unrelated change of file permissions prevented the intended (and randomly generated) session secret from being used. By knowing this secret, an attacker could forge a cookie that is deserialized by Marshal.load, leading to remote code execution.

Third prize

The third prize bonus of $5,000 goes to @soby for their report of another GitHub Enterprise SAML authentication bypass. This attack showed it was possible to replay a SAML response to have our SAML implementation use unsigned data in determining which user account was authenticated.

Best report

The best report bonus of $5,000 goes to @orangetw for their report of Server-Side Request Forgery. This report involved chaining together four vulnerabilities to deliver requests to internal services that end up executing attacker-controlled code. The reporter supplied a clear explanation of the problem through each step and included proof-of-concept scripts for the entire journey. While this report did not earn a prize for being the most severe, it is exactly the type of report we want to encourage reporters to submit.

Other notable reports

We received a wonderful Christmas gift from @orangetw with a SQL Injection bug on GitHub Enterprise. You can read more about how they learned Rails in three days before finding the bug.

A theme we've seen continue over the years is paying out for bugs that aren't in our own code but in browsers. 2016 was no exception with @filedescriptor's report of funky Internet Explorer behavior detailing how a triple-encoded host value in a URL is handled in redirects.

Lastly, Unicode gonna Unicode. @jagracy found a way to exploit the way Unicode was normalized in our code and in our database engine to deliver password reset emails to entirely different addresses than what were intended.

Some statistics

Our "Two Years of Bounties" post has detailed stats for our submissions during the first two years of the program. These years saw a total payout of $95,300 across 102 submissions out of a total of 7,050 submissions (1.4% validity rate). So far in the third year of the program, we have paid out for 73 submissions for a total of $81,700. Many of these reports fall into our "$200 thank you" bucket. These are issues that we do not consider severe enough for an immediate fix, but that we still want to reward our researchers for. Forty-eight of these issues were deemed high enough risk to warrant a write-up on https://bounty.github.com. We saw a total of 48 out of 795 valid reports, bringing our validity rate to 6%.

In 2016, we saw a slight decrease in the number of reports compared to the average of the previous two years. While we can't know for certain, we suspect this is due to the ever-decreasing presence of "low hanging fruit." Unfortunately, we saw an increase in the number of "critical" reports. All other categories saw a decrease in the number of reports.

Out of the accepted reports, we saw some notable changes in the type of vulnerability reports submitted. Many categories such as XSS, Injection, and CSRF saw a decrease in reports. Notably, the number of valid CSRF reports for 2016 was zero. At the same time, we saw an increase in session handling bugs, sensitive data exposure, and missing function level access controls.

In April of 2016, we transitioned to the HackerOne platform. The graphs will not include all data for the year, unfortunately, but the data is still interesting. Notably, even though we had run a public bounty for almost 2.4 years, we still experienced a large spike upon announcing the transition, just like many programs' initial public launch.

We've also been able to track new data via the platform. For example, our average response was about 16 hours and our time to resolution was about 28 days. Tracking this data and keeping it within acceptable bounds will help ensure our program continues to run smoothly and efficiently.

It's more than just a bounty

We continue to see rewards being donated to charities. We absolutely love donating bounties, and we match all contributions. This year saw donations to Doctors without Borders and the Electronic Frontier Foundation (EFF).

We also sponsored an event that was aimed at helping people from under-represented backgrounds participate in bug bounties. The h1-415 event saw attendance from groups like Hack the Hood, Women in Security and Privacy (WISP), FemHacks, Lairon College Cyber Patriots, and /dev/color. Hack the Hood was nice enough to make a video from the event.

In 2016, we've learned a lot about running a bug bounty program and we've continued to uncover sharp edges of our services and codebase. Our program will continue to evolve to engage and support the community of bounty hunters that have made this program successful. We look forward to your submission in our fourth year of the program!

Best regards and happy hacking,

@GitHubSecurity

Starting today, all Markdown user content hosted in our website, including user comments, wikis, and .md files in repositories will be parsed and rendered following a formal specification for GitHub Flavored Markdown. We hope that making this spec available will allow third parties to better integrate and preview GFM in their software.

The full details of the specification are available in our Engineering Blog.

This project is based on CommonMark, a joint effort to specify and unify the different Markdown dialects that are currently available. We've updated the original CommonMark spec with formal definitions for the custom Markdown features that are commonly used in GitHub, such as tables, task lists, and autolinking.

Together with the specification, we're also open-sourcing a reference implementation in C, based on the original cmark parser, but with support for all the features that are actively used in GitHub. This is the same implementation we use in our backend.

How will this affect me and my projects?

A lot of care and research has been put into designing the CommonMark spec to make sure it specifies the syntax and semantics of Markdown in a way that represents the existing real-world usage.

Because of this, we expect that the vast majority of Markdown documents on GitHub will not be affected at all by this change. Some documents sporting the most arcane features of Markdown may render differently. Check out our extensive GitHub Engineering blog post for more details on what has changed.

There's a new way to reinforce your team's code reviews. Now you can specify who in your organization can dismiss reviews on a protected branch.

In the last year, we've been updating pull requests with features that help teams give feedback and make sure only the highest quality code makes it into their projects. You can leave, manage, request, and dismiss reviews, as well as protect branches and limit merging rights. With restricted review dismissals, you can also ensure important feedback gets addressed.

Completely remove the ability to dismiss reviews on a protected branch or restrict that ability to a subset of users or teams specified in your branch protection settings for any organization repository.

Git helps millions of developers write and collaborate on code, but it's not always a practical choice for building games. With the GitHub for Unity extension, Unity game developers (artists and programmers alike) can better integrate Git and GitHub into their workflow, even if they're versioning large binary assets.

The GitHub for Unity extension integrates Git and GitHub directly into the Unity Editor. You can easily configure, collaborate, and manage your Git project in a dedicated window. The extension also includes Git LFS v2.0 support to store large binary assets and introduces file locking to help communicate with your team that you are working on difficult-to-merge files.

The GitHub for Unity extension is a first step towards unifying the GitHub and Unity workflows, and we'd love to hear your feedback to help guide us in the right direction. Watch for an alpha release over the next few weeks. We'll be making the project open source and publishing the extension in the Unity asset store soon after.

Many thanks to Emil "AngryAnt" Johansen for all his help in getting this project up and running.

Sign up now to get access to the GitHub for Unity plugin preview.

Today we're announcing the next major release of Git LFS: v2.0.0.

The official release notes have the complete list of all the new features, performance improvements, and more. In the meantime, here's our look at a few of our newest features:

File locking

With Git LFS 2.0.0 you can now lock files that you're actively working on, preventing others from pushing to the Git LFS server until you unlock the files again.

This will prevent merge conflicts as well as lost work on non-mergeable files at the filesystem level. While it may seem to contradict the distributed and parallel nature of Git, file locking is an important part of many software development workflows—particularly for larger teams working with binary assets.

# This tells LFS to track *.tga files and make them lockable.
# They will appear as read-only on the filesystem.
$ git lfs track "*.tga" --lockable

# To acquire the lock and make foo.tga writeable:
$ git lfs lock foo.tga

# foo.tga is now writeable

$ git add foo.tga
$ git commit ...
$ git push

# Once you're ready to stop work, release the file so others can work on it.
$ git lfs unlock foo.tga

Everything else

Git LFS v2.0.0 also comes with a host of other great features, bug fixes, and other changes.

Transfer queue

Our transfer queue, the mechanism responsible for uploading and downloading files, is faster, more efficient, and more resilient to failure.

To dive in, visit our release notes to learn more.

Internals

Git LFS has tremendously improved internals, particularly in Git and filesystem operations. push and pull operations have been optimized to run concurrently with the underlying tree scans necessary to detect LFS objects. Repositories with large trees can begin the push or pull operation immediately, while the tree scan takes place, greatly reducing the amount of time it takes to complete these operations.

The mechanism that scans for files tracked by LFS has been enhanced to ignore directories included in your repository's .gitignore, improving the efficiency of these operations.

In Git LFS v1.5.0, we introduced the process filter (along with changes in Git v2.11) to dramatically improve performance across multiple platforms, thanks to contributions from @larsxschneider.

Thank you

Since its release, Git LFS has benefited from the contributions of 81 members of the open source community. There have been 1,008 pull-requests, 851 of which have been merged into an official release. Git LFS would not be possible without the gracious efforts of our wonderful contributors. Special thanks to @sinbad who contributed to our work on file locking.

What's next?

File locking is an early release, so we're eager to hear your feedback and thoughts on how the feature should work.

In addition, our roadmap is public: comments, questions (and pull requests) are welcomed. To learn more about Git LFS, visit the Git LFS website.

Psst! We also just announced the GitHub plugin for Unity, which brings the GitHub workflow to Unity, including support for Git LFS and file locking. Sign up for early access now.

Today we're introducing a new Business offering that brings SAML single sign-on, automated provisioning and deprovisioning, 24/5 support, and guaranteed uptime to GitHub.com. With direct access to our developer community and growing platform of integrators, teams can scale and work more efficiently using the tools they need. With the new offering, teams can work on GitHub.com or GitHub Enterprise for $21/user/month.

A closer look

These new features build on how development teams already work on GitHub.com: with unlimited private repositories, team and user level permissions, pull requests, code review, and project management tools. Now, they can also access:

• Authentication through SAML single sign-on with support for Ping Identity, Okta, OneLogin, Azure AD, and Shibboleth
• Automated access provisioning and deprovisioning
• 99.95% uptime guarantee
• 24 hours a day, five days a week support with a response time of less than eight hours

You might recognize some of these features from GitHub Enterprise, and you'd be right! By adding them, we hope teams will be able to manage people and tools with added security and efficiency, all while hosting code on GitHub.com. We also expect they'll spend less time on overall administration and be able to grow without the need to manually add users or manage servers.

Teams that need to host GitHub on-premises or in a private cloud can do so with GitHub Enterprise, which has also received a few updates today for performance, reliability, and pull request efficiency. Read more about the latest release.

We'll be covering the specifics of this new offering in an upcoming webcast, along with an overview of how teams use GitHub.

Get started today

If you’re already using GitHub.com to host your projects, you can upgrade through your organization's Settings page. If you'd like to talk to someone first, get in touch with our Sales team—we'd be happy to help you out.