The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, has lived in a single repository for years. By now it holds the sources, two gigabytes of images and videos for the travel pages, several copies of a database export file and the builds of a partner library. A fresh clone takes half an hour, and the pipeline downloads the entire history on every run. You are to decide what belongs where and make the repository fast again.
The exam names two skills: managing large files (Git LFS, git-fat) and scaling and optimizing a repository (Scalar, sharing across repositories).
Prior knowledge: What a package and a feed are is covered in K3, lesson 3.7.4; what Git stores you know from K3, lesson 3.7.1. How you remove data from the history is covered in lesson 2.4. This lesson says how you prevent it from coming to that, and how you work with large repositories.
What Git does well and what it does not
Microsoft's guide to large files says: Git works best with text-based sources and with content that changes in small, readable steps. Large binary files that change completely with every version do not compress or compare well. Whoever checks them in keeps a complete copy in the repository with every commit. Many versions make checkout, branching, fetching and cloning noticeably slower.
The guide yields a simple assignment:
| What | Where | Why (according to Microsoft) |
|---|---|---|
| Source code, scripts, text files | Git | Differences are stored efficiently |
| Dependencies, reusable packages | Package management (Azure Artifacts) | Packages are versioned, the same state runs in every environment |
| Large binary files that change often | Git LFS | Pointer in the repository, content elsewhere |
| Small, rarely changed binary files (icons, web images) | Git | One uniform workflow, no effort |
| Build outputs, logs, traces | not in the repository | Git is for sources, not for results |
Two notes from the guide help you avoid mistakes. First: even small binary files can cause problems if they change often. Microsoft's example: 100 changes to a 100 KB file take as much storage as 10 changes to a 1 MB file, and the small file slows branching more often. Second, the strategies for large binary sources: do not check in compressed archives (unpack them and check in the comparable sources), do not check in compiled code and binary dependencies (build them or deliver them through package management), and keep configuration and structured data in comparable text formats such as JSON.