AZ-400 Question 79
Select 2Your organization maintains a Git repository that has grown to over 50 GB due to large binary files and an extensive commit history. Developers frequently encounter slow clone and fetch operations. You are asked to design a strategy for scaling and optimizing the repository, and you are considering the use of Scalar and cross-repository sharing. Which two approaches should you recommend?
- A
Use Scalar to accelerate Git operations and consider partial clone options to reduce the local repository footprint
- B
Migrate rarely accessed subprojects into separate repositories and reference them using submodules or cross-repository sharing
- C
Rebase and squash the entire repository history into fewer commits to drastically reduce commit count
- D
Disable Git garbage collection (GC) to avoid processing overhead on large repositories
Show answer and explanation
Correct answers: A, B
Explanation
To optimize large Git repositories, Microsoft recommends using tools like Scalar to streamline common Git commands and enable partial clones. Splitting monolithic repositories into smaller, more focused components (and referencing them when needed) further helps manage repository size and improve performance. Rebasing an entire history is typically too disruptive, and disabling Git garbage collection can lead to unchecked repository growth. Refer to Microsoft� documentation on Scalar (https://github.com/microsoft/scalar) and best practices for managing large Git repos for additional guidance.
- A. Correct.
Implementing Scalar provides performance benefits for large Git repositories by optimizing common operations and supporting partial clones. This reduces the local footprint and speeds up fetches and other Git commands.
- B. Correct.
Breaking out rarely accessed subprojects into separate repositories, then referencing them using submodules or cross-repository sharing, lessens the burden on the main repo. This approach makes clone operations smaller and more focused, especially when those rarely used components are not needed by every developer.
- C. Incorrect.
Rebasing and squashing the entire history can cause significant disruption and introduce risk. While it may reduce the total commit count, it often invalidates existing commits, pull requests, and references, which can be highly problematic in large production environments.
- D. Incorrect.
Disabling Git garbage collection creates more problems over the long term. Accumulated data and unreferenced objects continue to grow, eventually causing performance issues as the repository size becomes unmanageable.