17. Jul 2023
Lesedauer 16 Min.
Größe ohne Probleme
Umfangreiche Dateien mit Git verwalten
Git Large File Storage verwaltet große Dateien in Repositorien effizient und transparent.
dotnetpro
Die effiziente und übersichtliche Verwaltung von Quellcode steht in praktisch allen Softwareprojekten im Fokus. In diesem Zusammenhang hat sich Git, ein dezentrales Versionsverwaltungssystem, längst als Standardlösung etabliert. Doch wie bei jeder Technologie hat auch Git seine Grenzen, insbesondere bei der Verwaltung großer Dateien.Große Dateien zu verwalten ist für viele Repositorien unausweichlich. In Softwareprojekten gibt es in der Praxis zwar häufig eher kleinere Dateien mit Quellcode und anderen Ressourcen; nicht selten kommen aber auch Audio- und Video-Dateien, Datensätze und Grafiken hinzu. Diese sind dann schnell deutlich umfangreicher als reiner Quellcode.Hier setzt Git Large File Storage, kurz Git LFS, an. Das Tool ist als Erweiterung für Git und speziell für die Handhabung großer Dateien innerhalb von Git-Projekten konzipiert. Bei der Entwicklung von Softwareprojekten werden oft nicht nur Codedateien benötigt, sondern auch andere Dateitypen mit umfangreicheren Platzanforderungen. Diese können häufig sehr groß sein und führen bei der herkömmlichen Verwendung von Git zu Leistungsproblemen.Git ist ursprünglich entstanden, um Quellcode effizient zu verwalten – was das Werkzeug hervorragend beherrscht. Jede Version jeder Datei wird in der Git-Historie akribisch protokolliert, sodass sich die jeweiligen Änderungen jederzeit rückgängig machen oder vergangene Zustände sich wiederherstellen lassen. Bei kleinen Textdateien ist dies kein Problem, aber bei größeren Dateien kann es schnell zu enormen Speicheranforderungen kommen.Das ist der Grund für die Einführung von Git LFS. Anstatt große Dateien direkt im Repository zu speichern, verwendet Git LFS sogenannte Pointer-Dateien. Diese sind sehr klein und verweisen nur auf die eigentlichen Daten, die separat gespeichert sind. Auf diese Weise bleibt das Repository selbst klein, während die großen Dateien effizienter verwaltet werden können.Die Git-Erweiterung wurde erstmals 2015 von Atlassian und GitHub angekündigt und ist heute eine offene und weit verbreitete Lösung für die Handhabung großer Dateien in Git-Projekten. Es wird von einer Vielzahl von Hosting-Plattformen für Git-Repositories unterstützt, einschließlich GitHub, Bitbucket und GitLab, und ist bei einer Vielzahl von Unternehmen und Projekten in verschiedensten Branchen im Einsatz.Es ist wichtig zu betonen, dass Git LFS nicht als Ersatz für Git gedacht ist, sondern eine Ergänzung darstellt. Git LFS erweitert die Fähigkeiten von Git und ermöglicht es Entwicklern, besser mit großen Dateien in Projekten zu arbeiten, ohne die grundlegenden Arbeitsabläufe zu ändern, die bereits von Git bekannt und geschätzt sind.
Anwendungsfälle für Git LFS
Git LFS eignet sich also insbesondere, wenn in Git-Repositorien große Dateien gespeichert werden müssen. Dabei ist die Definition von „groß“ relativ und hängt von verschiedenen Faktoren ab, einschließlich der Größe und Kapazität des Systems, welches das Repository beheimatet. Im Allgemeinen lässt sich aber sagen, dass jede Datei, die mehrere Megabyte groß ist, als groß genug betrachtet werden könnte, um Git LFS in Betracht zu ziehen. Typische Anwendungsfälle für Git LFS sind daher:- Software- und Spieleentwicklung: In diesen Bereichen werden oft Mediendateien wie Grafiken, Audiodateien und 3D-Modelle verwendet, die sehr groß sein können.
- Wissenschaftliche Forschung und Datenanalyse: Forscher und Datenanalysten arbeiten oft mit großen Datensätzen, die viele Gigabyte oder sogar Terabyte groß sein können. Git LFS kann es ermöglichen, diese Daten in einem Git Repository zu speichern, ohne dass die Leistung leidet.
- Multimedia-Produktion: Bei der Produktion von Filmen, Musik und anderen Medienprodukten entstehen oft große Dateien wie unkomprimierte Audio- und Videodateien, hochauflösende Bilder und andere Ressourcen.
Funktionsweise von Git LFS
Git speichert, wie gesagt, jede Version jeder Datei in einem Projekt. Wird eine Datei geändert und ein neuer Commit erstellt, speichert Git die gesamte neue Version. Bei kleinen Textdateien, wie sie in den meisten Codeprojekten vorherrschen, ist dies äußerst effizient. Bei großen Dateien jedoch, besonders wenn sie oft geändert werden, kann dies schnell zu einer massiven Ausweitung des Repositorys führen.Die Pointer-Datei, die Git LFS anstatt dessen verwendet, ist eine Textdatei mit Informationen über die eigentliche Datei, einschließlich des Speicherorts und der Größe. Die ursprüngliche große Datei wird dann in einem separaten Speicherbereich gespeichert, dem sogenannten LFS Store. Dieser Store kann sich auf dem gleichen System befinden oder auf einem externen Server.Wird ein Repository geklont oder wird eine Datei ausgecheckt, lädt Git nur die Pointer-Dateien herunter. Die großen Dateien werden nur bei Bedarf heruntergeladen, wenn tatsächlich Zugriff auf diese Dateien gewünscht wird. Dies macht das Klonen und Arbeiten mit dem Repository viel schneller und effizienter.Die Verwendung von Git LFS ist insofern transparent, weil im Arbeitsverzeichnis immer noch die großen Dateien zu sehen sind, als ob die Dateien dort tatsächlich vorhanden wären. Git LFS kümmert sich im Hintergrund um die Verwaltung der Pointer-Dateien und des LFS Store.Das Tool ermöglicht es also, weiterhin Git wie gewohnt zu verwenden, während es gleichzeitig das Verwalten großer Dateien stark verbessert.Installation und Konfiguration
Die Einrichtung und Konfiguration von Git Large File Storage ist ein geradliniger Prozess, der in wenigen Schritten erledigt ist. Zuerst ist Git LFS auf dem System zu installieren. Es wird als eigenständiges Paket geliefert, das auf der Website zur Verfügung steht [1]; dort gibt es Downloads für die unterschiedlichen Plattformen. Unter Windows bietet sich beispielsweise der Installer an, während unter Linux oder unter macOS der bereitgestellte Befehl im Terminal auszuführen ist. Beim Schreiben dieses Artikels war die Version 3.3.3 aktuell, die Ende November 2022 veröffentlicht wurde. Git LFS selbst ist Open Source; der Quellcode steht bei GitHub zur Verfügung und nutzt die MIT-Lizenz [2].Nach der Installation ist eine Aktivierung in einem Repository notwendig. Befindet man sich in einem Repository, reicht es aus, den folgenden Befehl auszuführen:? git lfs install
Dadurch ist Git LFS für das aktuelle Repository aktiviert, was die Ausgabe auf der Konsole bestätigt:
Updated Git hooks.
Git LFS initialized.
Nach der Aktivierung lassen sich Dateien mit dem Tool verfolgen und generell verwalten, wie die nachfolgenden Beispiele zeigen.Eine Tätigkeit, die bei dieser Konfiguration durchgeführt wird und auf die in der Konsolen-Ausgabe hingewiesen wird, sind die aktualisierten Git-Hooks. Hier sind Anpassungen notwendig, damit umfangreiche Dateien speziell behandelt werden können. So wird beispielsweise das Pre-push-Skript angepasst, um dort Befehle für Git LFS zu hinterlegen.
Ein Repository mit Git LFS erstellen
Ein Repository mit Git LFS zu erstellen besteht im Wesentlichen aus dem Einrichten eines normalen Git-Repositorys und der anschließenden Aktivierung von Git LFS für bestimmte Dateitypen. Die Installation und Aktivierung sind damit erledigt.Was zur Einrichtung in einem Repository ebenfalls gehört, ist das Tracking bestimmter Dateitypen. Das folgende Befehlsbeispiel aktiviert Git LFS für alle JPG-Dateien:? git lfs track "*.jpg"
Von nun an werden alle JPG-Dateien, die diesem Repository hinzugefügt werden, automatisch mit Git LFS getrackt. Der Befehl hat zudem eine Datei mit Namen .gitattributes im Repository erstellt oder aktualisiert. Sie enthält die Regeln für die Dateitypen, die mit Git LFS getrackt werden sollen. Es ist sinnvoll, diese Datei im Repository zu committen, damit andere Nutzer, die das Repository klonen, die gleichen Git-LFS-Regeln verwenden können. Das lässt sich durch einfaches Hinzufügen der Datei zu Git bewerkstelligen:
? git add .gitattributes
? git commit -m "Add .gitattributes"
? git push
Nun ist das Git-Repository eingerichtet, um mit Git LFS zu arbeiten. Zu beachten ist, dass der Befehl git lfs track lediglich auf die zukünftig zum Repository hinzugefügten Dateien angewendet wird. Wenn bereits vorhandene Dateien getrackt werden sollen, sind diese erneut zu committen.
Dateien mit Git LFS tracken
Das Tracking eines einzelnen Dateityps war oben bereits zu sehen. Um alle JPG-Dateien zu erfassen, ist der folgende Befehl nötig:? git lfs track "*.jpg"
Damit der Befehl komfortabler zu nutzen ist, lassen sich auch mehrere Dateitypen in einem einzigen Befehl angeben, in dem diese durch Leerzeichen getrennt sind:
? git lfs track "*.png" "*.jpg" "*.pdf"
Dieser Befehl lässt Git LFS alle PNG-, JPG- und PDF-Dateien nachverfolgen. Die Ausgabe auf dem Terminal bestätigt dann, was durch ihn verändert wurde, wie die folgende Ausgabe zeigt:
Tracking "*.png"
"*.jpg" already supported
Tracking "*.pdf"
Korrekterweise wurden PNG- und PDF-Dateien neu getrackt, während Git LFS bemerkt hat, dass das für JPG-Dateien bereits der Fall ist.Wenn von Interesse ist, welche Dateien gerade von Git LFS getrackt werden, ist der track-Befehl hilfreich:
? git lfs track
Er zeigt eine Liste aller Dateitypen an, die derzeit von Git LFS getrackt werden, wie die Ausgabe auf der Konsole zeigt:
Listing tracked patterns
*.jpg (.gitattributes)
*.pdf (.gitattributes)
*.png (.gitattributes)
Listing excluded patterns
Diese einfache Befehle ermöglichen es, Dateien über Git LFS zu verfolgen und herauszufinden, was bereits getrackt wird.
Pull und Checkout
Der Pull- und Checkout-Prozess mit Git Large File Storage funktioniert weitgehend genauso wie in einem normalen Git-Verzeichnis, da Git LFS nahtlos in Git eingebunden ist. Dennoch gibt es einige Besonderheiten, die zu beachten sind. Beim Klonen einer Ablage über git clone gibt Git eine Meldung aus, dass es Git-LFS-Dateien herunterlädt.Wenn auf einen neuen Branch gewechselt oder eine ältere Version einer Datei ausgecheckt wird, kommt der übliche git checkout-Befehl zum Einsatz. Git LFS stellt dabei sicher, dass die richtigen Versionen der umfangreichen Dateien bereitgestellt werden.Um die jüngsten Änderungen von einem entfernten Repository zu beschaffen, ist der gewohnte git pull-Befehl von Nutzen. Git LFS lädt automatisch die neuen Versionen der großen Dateien, die sich noch nicht auf dem System befinden.Es ist wichtig zu beachten, dass Git LFS die großen Dateien nach Bedarf herunterlädt. Das bedeutet, dass es die großen Dateien erst herunterlädt, wenn ein Zugriff auf diese Dateien erfolgt, etwa beim Wechseln des Entwicklungszweigs.Das kann unschön sein, wenn keine stabile Verbindung zum Internet besteht, beispielsweise auf Reisen. Dann kann man sich mit diesem Befehl behelfen:? git lfs pull
Dieser Befehl lädt alle umfangreichen Dateien sofort herunter, die sich noch nicht auf dem System befinden, unabhängig davon, ob die Dateien gerade benötigt werden oder nicht.
Commit und Push
Nachdem Dateien zum Codeverzeichnis hinzugefügt sind und Git LFS für diese Dateien aktiviert ist, lassen sich die Dateien, genauer gesagt die Änderungen im Repository, committen und zum entfernten Repository pushen. Dieser Prozess ist im Wesentlichen der Gleiche wie bei normalen Git-Repositories und nutzt die Befehle git add, git commit und git push, nur mit dem Unterschied, dass das Tool die umfangreichen Dateien automatisch im Hintergrund behandelt.Git LFS kümmert sich um den Rest. Es lädt die großen Dateien in den oben erwähnten speziellen LFS-Speicher hoch und aktualisiert die kleinen Platzhalterdateien im Repository, um auf die neuen Versionen der großen Dateien zu verweisen. Alle Nutzer, die das Codeverzeichnis klonen oder die neuen Änderungen „pullen“, erhalten dann automatisch die richtigen Versionen der großen Dateien, wenn sie diese benötigen.Die (Fehler-)Historie in Git LFS
Die Git-LFS-Erweiterung verfügt über eine eigene Fehlerhistorie, die aufgetretene Fehler protokolliert. Sie lässt sich durchsuchen, um Angaben über mögliche Fehlerquellen zu erhalten. Um die LFS-Historie anzuzeigen, genügt der logs-Befehl [3]:? git lfs logs last
Ist kein Fehler erfasst, wird das auf der Konsole vermerkt. Ansonsten zeigt sich die Fehlermeldung.Zudem lässt sich überprüfen, wie viel Speicherplatz die LFS-Dateien insgesamt verbrauchen. Das geschieht über das Kommando ls-files mit unterschiedlichen Parametern. Ohne Parameter werden die IDs und die getrackten Dateien dazu angezeigt. Befehl und Ausgabe sehen so aus:
? git lfs ls-files
56ef04e3a9 * 20mb.jpg
9e5aefbc43 * 30mb.jpg
Sind weitere Details von Interesse, ist beispielsweise das Argument -s spannend, das zur folgenden Ausgabe auf der Kommandozeile führt:
? git lfs ls-files -s 56ef04e3a9 * 20mb.jpg (21 MB)
9e5aefbc43 * 30mb.jpg (31 MB)
Auf diese Weise lässt sich schnell prüfen, wie viel Speicher verbraucht wird, was bei Repositorien mit aktivem Git LFS nicht unwichtig ist. Die zusätzlich getrackten umfangreichen Dateien können zu einem erheblichen Speicherverbrauch beitragen.Zu beachten ist, dass der Befehl git lfs logs möglicherweise nicht auf allen Systemen verfügbar ist, da er nicht Teil der Standardinstallation von Git LFS ist. Falls der Befehl auf dem eigenen System nicht vorhanden ist, lässt sich stattdessen git lfs ls-files verwenden, um Informationen über die getrackten LFS-Dateien zu erhalten.
Dateien in Git LFS löschen
Um Dateien, die von Git LFS überwacht werden, zu entfernen, sind diese Dateien aus dem Repository zu entfernen und dieser Änderungsstand zu committen und zu pushen. Dieser Prozess ähnelt dem Löschen normaler Dateien in Git, aber es gibt einige zusätzliche Überlegungen für LFS-Dateien.Einmal angenommen, die Datei 20mb.jpg aus dem Beispiel-Repository soll gelöscht werden:? git rm "20mb.jpg"
Damit ist die Datei aus dem Dateisystem gelöscht und die Änderung auch direkt Git mitgeteilt. Das erspart den Weg über das Löschen der Dateien, um die Änderung später über git add/rm auch der Versionsverwaltung mitzuteilen. Jetzt fehlt noch ein Commit und ein Push:
? git commit -am "Remove 20mb.jpg file."
? git push
Ganz wichtig ist an dieser Stelle anzumerken, dass das Entfernen einer LFS-Datei aus dem lokalen Codeverzeichnis und dem entfernten Repository nicht bedeutet, dass die Datei vollständig aus dem LFS-Speicher verschwindet. Git LFS behält alte Versionen von Dateien für den Fall, dass diese in der Zukunft benötigt werden. Auch das kostet im Zweifel viel Speicherplatz.Um eine LFS-Datei vollständig aus dem LFS-Speicher zu entfernen, ist der Befehl git lfs prune zu verwenden. Er entfernt alle LFS-Dateien, die nicht von aktuellen oder kürzlich gecheckten Branches referenziert werden:
? git lfs prune
Die Ausgabe sieht bei unserem exemplarischen Repository dann wie im folgenden Beispiel aus:
prune: 2 local objects,
1 retained, done.
prune: Deleting objects:
100% (1/1), done.
Bei diesem Befehl ist allerdings Vorsicht geboten, da er sich nicht rückgängig machen lässt. Einmal entfernte Dateien sind nämlich nicht wiederherzustellen, es sei denn, diese Dateien sind noch auf einem anderen System vorhanden.
Vor- und Nachteile von Git LFS
Git LFS bietet eine Reihe von Vorteilen, die es zu einer idealen Lösung für die Verwaltung großer Dateien in Git-Projekten machen. Dennoch gibt es auch einige Einschränkungen, die bei der Entscheidung für oder gegen die Nutzung des Tools berücksichtigt werden sollten. Die Vorteile wurden schon öfter genannt: Es ist zum einen die effiziente Verwaltung großer Dateien: Sie werden außerhalb des Git-Repositorys gespeichert, wodurch die Größe und die Leistung des Repositorys nicht beeinträchtigt werden. Zum anderen ist es die transparente Verwendung: Die Trennung der großen Dateien vom eigentlichen Git-Repository ist für den Endanwender nicht sichtbar, es erscheint so, als ob die großen Dateien sich direkt im Repository befinden, auch wenn sie tatsächlich separat gespeichert sind. Ein weiterer Vorteil ist die nahtlose Integration: Als Erweiterung zu Git funktioniert das Tool mit den vorhandenen Git-Arbeitsabläufen. Es erfordert keine wesentlichen Änderungen an der Art und Weise, wie der Nutzer mit Git arbeitet.Bei den Nachteilen sind folgende Dinge zu berücksichtigen:- Zusätzlicher Speicherbedarf: Da die großen Dateien separat gespeichert werden, erfordert Git LFS zusätzlichen Speicherplatz. Dies kann ein Problem sein, wenn der Speicherplatz begrenzt ist oder wenn sehr große Dateien gehandhabt werden müssen.
- Begrenzter Support: Obwohl Git LFS von vielen bekannten Git-Repository-Hosting-Diensten wie GitHub, GitLab und Bitbucket unterstützt wird, gibt es auch Dienste und Tools, die Git LFS nicht oder nur eingeschränkt unterstützen.
- Komplexität: Obwohl Git LFS einfach zu verwenden ist, kann es in manchen Situationen, wie beispielsweise beim Umgang mit sehr großen Dateien oder komplexen Projekten, eine zusätzliche Ebene der Komplexität hinzufügen.
Vergleich mit ähnlichen Tools
Git LFS ist nicht die einzige Lösung zur Verwaltung großer Dateien in Versionskontrollsystemen. Es gibt auch andere Tools und Ansätze, die ähnliche Probleme lösen:- Git Annex: Dies ist ein weiteres Tool zur Verwaltung großer Dateien in Git [4]. Wie Git LFS verwendet auch Git Annex einen ähnlichen Ansatz, indem es Pointer-Dateien anstelle der eigentlichen Dateien im Repository speichert. Ein wichtiger Unterschied besteht jedoch darin, wie die beiden Tools die tatsächlichen Dateien verwalten. Während Git LFS die Dateien in einem zentralen Speicher ablegt, kann Git Annex die Dateien auf mehreren entfernten Speicherorten, sogenannten Remotes, verwalten. Dies kann in bestimmten Situationen von Vorteil sein, beispielsweise bei der Arbeit in verteilten Teams.
- Subversion (SVN): Im Gegensatz zu Git, das ein verteiltes Versionskontrollsystem ist, handelt es sich bei Subversion um ein zentrales System [5]. Eine Stärke von SVN ist, große Dateien und Binärdateien effizient zu verwalten. SVN speichert nur die Differenzen zwischen den Dateiversionen und nicht jede einzelne Version der Datei, was bei großen Dateien zu erheblichen Speichereinsparungen führen kann. Allerdings fehlen SVN die vielen Vorteile eines verteilten Systems wie Git, wie etwa die Möglichkeit, offline zu arbeiten oder mehrere gleichzeitig bestehende Zweige zu verwalten.
- Perforce (P4): Perforce ist ein weiteres zentrales Versionskontrollsystem, das für seine Leistungsfähigkeit bei der Verwaltung großer Dateien und großer Codebasen bekannt ist [6]. Es kommt bei vielen großen Unternehmen und in der Spieleentwicklung zum Einsatz. Wie SVN bietet auch Perforce einige Vorteile bei der Handhabung großer Dateien, aber es fehlen ebenfalls die Vorteile eines verteilten Systems wie Git.
GitHub und Git LFS
Als einer der am weitesten verbreiteten Online-Repository-Hosting-Dienste für Git unterstützt GitHub nativ Git LFS. Das macht es zu einer idealen Plattform für Entwickler, welche die Vorteile von Git LFS in Projekten nutzen wollen.Nachdem Git LFS im lokalen Repository eingerichtet wurde, wie es die obigen Abschnitte beschrieben haben, kann GitHub die mit Git LFS getrackten Dateien ohne zusätzliche Konfiguration erkennen und verarbeiten. Werden Commits auf GitHub wie erläutert gepusht, werden die Pointer-Dateien im Repository gespeichert und die umfangreichen Dateien werden in den LFS-Speicher von GitHub hochgeladen.Auf der GitHub-Oberfläche sieht es – auch das wurde schon erwähnt – so aus, als ob die großen Dateien direkt im Repository gespeichert wären (Bild 1). Wenn der Nutzer auf eine mit Git LFS getrackte Datei in GitHub klickt, ist jedoch zu sehen, dass GitHub die Datei als „Stored with Git LFS“ kennzeichnet. Dies ist ein Hinweis darauf, dass die Datei tatsächlich im LFS-Speicher gespeichert ist, wie Bild 2 zeigt.
Die Oberflächeeines Git-Repositorys mit Git-LFS-Unterstützung in GitHub(Bild 1)
Autor
Der Hinweis auf Git LFSin den Details einer Datei im Repository(Bild 2)
Autor
GitHub bietet jedem Nutzer eine begrenzte Menge an kostenlosem Speicherplatz für Git-LFS-Dateien. Sollte mehr Speicherplatz nötig sein, lässt sich dieser zusätzlich bei GitHub kaufen. Das war selbst beim Demo-Repository zu sehen. Bild 3 zeigt die Fehlermeldung, die erscheint, wenn zu viele umfangreiche Dateien im Repository vorhanden sind. Mit einigen Dateien weniger und damit auch mit weniger Speicherverbrauch funktioniert der Upload dann, wie Bild 4 zeigt.
Fehlermeldungenbei git push, wenn das Repository (Git LFS) zu umfangreich ist(Bild 3)
Autor
Erfolgreicher Pushdes Repositorys (Git LFS) zu GitHub(Bild 4)
Autor
Wie schon des Öfteren angemerkt: Wenn jemand ein Repository klont oder Dateien auscheckt, so werden nicht die großen Dateien heruntergeladen, sondern nur die Pointer-Dateien. Die eigentlichen, großen Dateien werden erst heruntergeladen, wenn der Nutzer versucht, auf sie zuzugreifen. Im Zweifel ist das den anderen Nutzern proaktiv mitzuteilen, weil es unter Umständen nicht bekannt ist.
Die Zukunft von Git LFS
Die Zukunft von Git LFS erscheint vielversprechend, da immer mehr Entwickler auf die Notwendigkeit stoßen, große Dateien in Git-Projekten zu verwalten. Dennoch sind in der Zukunft einige Verbesserungen denkbar:- Tiefere Integration in Git: Git LFS ist bereits gut in Git eingebunden, es ist jedoch möglich, dass die Zukunft eine noch engere Integration bringen wird. Dies könnte beispielsweise in Form von Verbesserungen der Nutzerfreundlichkeit erfolgen, wie etwa bessere Möglichkeiten zum Verwalten und Anzeigen von mit Git LFS getrackten Dateien innerhalb von Git.
- Breitere Unterstützung durch Hosting-Dienste: Obwohl viele der gängigen Git-Repository-Hosting-Dienste wie zum Beispiel GitHub, Bitbucket und GitLab bereits Git LFS unterstützen, zeigt sich die Unterstützung in Zukunft als durchaus noch ausbaufähig. Dies kann durch zusätzliche Funktionen oder durch die Integration von Git LFS in mehr Hosting-Dienste erreicht werden.
- Bessere Leistung: Da große Dateien naturgemäß mehr Ressourcen verbrauchen als kleinere Dateien, könnte es in der Zukunft Verbesserungen der Leistung von Git LFS geben. Dafür könnten effizientere Algorithmen für das Speichern und den Abruf großer Dateien oder die bessere Nutzung von Hardware-Ressourcen verantwortlich sein.
- Mehr Anwendungsfälle: Momentan wird Git LFS hauptsächlich von Softwareentwicklern und von Kreativen, wie zum Beispiel Spieleentwicklern oder Grafikdesignern, verwendet. In der Zukunft könnte sich die Nutzung von Git LFS jedoch auf weitere Anwendungsfälle ausweiten, beispielsweise auf wissenschaftliche Daten, die ebenfalls sehr umfangreich sein können.
Fazit
Git Large File Storage (Git LFS) hat sich als eine äußerst wertvolles Hilfsmittel für Git erwiesen, welches das Verwalten großer Dateien effizient und nutzerfreundlich macht. Es adressiert die ansonsten schwierige Aufgabe, große Dateien in einem System zu verwalten, das ursprünglich nicht für diese Art von Inhalten konzipiert wurde.Die Vorteile sind deutlich. Die effiziente Handhabung großer Dateien, die nahtlose Integration in vorhandene Git-Arbeitsabläufe und die Unterstützung durch gängige Hosting-Dienste wie GitHub machen es zu einem unverzichtbaren Werkzeug für viele Entwickler und Teams.Aber wie bei jedem Werkzeug gibt es auch Nachteile. Das Bedürfnis nach zusätzlichem Speicherplatz, der begrenzte Support durch andere Tools oder Dienste und die potenzielle zusätzliche Komplexität sind Punkte, die man im Auge behalten sollte. Darüber hinaus aber hat die nahtlose Integration von Git LFS in GitHub die Arbeit mit großen Dateien in Projekten erheblich vereinfacht.Insgesamt ist die Erweiterung Git LFS eine leistungsfähige Erweiterung für Git, welche die effiziente Verwaltung großer Dateien ermöglicht. Es erweist sich als ein wichtiger Fortschritt in der Versionskontrolle und wird wahrscheinlich eine immer wichtigere Rolle in vielen verschiedenen Anwendungsbereichen spielen.Fussnoten
- Git Large File Storage, https://git-lfs.com
- Git Large File Storage, GitHub-Repository, http://www.dotnetpro.de/SL2308LargeFile1
- Debian Man-Pages, git-lfs-logs, http://www.dotnetpro.de/SL2308LargeFile2
- git-annex, https://git-annex.branchable.com
- Subversion, https://subversion.apache.org
- Perforce, http://www.dotnetpro.de/SL2308LargeFile3
