What designers, game developers and architects need to know about Git LFS

By on February 19, 2016

<This is a cross-post from Atlassian Blogs>

Atlassian is dedicated to unleashing the potential in software teams. We want to help you work smarter and faster. This is the reason we keep adding new features to Bitbucket  – branch permissions, merge checks, smart commits, smart mirroring and many more.

Last year, we were working on solving another big problem for our users: tracking large files in a Git repository. Git large file support (LFS) provides the ability to store really big files where they’re needed, not just where they fit. We want to make Git right for everyone and that’s why we decided to collaborate with GitHub on building a standard for large file support.

Why Git LFS?
It’s a known issue that Git doesn’t play nicely with large files, and it’s not just developers who struggle with large files and version control. Native Git’s limitations make it challenging for team members like designers, tech writes, sys admins, and build engineers to work closely with developers.

They often need to store their assets in stand-alone systems or cloud storage providers because of Git’s historic inability to track version history for large assets (schematics, graphics, or other media files). Co-locating non-code assets with the code itself means the large assets can be updated quickly, easily versioned, and become a natural part of the deployment pipeline. As a design team incorporates feedback on their interface assets, iconography, and images, they can deploy those changes in a fully-built version of the product and see the results.

Git LFS also allows people like designers to version the assets they share with their team, just like all the other assets in a repository. This means developers can find the latest revision of an asset they need to use without needing to track down the right version of a file or interpreting what “menubar_v2_final_v3_final_final.psd” means. (Sounds almost too good to be true, doesn’t it?)


For mobile software teams and game development teams, Git LFS relieves the pain of working with the ever-larger image, texture, and video assets that cater to the ever-improving resolution on mobile devices. It also means tests and builds don’t need to rely on an external step to succeed. And if you’re building a video- or audio-intensive app, you can keep those stored in Git LFS too.

Git LFS in Bitbucket
Naturally, we want to do everything we can to make Git more accessible to all team members. And that’s reflected in the changes we’re making to Bitbucket, our Git repository manager, available as a cloud service or on-premises server. Any software team using Git LFS can now view every version of project assets through the Bitbucket interface and in select media types we’re now making it easy to compare the latest version updated with our visual diff tools.


Bitbucket Server implemented Git LFS in v4.3, and we’ll be releasing support for LFS in SourceTree (our desktop client for working with Git) soon. We’ve also made it really easy to use LFS in Bitbucket Server so you can get started quickly. But Atlassian’s LFS journey is far from complete. We’re bringing LFS to Bitbucket Cloud soon.

Git for everyone!
We’ll continue collaborating with GitHub on the LFS protocol to extend the capabilities of Git for all software teams using features like file locking to prevent change conflicts, better handling of vector and layered files, and more. In Bitbucket, we’re making it easier to work with media files and our design teams are helping us bring a great UI experience to every member of your software team like designers, tech writers, marketing, etc. – even if they don’t write code.

If you haven’t used Git yet, check out our collection of Git tutorials and articles. Or if you’re ready to get started, signup for a Bitbucket Server account. If you’re already using Bitbucket Server,enable Git LFS for your team and let us know what we can do better.


  • jkaris
    Posted February 22, 2016 at 7:30 pm | Permalink

    Great work! I Can’t wait to try this out on Bitbucket Cloud.

  • Zauron
    Posted February 24, 2016 at 9:39 am | Permalink

    So… is there any hope on getting LargeFiles support for Mercurial repositories as well now that its being added for Git? Don’t really want to force my team to learn yet another source control method now that finally got used to Mercurial (after having switched from Perforce and before that MS SourceSafe).

  • Posted February 24, 2016 at 10:18 am | Permalink

    Where is Mercurial LargeFiles support? Seriously? It’s been around since like 2011. BitBucket was built on the back of the Mercurial user base. Please don’t abandon us. I have a paid BB account and I’m happy to pay for it. But we always use Mercurial when given the choice and lack of LargeFiles support is an issue for us. Please give some love to the nearly 4 year old request here: https://bitbucket.org/site/master/issues/3843/largefiles-support-bb-3903

  • Ivan Zinkevich
    Posted February 24, 2016 at 2:05 pm | Permalink

    Seriously, where’s LargeFiles support for Mercurial? If you’re not going to add this feature, just tell us.

  • Matt
    Posted February 26, 2016 at 2:22 pm | Permalink

    when will this be available on bitbucket cloud?

    • Raj Sarkar
      Posted March 7, 2016 at 8:39 am | Permalink

      Coming soon. In the roadmap.

    • Hannes Tribus
      Posted April 6, 2016 at 10:21 am | Permalink

      I’d be more interested in what could/will be the storage backend for the cloud solution. Will it be configurable?
      Currently we’re using some tailor made solution that puts the files on an Azure Blob Storage or an Amazon one.

  • Raj Sarkar
    Posted March 23, 2016 at 4:26 pm | Permalink

    Sorry we cannot comment about the timeline but we’ve heard your request. Thanks for your feedback.

    • pdffs
      Posted July 12, 2016 at 7:09 pm | Permalink

      Is there a public issue tracking this?

  • pdffs
    Posted July 12, 2016 at 11:07 pm | Permalink

    In case someone else is looking for the git-lfs tracking issue for Bitbucket Cloud, you can find it here:


  • bryan cole
    Posted July 19, 2016 at 3:40 am | Permalink

    Largefiles, Great! But wait … I need to use git for this? Really? Why no mercurial largefiles support?