In recent years software teams across all industries have adopted Git thanks to its raw speed, distributed nature and powerful workflows. Additionally, modern software teams are increasingly cross-functional and consist not only of developers but designers, QA engineers, tech writers, and more. In order to be successful these teams need to collaborate not just on raw source code but on rich media and large data.

It’s no secret though that Git doesn’t handle large files very well and quickly bloats your repositories. We are therefore excited to announce that, following Bitbucket Server’s lead earlier this year, Git LFS is now available in beta for Bitbucket Cloud to improve the handling of your large assets. So even if your files are really, really large, Bitbucket Cloud allows your team to efficiently store, version and collaborate on them.

Why should you care about Git LFS?

Git was optimized for source – it’s easily merged and compressed and is relatively small, so it is perfectly feasible to store all history everywhere, but this makes it inefficient and slow when trying to track large binary files. For example, If your designer stores a 100 MB image in your Git repository and modifies it nine times, your repository could bloat to almost 1 GB in size, since binary deltas often compress poorly. Every developer, build agent, and deploy script cloning that repository would then have to download the full 1 GB history of changes, which may lead to drastically longer clone times. Just imagine what would have happened if your designer made 99 changes to that file.

A common solution to this inherent flaw in Git is to track these large files outside of Git, in local storage systems or cloud storage providers, which leads to a whole new set of problems. Separating your large files from your repository will require your team to manually sync and communicate all changes to keep your code working.

With the addition of Git LFS support, you can say goodbye to all these problems track all your files in one place in Bitbucket Cloud. Instead of bloating your Git repository, large files are kept in parallel storage, and only lightweight references are stored making your repositories smaller and faster. The next time your team clones a repository with files stored in Git LFS, only the references and relevant large files that are part of your checked out revision will get downloaded, not the entire change history.

For those interested in a longer explanation of how Git LFS works and how to migrate your existing repository, watch this presentation by Tim Pettersen, Atlassian Developer Advocate, on Tracking huge files with Git LFS.

When is Git LFS right for you?

Generally, if you want to use Git to easily version your large files, Git LFS is the right choice. To call out just a few cases in which Git LFS will make your life easier, here’s a short list:

Game developers working with large textures, 3D, audio and video files

Mobile developers catering for higher and higher display resolutions

Web developers building pages with rich media

Software teams handling checked in dependencies

Researchers working with huge data sets

Multimedia producers and designers

QA engineers using database snapshots for functional tests

Technical evangelists who store their presentation slides in Git

Git LFS support is built right into SourceTree

If you’re like us and use SourceTree, tracking files with Git LFS is one click away. Simply right click on any file type you’d like to track and select the “Track in Git LFS” option. SourceTree will do the rest for you.

What you will get with the Git LFS Beta

Track everything in one place – Track your large assets alongside your source code and stop worrying about manually versioning them in a separate storage system.

Store, version and share large files – Version all your large files with Git, no matter how large they are. With Git LFS you can store huge audio files, graphics, videos or any other binaries efficiently. During the beta period, you get 1GB of storage for up to 5 users. If you are a paid team your storage is based on your user tier.

Clone and fetch faster – Only download what you need. Git LFS will only fetch those large files that you check out and not the entire history of changes.

Just do git – No need to learn anything new. Git LFS seamlessly integrates into your Git workflow and does not require you to learn a new workflow, new commands or use new tools.

Git going right away

If you’re ready to get started, sign up for a Bitbucket Cloud account. If you’re already using Bitbucket Cloud, enable it in one click on the repos you would like to try it out on by heading to the “Git LFS Beta” section on the left sidebar.

Git LFS works pretty much automatically, but you do have to initially tell it which files or file patterns you want to track using LFS. If you wanted to track all mp4s with LFS, for example, you could invoke the track command via your shell:

git lfs track *.mp4

Selecting “Track in Git LFS” in SourceTree will mark just that file as being tracking in LFS. It’s the equivalent of running:

git lfs track

Once your files are tracked, you can stage them using ‘git add’ and check them out as normal.

Hi Joe, At the moment you can’t buy extra storage packs but you can upgrade to the next tier to get more storage during the beta. We have plans to introduce better ways to get more storage in the future for the General Availability of LFS.

Hi Joe, at the moment you cannot buy extra storage packs but you can upgrade to the next tier to get more storage during the beta. We have plans to introduce better ways to get more storage in the future for the General Availability of LFS.

Thanks a lot for your feedback Etienne! We are still dedicated to Mercurial and our integrated CI tool Bitbucket Pipelines just recently added support for it. For LFS we decided to focus on Git for the Beta as Atlassian is one of the top contributors to the public git-lfs extension and lots of customers have been asking for Git LFS. That doesn’t mean that we might not consider adding Mercurial support in the future, though.

Etienne, take into account that large file support in git is open source (just like git itself and mercurial). The actual git-lfs extension has been developed since three years ago by some key people (mostly from github, but also the original writer of atlassian’s SourceTree). It remains to be seen if anything like this is even possible with mercurial, and whether there is enough need so people will dedicate their time to it – it’s all about open source in the end.

The 1.8.x branch contains the UI changes which many users find unusable, and a lot of people are remaining or have downgraded back to this version of the software.

My question is to when will the LFS feature be back-ported to 1.7 as a lot of users want the new functionality without all the interface changes – which make the 1.8 version of software very difficult to use (in a UX sense) for regular use.

Yes, that’s the right ticket. As Dan pointed out in the recent update we had to finish up a few things but have a team focussing on search inside of Bitbucket Cloud. We will post all future updates on that issue to keep everyone informed on our progress.

Hi, LFS storage is separate from your 2GB repo storage. LFS files are stored outside of your Git repo, so you can still store data in your Git repo up to 2GB and store anything else beyond that in LFS.

Plans on the free 1-5 user plan currently get 1GB of free LFS storage.