<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.