Large Files, Repository Scale, Permissions and Tags

What it is

Git is built for text. Large binary files, huge histories and loose access make repositories slow, bloated and risky. This topic covers keeping a repository healthy: large file storage, scaling and optimizing big repositories, sharing code across repositories, permissions, and tags that mark releases.

How it works

Large files

Git stores every version of every file forever. A large binary that changes often can make the history grow by the size of the file every time, and every clone downloads all of it.

Set up Git LFS by installing it, then telling it which patterns to manage.

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design.psd
git commit -m "Track Photoshop files with LFS"

git lfs track writes the rule into .gitattributes, which you must commit. Files already committed stay in the old history unless you migrate them (git lfs migrate).

Scaling and optimizing a large repository

Pipelines can use a shallow fetch to save time, but jobs that need full history, such as versioning from tags or computing a changelog, must fetch the depth they need.

Sharing code across repositories

Permissions

Give the least privilege that does the job and prefer groups or teams over individuals. In Azure DevOps, an explicit Deny overrides Allow.

Tags

A tag is a named pointer to a commit, used to mark releases.

Tags are not pushed by default. Push one with git push origin v1.4.0, or all with git push origin --tags. Use consistent names such as semantic versions, and restrict who can create or delete release tags (a GitHub tag ruleset, or the Create tag and Manage tags permissions in Azure Repos).

A worked scenario

A game studio's repository takes 40 minutes to clone because of texture files. They move *.png and *.fbx to Git LFS, use partial clone and sparse checkout for artists who need one title, give build agents a shallow clone, and tag each release with an annotated tag that the release pipeline watches.