When you add a tracked file, Git LFS intercepts the operation via smudge/clean filters. It stores the actual file on the LFS server and creates a pointer file (containing OID, size, and server URL) in the Git repository. On checkout, the smudge filter replaces the pointer with the actual file downloaded from the LFS server.

Git LFS replaces large files with pointers while keeping them in the same repository. Submodules reference external repositories. LFS is better for large files within a project; submodules are better for separate projects with independent lifecycles. LFS provides seamless integration; submodules require explicit initialization and updating.

Use git lfs migrate import --include="*.ext" --everything to rewrite history and replace existing large files with LFS pointers. This requires a force push and coordination with all collaborators, who must re-clone the repository. Always backup before migration and test on a copy first.

You can't push new LFS files until you free up space or upgrade your plan. Existing LFS files remain accessible. Solutions include pruning old objects (git lfs prune), removing unused LFS files from history, or migrating to external storage for archival files. Monitor usage proactively to avoid surprises.

Most major providers support LFS: GitHub, GitLab, Bitbucket, Azure DevOps. However, storage limits, bandwidth policies, and pricing vary significantly. Some providers include LFS in their plans; others charge extra. Always verify LFS support and limits before committing to a hosting provider for large-file repositories.

A Git LFS pointer file is a small text file (typically 128 bytes) that replaces the actual large file in the Git repository. It contains the LFS version, the file's SHA-256 OID (object ID), and the file size in bytes. For example: version https://git-lfs.github.com/spec/v1, oid sha256:abc123..., size 12345678.

The pointer file is what Git actually versions and commits. The smudge filter reads this pointer during checkout and downloads the real file from the LFS server. If the pointer file is committed without the actual LFS object on the server, you get a broken checkout where the working directory shows the pointer text instead of the real file.

The key is to commit the .gitattributes file to the repository so every team member automatically gets the same LFS tracking configuration. Define patterns for file types (e.g., *.psd filter=lfs diff=lfs merge=lfs -text) in .gitattributes and commit it before anyone adds large files.

Additionally, use a pre-commit hook that checks for files over a size threshold (e.g., 1MB) that aren't tracked by LFS. This catches human errors where team members add large files without updating the tracking patterns. Document the LFS workflow in your team's onboarding guide so everyone understands how to add new file types to LFS.

When bandwidth limits are exceeded, LFS push and pull operations fail with a quota exceeded error from the hosting provider. Existing LFS objects remain accessible — you can still clone older commits that reference objects already stored — but you cannot upload new objects or download objects that were never cached locally.

Mitigation strategies include monitoring bandwidth usage proactively, compressing files before adding them to LFS, using git clone --filter=blob:none to avoid unnecessary LFS downloads in CI, and upgrading your hosting plan or switching providers if bandwidth costs become prohibitive at scale.

Git LFS does not support meaningful diffing of binary files. Since the actual file content is stored externally and only a pointer file exists in the repository, Git's diff engine sees only the pointer file differences (OID changes) rather than content-level changes. This is a fundamental limitation — LFS treats files as opaque blobs.

For binary assets that need diffing (e.g., design files, 3D models), consider specialized tools like PixelGlass for images or DeltaWalker for binary comparison. Some providers like GitHub support rich diffs for specific file types (PNG, SVG) without LFS, which may be a better choice if visual diffing is important.

Several alternatives exist depending on your use case. Git Annex provides similar functionality but with a different architecture — it tracks file content in the Git repository while storing the actual files on external remotes, offering more flexibility for archival and academic use cases. External storage (S3, CDN, GCS) is appropriate for static assets that don't need version control integration.

For game development, Perforce is often preferred due to its superior handling of large binary files and partial checkout capabilities. DVC (Data Version Control) is purpose-built for ML datasets and models. Some teams use Git submodules to reference separate repositories for large files, though this introduces coordination overhead.

Use git lfs migrate import with the --include flag specifying file patterns: git lfs migrate import --include="*.psd,*.png" --everything. This rewrites Git history, replacing the actual file contents in old commits with LFS pointer files. The --everything flag applies the migration to all branches and tags.

You can also migrate specific directories: git lfs migrate import --include="assets/images/**" --everything. Always run the migration on a fresh clone to avoid local state issues, and coordinate with the team since migration requires a force push. Test the migration on a copy of the repository first to verify the results.

git lfs migrate import converts large files in Git history to LFS pointers, reducing repository size by storing actual file content on the LFS server. This is the command used when migrating an existing repository to use Git LFS. It rewrites history so old commits reference LFS objects instead of storing the full file content.

