Design and implement a source control strategy
Repository Scale, Permissions, and Recovery
CoreKeep repositories fast and governable while selecting the right storage, permission, tagging, recovery, and history-removal technique.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Git history is distributed. A local fix, server permission, or ordinary deletion may not change other clones, historical objects, LFS storage, or shared references.
Must Know
- Git LFS stores pointer files in Git and large content in LFS storage; collaborators need LFS support and quotas still matter.
- Generated binaries and reusable packages normally belong in artifacts or package registries, not source history or LFS by default.
- Partial clone, sparse checkout, and Scalar reduce work for large repositories; measure repository hygiene and client behavior before splitting a monorepo.
- Repository and branch permissions inherit by scope; least privilege avoids force-push, policy-bypass, or administration rights for ordinary builds.
- Annotated tags carry tagger, date, and message metadata and suit release markers; control tag creation and forced updates.
- Use revert for a bad shared commit. If a deleted or force-pushed branch commit still exists in a collaborator clone, create a recovery branch at that commit and push the recovered reference.
- For exposed credentials, rotate first. History rewrite requires coordinated force-push, clone cleanup, and prevention of reintroduction.
Compare and Distinguish
- LFS is versioned large-file storage; a package feed distributes versioned dependencies; a pipeline artifact transfers run outputs.
- Revert appends history; reset moves a reference; restore or checkout changes selected paths; history rewriting removes objects from reachable history.
Scenario examples
- Scenario: A shared branch has one faulty commit followed by valid work. Think: revert the faulty commit.
- Scenario: A secret reached the remote. Think: rotate first, then coordinated history cleanup; deletion in the latest commit is not enough.
Exam traps
- Moving a file to LFS now does not automatically purge its earlier Git blobs.
- A forced rewrite can be undone when an old clone merges tainted history.
- Repository read permission and a package-consumer permission are different scopes.
Key takeaways
- Choose storage by lifecycle and consumer, not file size alone.
- Prefer additive recovery on shared branches.
- Treat history removal as a coordinated incident, not one Git command.
How it works
- Git references make commits reachable, while object cleanup can eventually prune content no branch or tag retains.
- Annotated tags bind release metadata to a commit; permissions determine who may create or replace remote tag references.
Objects and administrative surfaces
- `.gitattributes`, Git LFS, partial clone, sparse checkout, Scalar, ignore rules, tags, branch creation, revert, reset, and filter-repo.
- GitHub and Azure Repos repository security, branch security, audit logs, deleted-branch recovery, server retention, and support procedures.
When to use it
- Split a component into another repository when ownership, permissions, and release lifecycle outweigh atomic cross-component changes.
Security and governance implications
- Coordinate force-pushed history rewrites, protect tags, scope repository roles, and require affected clones to remove tainted objects.
Troubleshooting signals
- For slow clones, measure object size, generated files, large blobs, working-tree count, and client operations before choosing LFS or a split.
More detail
- Use a new revert commit for a shared bad change; reserve reset and rebase for history that can safely be rewritten.
- Recover an existing commit by creating and pushing a reference before reflog expiry or garbage collection removes reachability.
- Revoke an exposed credential before rewriting history because deletion from Git does not make the credential invalid.
Ready for the quiz?
- Why is revert usually safer than reset on a shared branch?
- What remains after a current file deletion?
- When does Scalar help without splitting a repository?
Related objectives
- D2.2.S1 — Design and implement a strategy for managing large files, including Git Large File Storage (LFS) and git-fat
- D2.2.S2 — Design a strategy for scaling and optimizing a Git repository, including Scalar and cross-repository sharing
- D2.2.S3 — Configure permissions in the source control repository
- D2.2.S4 — Configure tags to organize the source control repository
- D2.2.S5 — Recover specific data by using Git commands
- D2.2.S6 — Remove specific data from source control