my-git

Large Repository Practices

English

中文

This directory is intended for teams dealing with monorepos, repositories with massive histories, large binary files, mixed multi-service repositories, and high CI clone costs.

Identify Where the Slowness Originates First

Symptom	Recommended Reading
Unsure how to optimize overall	Large Repository Git Practices
Clone is too slow, only need partial history	Shallow Clone
History and blob objects are too large	Partial Clone
Only care about specific directories	Sparse Checkout
Large files must be checked into the repository	Git LFS
Parallel development across multiple branches	Worktree
Repository operations are getting progressively slower	Repo Maintenance

Architectural Trade-offs

• Submodule vs Subtree

When dealing with shared code, cross-repository dependencies, and component reuse, do not merely consider whether a Git command is viable. Also evaluate team collaboration costs, release cadences, permission boundaries, and disaster recovery methods.

Implementation Sequence

1. First, identify whether the bottleneck is in clone, checkout, status, fetch, CI, or IDE indexing.
2. Then, choose from shallow clone, partial clone, sparse checkout, LFS, or repo maintenance.
3. Optimize for CI and developers’ local machines separately.
4. Establish repository rules for large files and generated files.
5. Configure CODEOWNERS and review rules for critical paths.

Related Content

• GitHub Engineering Governance
• Engineering Practice Cases from Top Tech Companies
• Microsoft Scalar and Large Repository Git Practices
• Uber GitFarm and Git Service Practices

This site is open source. Improve this page.