Managing Large Binary Files in SourceTree with Git LFS

The problem: a multi-gigabyte design file in your Git history

A designer commits a large Photoshop file to a feature branch. The commit succeeds, but the next pull drags for everyone else. Git is built for text, so every version of that binary stays in the repository history. Clones slow down, disk usage grows, and the repository becomes difficult to maintain.

The useful takeaway is that SourceTree can manage these assets with Git LFS, but LFS is not bundled with SourceTree. You must install it separately, configure tracking patterns, and verify that binary objects actually reach the remote before assuming the work is safe.

How Git LFS changes what SourceTree stores

Git Large File Storage (LFS) replaces large files in Git commits with small text pointers. The actual binary lives in an LFS object store, while the pointer stays in the normal Git history. When someone clones the repository, Git downloads the pointer first and fetches the binary only when needed.

SourceTree exposes this through a graphical interface, but it does not install or ship the git-lfs binary. If that binary is missing from your system PATH, SourceTree cannot initialize LFS or surface its options correctly.

Check that Git LFS is available

Open a terminal or command prompt and run:

git lfs version

Where to run: any directory. Required permissions: none. Expected result: version information for the installed Git LFS binary. If the terminal reports that the command is not installed, install Git LFS before opening SourceTree for LFS work. SourceTree will not install it for you.

Worked example: track Photoshop files

This example tracks Photoshop files so they are handled by LFS instead of being committed directly to Git.

1. Open the repository in SourceTree.
2. Open a terminal in the repository root and run:

git lfs track "*.psd"

Where to run: repository root. Required permissions: write access to the repository working tree. Expected result: Git LFS creates or updates .gitattributes with a pattern such as *.psd filter=lfs diff=lfs merge=lfs -text.

1. Commit .gitattributes in SourceTree.
2. Add a Photoshop file, stage it, and commit.
3. Push to the remote.

After committing, inspect the tracked file in SourceTree or a text editor. It should contain an LFS pointer rather than binary image data. The pointer references an object ID and size, while the binary itself belongs in the LFS store.

Verify the push before telling the team it is safe

A SourceTree commit can appear successful even when LFS objects remain on your local machine. Run this check after committing and before pushing:

git lfs ls-files

Where to run: repository root. Required permissions: read access to the local repository. Expected result: a list of LFS-tracked files with their object IDs. If a recently committed binary does not appear, its object may not be tracked locally yet.

Push to a remote that accepts LFS pushes. After pushing, confirm the binary reached the remote using your Git host's LFS object count or storage report. If your host enforces LFS quotas, large binaries can consume storage and bandwidth faster than ordinary text commits.

Limitations and rollback

Git LFS is not a substitute for repository history hygiene. Large LFS objects remain outside normal Git objects, and rewriting history to remove them later can be expensive. SourceTree's LFS interface also differs between Windows and Mac, and older versions may lack newer lock or unlock features.

If you decide to stop tracking a pattern, run:

git lfs untrack "*.psd"

Then update .gitattributes and commit the change. This stops future matches from being tracked by LFS, but it does not remove LFS objects already stored in previous commits.

Actionable closing

Before standardizing on SourceTree with Git LFS, confirm your edition and version are still supported. Then run git lfs version on every developer machine, track only the binary patterns that truly need LFS, and verify pushes with git lfs ls-files and a remote check. Treat LFS as a storage tool, not a replacement for keeping repository history lean.