Das Buchungsportal der Nordlicht Reisen GmbH liegt seit Jahren in einem Repository. Inzwischen liegen darin die Quellen, zwei Gigabyte Bilder und Videos für die Reiseseiten, mehrere Kopien einer Datenbank-Exportdatei und die Builds einer Partnerbibliothek. Ein frischer Klon dauert eine halbe Stunde, und die Pipeline lädt bei jedem Lauf die ganze Geschichte. Sie sollen entscheiden, was wohin gehört, und das Repository wieder schnell machen.
Die Prüfung nennt zwei Fähigkeiten: große Dateien verwalten (Git LFS, git-fat) und ein Repository skalieren und optimieren (Scalar, Teilen über Repositories hinweg).
Vorwissen: Was ein Paket und ein Feed sind, steht in K3, Lektion 3.7.4; was Git speichert, kennen Sie aus K3, Lektion 3.7.1. Wie Sie Daten aus der Geschichte entfernen, behandelt Lektion 2.4. Diese Lektion sagt, wie Sie verhindern, dass es dazu kommt, und wie Sie mit großen Repositories arbeiten.
Was Git gut kann und was nicht
Microsofts Anleitung zu großen Dateien sagt: Git arbeitet am besten mit textbasierten Quellen und Inhalten, die sich in kleinen, lesbaren Schritten ändern. Große Binärdateien, die sich bei jeder Version komplett ändern, lassen sich nicht gut komprimieren und vergleichen. Wer sie einchecken, behält bei jedem Commit eine vollständige Kopie im Repository. Viele Versionen machen Auschecken, Verzweigen, Abrufen und Klonen spürbar langsamer.
Aus der Anleitung ergibt sich eine einfache Zuordnung:
| Was | Wohin | Warum (nach Microsoft) |
|---|---|---|
| Quellcode, Skripte, Textdateien | Git | Unterschiede werden effizient gespeichert |
| Abhängigkeiten, wiederverwendbare Pakete | Paketverwaltung (Azure Artifacts) | Pakete sind versioniert, derselbe Stand läuft in jeder Umgebung |
| große Binärdateien, die sich oft ändern | Git LFS | Zeiger im Repository, Inhalt anderswo |
| kleine, selten geänderte Binärdateien (Icons, Webbilder) | Git | ein einheitlicher Ablauf, kein Aufwand |
| Build-Ausgaben, Protokolle, Ablaufverfolgungen | nicht ins Repository | Git ist für Quellen, nicht für Ergebnisse |
Zwei Hinweise aus der Anleitung vermeiden Fehler. Erstens: Auch kleine Binärdateien können Probleme machen, wenn sie oft geändert werden. Microsofts Beispiel: 100 Änderungen an einer 100-KB-Datei brauchen so viel Speicher wie 10 Änderungen an einer 1-MB-Datei, und die kleine Datei bremst das Verzweigen häufiger. Zweitens die Strategien für große Binärquellen: keine komprimierten Archive einchecken (entpacken und die vergleichbaren Quellen einchecken), kompilierten Code und binäre Abhängigkeiten nicht einchecken (bauen oder per Paketverwaltung liefern) und Konfiguration und strukturierte Daten in vergleichbaren Textformaten wie JSON halten.