Rate this post

SCM-Systeme organisieren die unter Konfiguration-Management gestellten Dateien in einer Baumstruktur, welche stets die Änderungen zu vorherigen Version ablegt. Wird nun eine konkrete Revison einer Datei angefordert, baut Git aus den vorhandene Deltas die richtige Version zusammen und liefert diese aus. Dieser Mechanismus erlaubt es, die Größe des Source-Code-Repositories sehr kompakt zu halten, da nicht jedes Mal die gesamte Datei gespeichert wird. Leider funktioniert diese Technik nur mit reinen ASCII Textdateien, wie es bei einfachem Quelltext der Fall ist. Speichert man allerdings binäre Dateien wie Office-Dokumente, Bilder oder kompilierte Bibliotheken im Repository, greift dieser Mechanismus nicht. Jede Änderung der Binäredatei stellt eine neue Version dar und wird vollständig ins Repository aufgenommen. Hat man nun eine hohe Anzahl solcher Binärartefakte, die auch oft geändert werden, steigt der Speicherverbrauch auf dem Datenträger recht schnell an.

Ein anderer sehr negativer Effekt, der sich mit der Zeit einstellt, ist eine vergleichsweise lange Zeit für das Auschecken auch kleiner Unterverzeichnisse. Zeiten von über 15 Minuten in manchen Projekten sind durchaus möglich. Der Grund liegt in dem Umstand, das Git durch die vielen Dateien mehr Zeit benötigt, um der Baum der angeforderten Revision zu erstellen. Daher resultiert auch der Grundsatz, möglichst keine Binärdateien in die Versionskontrolle aufzunehmen.

Das soeben beschriebene Problem wird durch das Git Large File Support (LFS)-Plugin adressiert. Nachdem festgelegt ist, welche Dateien über LFS zu verwalten sind, werden diese separat abgelegt und über eine Referenz mit dem Repository verknüpft.