AZ-400 Question 81
Select 3Your organization maintains a large monolithic Git repository for multiple products. Over time, the repository has grown significantly, leading to prolonged clone times and slow merge or fetch operations. You need to design a strategy for scaling and optimizing this repository to maintain developer productivity. Which three actions should you consider to improve repository performance while minimizing disruption?
- A
Convert the repository into multiple Git submodules, with each product maintained in its own submodule.
- B
Use partial clones or sparse checkouts so that developers only download subdirectories or files they need.
- C
Leverage cross-repository sharing to store common objects in a central object store that multiple repositories can reference.
- D
Enforce a strict linear history policy to reduce branching, thereby simplifying merges.
- E
Implement Scalar to automate background maintenance, such as prefetching objects and running optimized garbage collection.
Show answer and explanation
Correct answers: B, C, E
Explanation
To optimize large Git repositories, especially monolithic ones, you can combine partial clones/sparse checkouts, cross-repository sharing, and tools like Scalar. Partial clones allow developers to pull only relevant data, reducing local disk usage and clone times. Cross-repository sharing helps multiple repositories reference the same objects, cutting down on duplicated storage. Scalar automates routine maintenance tasks so that developers spend less time waiting on Git operations. For more details, consult the Microsoft documentation on Scalar (https://github.com/microsoft/scalar) and Git performance techniques (https://git-scm.com/docs/).
- A. Incorrect.
Option 1 (Convert into multiple submodules): INCORRECT. While submodules can help isolate different parts of a codebase, they significantly increase complexity for repository administration and developer workflows. Submodules are not typically recommended as a primary scaling strategy for performance issues in a monolithic repository.
- B. Correct.
Option 2 (Use partial clones or sparse checkouts): CORRECT. Partial clones and sparse checkouts can dramatically reduce the amount of data developers must download. This is one of the recommended approaches to mitigate the performance overhead of large monolithic repositories without requiring the entire repository content for every developer.
- C. Correct.
Option 3 (Leverage cross-repository sharing): CORRECT. Cross-repository sharing can store common objects in a shared object store, enabling different repositories (or forks) to reference the same underlying data. This approach can reduce storage requirements and clone times, especially if multiple repositories share substantial history.
- D. Incorrect.
Option 4 (Enforce strict linear history): INCORRECT. While a linear history can simplify merges, it does not substantially address large repository size or slow cloning times. Restricting branching typically impacts development workflows more than it addresses performance problems.
- E. Correct.
Option 5 (Implement Scalar): CORRECT. Scalar helps large Git repos by automating background maintenance tasks like garbage collection and prefetch operations. It also optimizes performance-intensive Git operations and reduces the overhead developers experience with large repositories.