Skip to main content
Git LFS is supported out of the box on native Code Storage repositories and GitHub App sync repositories. The LFS server lives at the same hostname as your Git remote, uses the same JWT for authentication, and stores objects in managed object storage. There is nothing to enable or configure. LFS is not supported on public GitHub sync or generic HTTPS Git sync repositories.

​
Prerequisites

Install the git-lfs client locally and run the one-time hook installation:
This registers the LFS smudge/clean filters in your global Git config. You only need to do it once per machine.

​
Quick start

Clone the repository, declare which paths LFS should track, and push.
The pointer files land in Git. The object bytes stream to Code Storage’s LFS backend over the same HTTPS connection.
Run git lfs track before you add the file. Commit .gitattributes with the file or in an earlier commit. Git LFS does not convert a file from an earlier commit.If Git already stores the file as a regular blob, use git lfs migrate import to convert it. This command rewrites Git history.

​
How it works

Every repository exposes a Git LFS Batch API at the same host as the Git remote. The client discovers it automatically, so you do not configure it. The endpoint it posts to is:
When you git push, the LFS client:
  1. Reads .gitattributes to determine which paths are tracked
  2. Replaces tracked file contents in the commit with pointer files (size + SHA-256 OID)
  3. Posts to the LFS Batch endpoint to negotiate object upload URLs
  4. Uploads the actual object bytes
  5. Pushes the Git refs as usual
The same JWT that authenticates git push authenticates the LFS upload. There is no separate token or credential. Required scopes match Git operations: git:read for git lfs pull/fetch, git:write for git lfs push.

​
Verifying tracked files

After committing, confirm what LFS is actually managing:
If git lfs ls-files does not show a file you expected, it was committed as a regular blob. Check that .gitattributes was committed first and that the path glob matches.

​
Migrating existing large files

If you already committed large files as regular blobs, rewrite history to move them to LFS:
This rewrites commits, so coordinate with collaborators before force-pushing.

​
Forking and LFS objects

Server-side forks copy Git history but not LFS objects. The fork inherits pointer files. The bytes stay under the source repo. git lfs pull on the fork will fail. To carry LFS objects across, round-trip locally:

​
Caveats

  • Pointer files in diffs: Tools that don’t understand LFS will show the pointer file (version, oid, size lines) instead of the real content. Install git-lfs everywhere the repo is checked out.
  • Object lifecycle: LFS objects are scoped to the repository. Deleting the repository deletes its LFS objects.
  • File locking API not supported: git lfs lock, git lfs unlock, and git lfs locks will fail. There is no server-side lock registry.
  • Maximum single file size is 5 GiB: Enforced by the git-lfs client itself, which uploads each object in a single PUT.