L6. Repository Management: Git LFS, Scalar & Repository Scaling

Git Large File Storage: Keeping Binaries Out of History

Git Large File Storage (LFS) solves a common problem: binary files (images, videos, compiled libraries) bloat repository history. Every clone and fetch downloads the entire history, so adding a large binary means every developer waits longer and uses more disk.

Git LFS replaces large files with lightweight pointer files (a few hundred bytes) in the repository itself. The actual file content is stored separately in a content-addressable storage system. When a developer checks out a file, Git LFS automatically fetches the actual binary from storage.

This keeps clone and fetch operations fast while still versioning binary assets. It is essential for teams with lots of media content or compiled artifacts.

Scalar: Monorepos at Scale

Some organizations run monorepos: a single repository containing code, tests, and configuration for an entire company or product line. Microsoft itself uses a monorepo with billions of files. Scalar is a Git tool built on Git's partial clone and sparse-checkout features. Instead of downloading every commit, tree, and blob in the history, Scalar downloads only the parts you actually need. If you work in the /frontend directory, you don't download the entire /backend history.

Scalar can make a repository with millions of files clone and fetch in seconds instead of hours.

Sharing Code Across Repositories

Sometimes you need to reference code from one repository inside another. Two approaches exist, each with different trade-offs:

Git submodules let you embed another repository as a subdirectory while keeping it logically separate. Updates to the referenced repository require explicit update steps. Git subtree merges another repository's history directly into a subdirectory. The history becomes part of your repository, so future clones include both histories. Subtree is simpler for small shared libraries but creates duplicate history.

Repository Permissions

Azure Repos supports branch-level and repository-level permissions tied to security groups. You can restrict who can merge to main, who can push to release branches, and who can delete branches. GitHub uses team roles: read (view), triage (manage issues/PRs), write (push), maintain (manage settings), and admin (full control). Permissions are assigned per repository and inherited by team members.

Tags for Release Management

Annotated tags are full objects with author, date, and message. They are ideal for releases: they document why this version was released and by whom. Lightweight tags are just pointers to a commit, useful for internal markers.

Most teams tag releases with annotated tags and configure release pipelines to trigger from tag creation. A tag like v1.2.3 signals a release point that is semantically versioned and release-ready.

Recovering Lost Commits

Accidentally running git reset --hard is terrifying, but git reflog records everywhere your branch pointers have pointed. If you haven't garbage-collected yet, git reflog can recover a "lost" commit.

git reflog
git show <lost-commit-hash>
git branch recover-branch <commit-hash>

This is a lifeline if you accidentally delete a branch or hard-reset past commits.

Removing Secrets from History

If you commit a secret (API key, password, database credential) and push it, simply deleting the file in a new commit is not enough. The secret still exists in the commit history where anyone with repository access can find it. git filter-repo (the modern recommended tool, replacing the older git filter-branch) rewrites history to remove the secret from every commit. After filtering, you must force-push and rotate the leaked credential immediately. Exam tip: The AZ-400 exam tests Git LFS for binaries, Scalar for monorepos, git reflog for recovery, and git filter-repo for removing secrets. Know the right tool for each scenario.