git lfs migrate export does the reverse — it converts LFS pointer files back to regular Git blobs, removing files from LFS management. This is useful when you decide LFS isn't right for certain file types, or when migrating away from LFS entirely. Both commands rewrite history and require force push and team coordination.

Most CI/CD platforms require explicit LFS configuration to pull large files during builds. In GitHub Actions, set lfs: true in the checkout step. In other CI systems, run git lfs pull after checkout. Without this, CI jobs work with pointer files instead of actual content, causing build failures.

For faster CI, use git clone --filter=blob:none to skip LFS download entirely, then selectively pull only the LFS files needed for the specific build job. This avoids downloading gigabytes of assets for every CI run. Cache LFS files between CI runs using platform-specific caching mechanisms to further reduce bandwidth and build time.

Git LFS file locking prevents merge conflicts on binary files by allowing developers to lock files they are actively editing. When you lock a file via git lfs lock filename.ext, other users are blocked from pushing changes to that file until you unlock it with git lfs unlock filename.ext.

This is particularly important for binary file formats like PSD, AI, or 3D model files that cannot be merged. Without locking, two developers editing the same binary asset will inevitably encounter merge conflicts that must be resolved by discarding one version. File locking requires server-side support and works with most major Git hosting providers.

Use git lfs prune to remove local LFS objects that are no longer referenced by any checkout or recent commit. This frees up disk space without affecting the remote LFS storage. By default, prune keeps objects referenced by the current checkout plus recent revisions (configured via lfs.pruneverifyremotealways and lfs.pruneoffsetdays).

For remote storage management, identify large or unused LFS objects with git lfs ls-files --all --size. Some providers offer APIs to delete specific LFS objects, but use caution — deleting objects that are still referenced in Git history will break checkouts for anyone fetching those commits. Set up automatic pruning schedules in CI and monitor storage usage dashboards provided by your Git host.

Git LFS integrates with Git's partial clone feature via git clone --filter=blob:none, which downloads commit metadata but defers downloading LFS objects until checkout. This enables faster clones by transferring only the pointer files initially, then fetching actual content on demand during checkout.

When combined with sparse checkout, you can clone a monorepo and only populate specific directories, and LFS will only download the large files within those checked-out paths. This dramatically reduces clone time and disk usage for repositories with many large assets, making it practical to work with game engines, ML datasets, and design repositories on limited bandwidth.

Git LFS improves initial clone speed for repositories with large files because only pointer files (128 bytes each) are transferred through Git's protocol. The actual file content is downloaded in parallel by the LFS client from the remote server, typically using multiple concurrent connections. A repository with 1GB of assets might clone in seconds instead of minutes.

However, checkout time increases because each LFS file triggers an HTTP request to the remote server. For repositories with thousands of small LFS files, the overhead of individual requests can make checkout slower than a non-LFS repository. Use git lfs pull --include="..." to selectively fetch only needed files, and consider batching small assets into archives to reduce the number of LFS objects.

Common Git LFS errors include pointer files in the working directory instead of actual files (meaning LFS objects weren't downloaded — run git lfs pull), batch response errors indicating quota or auth issues (check hosting limits and credentials), and smudge filter errors during checkout (re-run git lfs install and verify filters are configured).

For corruption issues, run git lfs fsck to verify object integrity. For missing objects, try git lfs fetch --all to download everything. If you see this exceeds Git LFS file size limit, the file exceeds your provider's limit (typically 2-5GB) and needs to be split or stored externally. Always check git lfs env to verify LFS configuration and endpoint URLs.

For large teams, standardize LFS tracking patterns via a committed .gitattributes file and enforce it with CI checks that reject pushes containing large non-LFS files. Establish clear ownership for different asset types — designate who can add new LFS file patterns and who monitors storage usage each sprint.

Implement LFS file locking for binary assets to prevent merge conflicts. Use git lfs dedup (where available) to save disk space on duplicated files across branches. Set up automated alerts at 70% and 90% of your storage and bandwidth quotas, and schedule regular audits to identify and archive unused LFS objects. Document the LFS workflow heavily in your onboarding materials.

Git LFS is simpler to set up and integrates natively with major hosting providers (GitHub, GitLab, Bitbucket), making it the preferred choice for most teams. It uses a straightforward pointer file model and works transparently once configured. However, it requires paid storage on most providers beyond free tiers and is less flexible about storage backends.

Git Annex is more flexible and powerful but significantly more complex. It supports multiple remote storage backends (S3, rsync, USB drives, web) and allows files to exist only on specific remotes without needing a central server. Git Annex is better suited for archival, scientific data, and scenarios where you need fine-grained control over file availability. For most software teams managing binary assets, Git LFS is the recommended choice due to its simplicity and platform support.