Simplifying Large Binary Management in Tower with Git LFS

The Problem: Binaries Bloat Your Repo

When a team checks in large media files—textures, audio, or compiled assets—Git stores every version of the file. A 200 MB image committed ten times can inflate the repository to 2 GB, slowing clone, fetch, and pull operations. Git Large File Storage (LFS) solves this by replacing the file in the repository with a lightweight pointer and storing the actual data in a separate LFS server.

What Tower Does Under the Hood

Tower adds a first‑class Git LFS toggle in Settings → Git LFS. When enabled, Tower automatically:

• Detects a .gitattributes entry for a file type (e.g., *.png filter=lfs diff=lfs merge=lfs -text).
• Replaces the binary content with a pointer file during commit.
• Caches fetched LFS objects locally, so subsequent checkouts use disk instead of the network.
• Integrates LFS downloads into the pull‑request workflow, making collaborators see full files without extra steps.

Getting Started: Enable LFS in Tower

1. Open Tower and go to Settings → Git LFS.
2. Toggle the switch to On. Tower will run git lfs install for you and add the necessary .gitattributes entries.
3. Verify that the toggle is active by checking the .gitattributes file in your repo; you should see lines like *.bin filter=lfs diff=lfs merge=lfs -text.
4. Commit any large file; Tower will push the pointer, and the LFS server will receive the binary.

Note: The LFS toggle is only available in Tower’s paid tiers. The free edition requires manual git lfs install and attribute configuration.

Concrete Example: Adding a 150 MB Asset

Assume you have a new asset assets/hero.png that is 150 MB.

# Inside your repository root
# 1. Add the file
mv /path/to/hero.png assets/hero.png

# 2. Stage and commit (Tower will handle LFS automatically)
# Tower UI: Stage → Commit

# 3. Push to remote
# Tower UI: Push

After the push, check the commit history in Tower:

• Under the hero.png file entry you’ll see a pointer file content similar to:

  version https://git-lfs.github.com/spec/v1
  oid sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  size 157286400

• In the repo on the server, the actual 150 MB binary is stored in the LFS store.

Clone the repo on a fresh machine with Tower:

# Tower UI: Clone → Checkout

When you navigate to assets/hero.png, Tower automatically downloads the full binary from the LFS server. You can confirm this by opening the file in an editor or viewer; it should display correctly.

Trade‑offs & Limitations

• Paid‑tier requirement: The LFS toggle is hidden in the free edition. Manual setup is possible but more error‑prone.
• History rewrite: If your repo already contains large binaries without LFS, enabling LFS will not retroactively convert history. To clean past commits, you must run git filter-branch or BFG Repo-Cleaner and force‑push.
• Team coordination: All collaborators must have LFS installed and the same .gitattributes configuration. Otherwise, they will see pointers instead of files.
• Storage limits: Remote LFS servers often impose quotas. Monitor usage to avoid hitting limits.

Actionable Checklist

1. Confirm your Tower subscription level supports Git LFS.
2. Enable the Git LFS toggle in Settings.
3. Verify .gitattributes contains appropriate filter rules.
4. Test by adding a large file, committing, and pushing.
5. Clone the repo on a new machine to ensure the binary downloads automatically.
6. If you have legacy large files, run BFG Repo-Cleaner to move them to LFS and force‑push.
7. Inform teammates to upgrade Tower or manually install LFS.
8. Monitor LFS storage usage via your remote provider’s dashboard.

By following these steps, you can keep your Git history lean, reduce bandwidth, and provide a smooth experience for all developers working with large assets.