Git LFS on iPhone and iPad.

Zero-config: what happens automatically

Git LFS replaces large files in Git history with small pointer files and stores the real bytes elsewhere. GitSync.md speaks the LFS batch protocol natively, so on iOS you get:

• Clone — the repository downloads, then every LFS file is fetched (SHA-256 and size verified before it's written) and checked out into your working copy.
• Pull and rebase — only files that actually changed in the incoming commits are re-downloaded.
• Status stays fast — hydrated LFS files don't show up as permanently "modified", even in vaults full of media.

If some objects can't be downloaded (offline, expired link), the clone still completes and you get a clear warning naming the problem — the repository itself is fine.

Tracking new large files with LFS

Suppose you add a 40 MB video to a repo that isn't using LFS yet. When you stage it, GitSync.md notices it looks binary-and-large and asks:

"Use Git LFS? These files look binary or large and are safer in Git LFS. This will update and stage .gitattributes."

Confirm, and three things happen: the matching pattern (for example *.mp4, or an exact path for unusual files) is appended to .gitattributes, the real file is copied into the local LFS object store, and a pointer is staged in the index instead of the raw bytes. Your working copy keeps the playable video — the repository stays lean.

Nothing is tracked silently: the prompt is the gate, every time, for files over the size threshold or with known media extensions (PDF, video, audio, archives, images, design formats).

Pushing: uploads, locks, and guards

• Objects upload first — before the Git push, every LFS object referenced by your new commits is uploaded (batch API, verified by the server).
• Lock guard — if a teammate holds an LFS lock on a file you changed, the push stops with the file and lock owner named, instead of clobbering their work.
• Large-blob guard — a big file that isn't LFS-tracked blocks the push with a clear message ("track them with Git LFS before pushing"), protecting you from accidentally bloating history.
• File locking — on servers that support LFS locking, lock and unlock files from the repo's Git sheet; servers without it degrade silently.

Self-hosted LFS endpoints

GitHub's LFS service works out of the box. For your own infrastructure, GitSync.md resolves the endpoint the standard way:

• .lfsconfig in the repository root or lfs.url in config (HTTP/HTTPS URLs, served with basic auth).
• Otherwise the endpoint is derived from your origin remote — including SSH remotes, where GitSync.md authenticates via git-lfs-authenticate with the same host-key trust flow as regular SSH.

Known limits

• Only the repository root's .gitattributes is consulted (not .git/info/attributes or a global file).
• Hydration is a sweep after clone/pull, not partial-clone/on-demand — repos with huge media history may take a while on first clone.
• Only the origin remote's LFS endpoint is resolved.

Recap

LFS on iOS should be invisible: clone, edit, and push, with the app fetching media, asking before tracking new binaries, and guarding pushes. It works with GitHub and self-hosted endpoints alike — a natural companion to self-hosted Git over SSH.

Related guides