Sourcetree and Git LFS: What the GUI Handles, and Where It Stops

The symptom: a repository that looks broken after checkout

You clone a repository that stores design assets or build artifacts, and the files land in your working tree at roughly 130 bytes each. Opening one shows a few lines of text starting with version https://git-lfs.github.com/spec/v1. Nothing is corrupt — you are looking at a Git LFS pointer, and the real binary was never fetched.

Git LFS (Large File Storage) keeps big binaries out of the Git object database. Git stores a small text pointer instead, and the actual bytes live on an LFS server. Sourcetree's value here is not that it replaces the git-lfs command-line tool — it does not — but that it can fetch pointer content during checkout and give you a place to see which files are tracked.

What Sourcetree actually does with LFS

Three behaviors matter in day-to-day use:

• Automatic smudge on checkout. When you switch branches or check out a commit, Sourcetree runs the LFS filter so pointer files are replaced with real content. In most setups you do not need to run git lfs pull by hand afterward.
• Credential reuse. LFS authentication goes through the same credential helper Sourcetree uses for the remote, so a repository that already pushes successfully usually does not prompt separately for LFS.
• A status view. Builds that include the LFS pane list tracked files and indicate whether full content is present locally. Treat this as a convenience view over git lfs ls-files, not as a separate source of truth.

Where the settings live, and the version caveat

On Windows, LFS options appear under Tools → Options → Git → LFS. On macOS the same panel is under Sourcetree → Preferences → Git → LFS. The exact label and placement have moved between the 3.x and 4.x release lines, so confirm the path in your installed build rather than trusting a screenshot from an older version.

The hard prerequisite: the git-lfs executable must be installed and on PATH. If it is missing, Sourcetree has no filter to invoke and pointers stay as plain text files in your working tree. Check from Sourcetree's built-in terminal (Terminal button) with git lfs version. A version string means the tool is reachable; a "command not found" error means fix that first.

A worked example: tracking a large asset

Run these in the repository's terminal, with git-lfs installed. The placeholder assets/hero.psd stands for whatever large file you are adding.

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add assets/hero.psd
git commit -m "Track hero art with LFS"
git push origin main

What each step is doing: git lfs install registers the clean/smudge filters in your Git config; git lfs track writes a pattern into .gitattributes, which is the file that actually tells Git to route matching paths through LFS; the commit stores a pointer, not the binary.

Now switch to another branch in Sourcetree and back. Expected result: the file in the working tree is the real size, not ~130 bytes. If it stays small, the filter did not run — check the progress bar for a stalled download, then confirm git lfs version resolves.

Two verification commands, both run in the repository root:

git lfs ls-files
git lfs status

git lfs ls-files lists paths currently tracked by LFS; the output should include assets/hero.psd and should match what Sourcetree's LFS pane shows. git lfs status reports staged and unstaged LFS objects. If the GUI pane and the CLI disagree, the CLI is authoritative.

Trade-offs and limits worth knowing

Behavior	Practical consequence
Diffs show the pointer, not the binary	You cannot review an image or archive change in Sourcetree's diff view. Use an external diff tool or compare outside Git.
Startup polling of the LFS cache	Adds a small launch cost on large repositories; it can be disabled for lightweight workflows where LFS is irrelevant.
Checkout pulls real bytes	Slow networks stall on checkout. Watch the progress bar instead of assuming the app has hung.
Disk usage is unchanged	LFS reduces repository size, not your working copy. Every checkout still materializes full files.

One more limitation that catches teams: git lfs track only affects files added after the pattern exists. Binaries already committed as normal Git objects stay in history. Converting them requires history rewriting, which is a separate, disruptive operation.

Reversing or adjusting the setup

Because tracking changes repository state, know the exit before you standardize on it. git lfs untrack "*.psd" removes the pattern from .gitattributes for future commits, but it does not move existing LFS objects back into Git. Exporting content out of LFS is a history-migration task, not a checkbox toggle. Commit the .gitattributes change like any other file so teammates stay consistent.

What to check before you rely on it

1. Run git lfs version in Sourcetree's terminal and confirm it resolves.
2. Confirm the LFS settings panel in your specific build and note whether the enable option is on.
3. Add one tracked file, commit, push, then check out a different branch and confirm the working-tree size matches the real file.
4. Cross-check the GUI pane against git lfs ls-files.

If all four pass, Sourcetree is handling LFS correctly for that repository. If any fail, the problem is almost always the missing git-lfs binary or an uncommitted .gitattributes — not the GUI.