Every clone downloads the whole history. A 50 MB design file committed once is 50 MB in every clone forever, even after you delete it. Git LFS exists for that problem: the repo keeps a pointer, the bytes live in separate storage.
The setup#
git lfs install
git lfs track "*.psd" "*.zip" "*.mp4"
git add .gitattributes
From then on, matching files are stored via LFS automatically. Existing history is untouched — only new commits use the pointer.
What belongs in LFS on a Laravel project#
Genuinely version-worthy binaries: design source files, brand assets, documentation PDFs, maybe small fixture videos for tests. If the file is source material the team edits and needs history for, LFS fits.
What does not#
User uploads, media libraries, anything served to visitors. Those belong in object storage with a CDN in front — Laravel’s filesystem disks are built for exactly that, and your repo stays lean. The test is “does the next developer need this on a fresh clone?” If not, it is not repo content.
If the repo is already heavy#
Adding LFS now does not shrink old history; that takes the same history-rewriting treatment as a leaked secret, with the same team-wide re-clone cost. Worth it when clones hurt, not before.
Share this post
Keep reading
Annotating Commits with git notes: Metadata Without Rewriting History
Some things belong on a commit but not in it: review links, benchmark results, the ticket nobody remembered to reference. git notes adds them after the fact, no rebase required.
Backing Up Your Git Server So It Actually Restores
Every clone is a partial backup - but hooks, config and server state live outside the repo. Mirror, bundle, copy off-site, and rehearse the restore.
Cherry-Picking: One Commit Without the Branch
Cherry-pick copies a single commit onto your branch and leaves the rest behind. Right for hotfixes across release branches, wrong as a sync strategy.
