How do you handle large binary files in Bitbucket using Git LFS, and what are the storage and performance considerations?

Think of Git LFS like a coat check at a theater. Instead of carrying your heavy winter coat (large binary file) into the theater and stuffing it under your seat (Git repository), you hand it to the coat check attendant (LFS server) and receive a claim ticket (pointer file). The ticket is small and light, making it easy to carry around. When you need your coat back, you present the ticket and get the original item. Everyone in the theater benefits because the seats are not cluttered with coats, even though the coats still exist and are retrievable.

Git LFS is a Git extension that replaces large files with text pointer files in the Git repository while storing the actual file content on a separate server. When you track a file pattern with 'git lfs track *.psd', Git LFS creates or updates a .gitattributes file marking those patterns for LFS handling. When you commit a tracked file, Git LFS intercepts the add operation, uploads the file content to the LFS server, and stores a pointer file (containing the SHA-256 hash and file size) in the Git tree instead. When cloning or checking out, Git LFS downloads the actual file content from the LFS server and replaces the pointer with the real file in the working directory.

Bitbucket Cloud includes Git LFS support with storage and bandwidth limits that vary by plan. Free plans include 1 GB of LFS storage and 1 GB of bandwidth per month. Premium plans include 10 GB of storage with additional purchasable. Repository-level LFS settings are managed through the Bitbucket UI or API. Bitbucket Data Center supports LFS natively, storing LFS objects on the shared filesystem alongside regular Git data. Data Center's LFS storage is limited only by available disk space, making it suitable for organizations with very large binary assets. Smart mirrors in Data Center also replicate LFS objects, so remote teams get fast LFS downloads from their local mirror.

In production, teams adopt Git LFS for repositories that contain game assets, machine learning models, compiled binaries, design files (Photoshop, Figma exports), or firmware images. The key performance benefit is clone time: without LFS, cloning a repository with 10 GB of binary history downloads every version of every binary file. With LFS, the clone downloads only pointer files (a few KB each), and the LFS checkout downloads only the current version of each file. For a repository with 100 versions of a 50 MB model file, this reduces clone data from 5 GB to 50 MB. However, LFS introduces a sequential download step after clone that can be slow on high-latency connections. The 'git lfs fetch' command supports parallelism (configurable via lfs.concurrenttransfers), and teams with large LFS stores often set this to 8 or higher.

A gotcha that causes data loss and frustration: migrating an existing repository to Git LFS requires rewriting Git history with 'git lfs migrate', which changes commit SHAs and forces all team members to re-clone. This is disruptive and must be coordinated carefully. Another trap is LFS bandwidth limits on Bitbucket Cloud: CI/CD pipelines that clone the repository on every build consume LFS bandwidth, and a busy repository with many daily builds can exhaust the monthly bandwidth allocation. Teams mitigate this by using LFS-aware caching in their pipelines or by configuring GIT_LFS_SKIP_SMUDGE=1 to skip LFS downloads in steps that do not need the actual binary files. Storage costs also accumulate because LFS stores every version of every tracked file, and deleted files are not garbage-collected by default.