Verwalten großer Binärdateien mit Git

StackOverflow https://stackoverflow.com/questions/540535

Frage

Ich suche nach Meinungen zum Umgang mit großen Binärdateien, von denen mein Quellcode (Webanwendung) abhängt.Wir diskutieren derzeit mehrere Alternativen:

  1. Kopieren Sie die Binärdateien manuell.
    • Profi:Nicht sicher.
    • Kontra:Ich bin strikt dagegen, da es die Wahrscheinlichkeit von Fehlern beim Einrichten einer neuen Site/Migration der alten Site erhöht.Stellt eine weitere Hürde dar, die es zu nehmen gilt.
  2. Verwalten Sie sie alle mit Git.
    • Profi:Entfernt die Möglichkeit, das Kopieren einer wichtigen Datei zu „vergessen“.
    • Kontra:Bläht das Repository auf und verringert die Flexibilität bei der Verwaltung der Codebasis sowie bei Checkouts, Klonen usw.wird eine ganze Weile dauern.
  3. Separate Repositorys.
    • Profi:Das Auschecken/Klonen des Quellcodes geht schneller als je zuvor und die Bilder werden ordnungsgemäß in ihrem eigenen Repository archiviert.
    • Kontra:Entfernt die Einfachheit des Habens der einzig wahre Git-Repository für das Projekt.Es führt sicherlich einige andere Dinge ein, über die ich noch nicht nachgedacht habe.

Welche Erfahrungen/Gedanken habt ihr diesbezüglich?

Auch:Hat jemand Erfahrung mit mehreren Git-Repositories und deren Verwaltung in einem Projekt?

Bei den Dateien handelt es sich um Bilder für ein Programm, das PDFs mit diesen Dateien generiert.Die Dateien werden sich nicht sehr oft ändern (wie in Jahren), aber sie sind für ein Programm sehr relevant.Ohne die Dateien funktioniert das Programm nicht.

War es hilfreich?

Lösung

Wenn das Programm nicht ohne die Dateien arbeiten scheint es, wie sie in einem separaten Repo-Spaltung ist eine schlechte Idee. Wir haben große Test-Suiten, die wir in einem separaten Repo brechen, aber das sind wirklich „Hilfs“ Dateien.

Allerdings können Sie in der Lage sein, die Dateien in einem separaten Repo zu verwalten und verwenden Sie dann git-submodule in Ihr Projekt in einer vernünftigen Art und Weise zu ziehen. Also, würden Sie noch haben die volle Geschichte aller Ihrer Quelle, sondern, wie ich es verstehe, dann würden Sie haben nur die eine relevante Änderung Ihrer Bilder Submodul. Die git-submodule Anlage sollten Sie die richtige Version des Codes in Übereinstimmung mit der korrekten Version der Bilder halten helfen.

Hier ist eine gute Einführung in den Submodule von Git Buch .

Andere Tipps

Ich entdeckte git-Anhang vor kurzem die ich genial finden. Es wurde für die Verwaltung großer Dateien effizient gestaltet. Ich benutze es für mein Foto / Musik (etc.) Sammlungen. Die Entwicklung von git-Anlage ist sehr aktiv. Der Inhalt der Dateien kann von dem Git Repository entfernt wird, werden nur die Baumhierarchie wird durch Git (durch symbolische Links) verfolgt. Um jedoch den Inhalt der Datei zu bekommen, ein zweiter Schritt ist notwendig, nach dem Ziehen / Schieben, z. 

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Es gibt viele Befehle zur Verfügung, und es gibt eine große Dokumentation auf der Website. Ein Paket ist auf Debian .

Eine andere Lösung, seit April 2015 Git Large Dateiablage (LFS) (von GitHub).

Es verwendet git-LFS (siehe < a href = "https://git-lfs.github.com/" rel = "noreferrer"> git-lfs.github.com ) und getestet mit einem Server es unterstützt: LFS-Test-Server :
Sie können Metadaten speichern nur im git Repo, und die großen Datei an anderer Stelle.

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb -8fc165e5ece4.gif

Hier finden Sie aktuelle git bup die ein Git-Erweiterung ist intelligent zu speichern große Binärdateien in einem Git Repository.

Sie würden wollen, dass es als Submodul haben, aber Sie werden nicht immer schwer Repository sorgen müssen um zu handhaben. Einer ihrer Probenanwendungsfälle ist die Speicherung VM-Images in Git.

Ich habe nicht wirklich eine bessere Kompressionsraten gesehen, aber meine Repositories haben nicht wirklich große Binärdateien in ihnen.

Ihre Ergebnisse können variieren.

können Sie auch git-Fett . Ich mag, dass es nur auf Lager Python hängt und rsync . Es unterstützt auch den üblichen Git-Workflow mit den folgenden selbsterklärend Befehlen: 

git fat init
git fat push
git fat pull

Darüber hinaus müssen Sie in einer .gitfat Datei in Ihrem Repository überprüfen und Ihre .gitattributes ändern, um die Dateierweiterungen geben Sie git fat verwalten möchten.

Sie ein binäres fügen Sie den normalen git add verwenden, was wiederum git fat Regeln auf der Grundlage Ihrer gitattributes aufruft.

Schließlich hat es den Vorteil, dass der Ort, an dem Ihre Binärdateien tatsächlich gespeichert sind, können über Repositories und Benutzer und alles unterstützt geteilt werden rsync der Fall ist.

UPDATE: Verwenden Sie git-Fett nicht, wenn Sie eine Git-SVN-Brücke verwenden. Es wird die Binär-Dateien von Ihrer Subversion-Repository entfernt enden. Wenn Sie jedoch eine reine Git-Repository verwenden, es funktioniert wunderbar.

würde ich Submodule (als Pat Notz) oder zwei verschiedene Repositories. Wenn Sie zu oft Ihre binären Dateien ändern, dann würde ich versuchen, die Auswirkungen des großen Repository zu minimieren, um die Reinigung der Geschichte:

hatte ich ein sehr ähnliches Problem vor einigen Monaten: ~ 21 GB MP3-Dateien, nicht klassifiziert (schlechte Namen, schlechte ıd3 ist, weiß nicht, ob ich die MP3-Datei oder nicht wollen ...) und repliziert auf drei Computern .

habe ich eine externe Festplatte mit der Haupt-Git-Repository, und ich geklont es in jeden Computer. Dann fing ich an, sie in der gewöhnlichen Art und Weise zu klassifizieren (Schieben, Ziehen, Zusammenführen ... löschen und oft umbenennen).

Am Ende hatte ich nur ~ 6 GB MP3-Dateien und ~ 83 GB im .git Verzeichnis. Ich benutzte git-write-tree und git-commit-tree eine neue verpflichten zu schaffen, ohne Vorfahren zu begehen, und begann eine Niederlassung zeigt auf, dass begehen. Die „git log“ für diesen Zweig zeigte nur einen begehen.

Dann habe ich löschte den alten Zweig, behielt nur die neue Filiale, löschte die ref-Logs, und führen Sie "git prune": danach, meine .git Ordner gewichtet nur ~ 6 GB ...

Sie könnten „Säuberung“ der große Repository von Zeit zu Zeit auf die gleiche Weise: Ihre „git clone“ 's wird schneller sein

.

Meiner Meinung nach, wenn Sie wahrscheinlich diese großen Dateien oft zu ändern, oder wenn Sie beabsichtigen, eine Menge git clone oder git checkout zu machen, dann sollten Sie ernsthaft in Erwägung ziehen ein anderes Git Repository (oder vielleicht eine andere Möglichkeit, diese Dateien zugreifen ).

Aber wenn Sie wie wir funktionieren, und wenn Sie Ihre binären Dateien werden nicht häufig geändert, dann wird der erste Klon / Kasse wird lang sein, aber nach, dass es so schnell sein sollte, wie Sie wollen (die Benutzer unter Berücksichtigung der ersten halten mit geklonte Repository sie hatten).

Die Lösung, die ich vorschlagen möchte, basiert auf verwaisten Zweigen und einem leichten Missbrauch des Tag-Mechanismus und wird im Folgenden als *Orphan Tags Binary Storage bezeichnet (OTABS)

TL;DR 12.01.2017 Wenn Sie Githubs LFS oder einen anderen Drittanbieter verwenden können, sollten Sie dies auf jeden Fall tun.Wenn Sie das nicht können, dann lesen Sie weiter.Seien Sie gewarnt, diese Lösung ist ein Hack und sollte als solcher behandelt werden.

Wünschenswerte Eigenschaften von OTABS

  • es ist ein reiner Idiot Und Nur Idiot Lösung – die Arbeit wird ohne Software von Drittanbietern (wie Git-Annex) oder Infrastruktur von Drittanbietern (wie LFS von Github) erledigt.
  • Es speichert die Binärdateien effizient, d.h.Es bläht den Verlauf Ihres Repositorys nicht auf.
  • git pull Und git fetch, einschließlich git fetch --all sind immer noch Bandbreiteneffizient, d.h.Nicht alle großen Binärdateien werden standardmäßig von der Fernbedienung abgerufen.
  • es funktioniert weiter Windows.
  • Es speichert alles in einem einzelnes Git-Repository.
  • es ermöglicht Streichung von veralteten Binärdateien (im Gegensatz zu bup).

Unerwünschte Eigenschaften von OTABS

  • es macht git clone potenziell ineffizient (aber nicht unbedingt, abhängig von Ihrer Nutzung).Wenn Sie diese Lösung einsetzen, müssen Sie möglicherweise Ihre Kollegen zur Verwendung beraten git clone -b master --single-branch <url> anstatt git clone.Dies liegt daran, dass Git Clone standardmäßig buchstäblich klont gesamte Repository, einschließlich Dingen, für die Sie Ihre Bandbreite normalerweise nicht verschwenden möchten, wie z. B. nicht referenzierte Commits.Genommen von SO 4811434.
  • es macht git fetch <remote> --tags Bandbreite ineffizient, aber nicht unbedingt ineffizient in Speicher.Sie können Ihren Kollegen jederzeit davon abraten, es zu verwenden.
  • Sie müssen regelmäßig a verwenden git gc Trick, um Ihr Repository von allen Dateien zu bereinigen, die Sie nicht mehr benötigen.
  • es ist nicht so effizient wie bup oder git-bigfiles.Aber es ist entsprechend besser für das, was Sie tun möchten, und eher von der Stange.Es ist wahrscheinlich, dass Sie mit Hunderttausenden kleiner Dateien oder mit Dateien im Gigabyte-Bereich auf Probleme stoßen, aber lesen Sie weiter, um Workarounds zu finden.

Hinzufügen der Binärdateien

Bevor Sie beginnen, stellen Sie sicher, dass Sie alle Ihre Änderungen übernommen haben, Ihr Arbeitsbaum auf dem neuesten Stand ist und Ihr Index keine nicht übernommenen Änderungen enthält.Für den Fall einer Katastrophe könnte es eine gute Idee sein, alle Ihre lokalen Zweigstellen auf Ihre Fernbedienung (Github usw.) zu übertragen.

  1. Erstellen Sie einen neuen verwaisten Zweig. git checkout --orphan binaryStuff wird den Zweck erfüllen.Dadurch entsteht ein Zweig, der vollständig von allen anderen Zweigen getrennt ist, und der erste Commit, den Sie in diesem Zweig durchführen, hat kein übergeordnetes Element, was ihn zu einem Root-Commit macht.
  2. Bereinigen Sie Ihren Index mit git rm --cached * .gitignore.
  3. Atmen Sie tief ein und löschen Sie den gesamten Arbeitsbaum mit rm -fr * .gitignore.Intern .git Verzeichnis bleibt unberührt, da das * Platzhalter passt nicht dazu.
  4. Kopieren Sie Ihre VeryBigBinary.exe oder Ihr VeryHeavyDirectory/.
  5. Fügen Sie es hinzu und übernehmen Sie es.
  6. Jetzt wird es knifflig – wenn Sie es als Zweig in die Remote-Umgebung verschieben, werden alle Ihre Entwickler es beim nächsten Aufruf herunterladen git fetch ihre Verbindung verstopfen.Sie können dies vermeiden, indem Sie ein Tag anstelle eines Zweigs verschieben.Dies kann sich dennoch auf die Bandbreite und den Dateisystemspeicher Ihres Kollegen auswirken, wenn dieser die Angewohnheit hat, zu tippen git fetch <remote> --tags, aber lesen Sie weiter, um eine Problemumgehung zu finden.Fahre fort und git tag 1.0.0bin
  7. Drücken Sie Ihr Waisen-Tag git push <remote> 1.0.0bin.
  8. Damit Sie Ihren Binärzweig nicht versehentlich verschieben, können Sie ihn löschen git branch -D binaryStuff.Ihr Commit wird nicht für die Garbage Collection markiert, da ein verwaistes Tag darauf verweist 1.0.0bin reicht aus, um es am Leben zu erhalten.

Auschecken der Binärdatei

  1. Wie kann ich (oder meine Kollegen) die Datei VeryBigBinary.exe in den aktuellen Arbeitsbaum auschecken?Wenn Ihr aktueller Arbeitszweig beispielsweise „Master“ ist, können Sie dies einfach tun git checkout 1.0.0bin -- VeryBigBinary.exe.
  2. Dies schlägt fehl, wenn Sie nicht über das Orphan-Tag verfügen 1.0.0bin heruntergeladen werden. In diesem Fall müssen Sie dies tun git fetch <remote> 1.0.0bin vorweg.
  3. Sie können das hinzufügen VeryBigBinary.exe in deinen Master .gitignore, damit niemand in Ihrem Team versehentlich den Hauptverlauf des Projekts mit der Binärdatei verunreinigt.

Vollständiges Löschen der Binärdatei

Wenn Sie sich entscheiden, VeryBigBinary.exe vollständig aus Ihrem lokalen Repository, Ihrem Remote-Repository und den Repositorys Ihrer Kollegen zu löschen, können Sie einfach:

  1. Löschen Sie das Orphan-Tag auf der Fernbedienung git push <remote> :refs/tags/1.0.0bin
  2. Löschen Sie das verwaiste Tag lokal (löscht alle anderen nicht referenzierten Tags) git tag -l | xargs git tag -d && git fetch --tags.Genommen von SO 1841341 mit geringfügiger Modifikation.
  3. Verwenden Sie einen Git-GC-Trick, um Ihr jetzt nicht referenziertes Commit lokal zu löschen. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@".Außerdem werden alle anderen nicht referenzierten Commits gelöscht.Genommen von SO 1904860
  4. Wenn möglich, wiederholen Sie den Git-GC-Trick auf der Fernbedienung.Dies ist möglich, wenn Sie Ihr Repository selbst hosten, was bei einigen Git-Anbietern wie Github oder in einigen Unternehmensumgebungen möglicherweise nicht möglich ist.Wenn Sie bei einem Anbieter hosten, der Ihnen keinen SSH-Zugriff auf die Fernbedienung gewährt, lassen Sie es einfach sein.Es ist möglich, dass die Infrastruktur Ihres Anbieters Ihr nicht referenziertes Commit in kürzester Zeit bereinigt.Wenn Sie sich in einer Unternehmensumgebung befinden, können Sie Ihrer IT-Abteilung empfehlen, etwa einmal pro Woche einen Cron-Job zur Müllbeseitigung Ihrer Fernbedienung auszuführen.Unabhängig davon, ob dies der Fall ist oder nicht, wird es hinsichtlich der Bandbreite und des Speichers keine Auswirkungen auf Ihr Team haben, solange Sie Ihren Kollegen dies immer raten git clone -b master --single-branch <url> anstatt git clone.
  5. Alle Ihre Kollegen, die veraltete Orphan-Tags entfernen möchten, müssen nur die Schritte 2-3 anwenden.
  6. Anschließend können Sie die Schritte 1–8 wiederholen Hinzufügen der Binärdateien um ein neues verwaistes Tag zu erstellen 2.0.0bin.Wenn Sie sich Sorgen machen, dass Ihre Kollegen tippen git fetch <remote> --tags Sie können es tatsächlich noch einmal benennen 1.0.0bin.Dadurch wird sichergestellt, dass beim nächsten Abruf alle Tags die alten sind 1.0.0bin wird nicht referenziert und für die nachfolgende Garbage Collection (mit Schritt 3) markiert.Wenn Sie versuchen, ein Tag auf der Fernbedienung zu überschreiben, müssen Sie es verwenden -f so was: git push -f <remote> <tagname>

Nachwort

  • OTABS berührt weder Ihren Master noch andere Quellcode-/Entwicklungszweige.Die Commit-Hashes, der gesamte Verlauf und die geringe Größe dieser Zweige bleiben davon unberührt.Wenn Sie Ihren Quellcode-Verlauf bereits mit Binärdateien überladen haben, müssen Sie ihn als separate Arbeit bereinigen. Dieses Skript könnte nützlich sein.

  • Bestätigt, dass es unter Windows mit Git-Bash funktioniert.

  • Es ist eine gute Idee, a anzuwenden Reihe von Standard-Tricks um die Speicherung von Binärdateien effizienter zu gestalten.Häufiges Laufen git gc (ohne zusätzliche Argumente) sorgt dafür, dass Git den zugrunde liegenden Speicher Ihrer Dateien mithilfe binärer Deltas optimiert.Wenn es jedoch unwahrscheinlich ist, dass Ihre Dateien von Commit zu Commit gleich bleiben, können Sie binäre Deltas ganz ausschalten.Da es außerdem keinen Sinn macht, bereits komprimierte oder verschlüsselte Dateien wie .zip, .jpg oder .crypt zu komprimieren, bietet Ihnen Git die Möglichkeit, die Komprimierung des zugrunde liegenden Speichers auszuschalten.Leider ist es eine Alles-oder-Nichts-Einstellung, die sich auch auf Ihren Quellcode auswirkt.

  • Möglicherweise möchten Sie Teile von OTABS per Skript erstellen, um eine schnellere Nutzung zu ermöglichen.Insbesondere die Skriptschritte 2–3 ab Binärdateien vollständig löschen In ein update Git Hook könnte eine überzeugende, aber möglicherweise gefährliche Semantik für Git Fetch liefern („Alles abrufen und löschen, was veraltet ist“).

  • Möglicherweise möchten Sie Schritt 4 überspringen Binärdateien vollständig löschen um einen vollständigen Verlauf aller binären Änderungen auf der Fernbedienung zu behalten, was zu einer Aufblähung des zentralen Repositorys führt.Lokale Repositories bleiben im Laufe der Zeit schlank.

  • In der Java-Welt ist es möglich, diese Lösung mit zu kombinieren maven --offline um einen reproduzierbaren Offline-Build zu erstellen, der vollständig in Ihrer Versionskontrolle gespeichert ist (mit Maven ist es einfacher als mit Gradle).In der Golang-Welt ist es möglich, auf dieser Lösung aufzubauen, um Ihren GOPATH zu verwalten go get.In der Python-Welt ist es möglich, dies mit Virtualenv zu kombinieren, um eine eigenständige Entwicklungsumgebung zu erstellen, ohne bei jedem Build von Grund auf auf PyPi-Server angewiesen zu sein.

  • Wenn sich Ihre Binärdateien sehr häufig ändern, wie z. B. Build-Artefakte, ist es möglicherweise eine gute Idee, ein Skript für eine Lösung zu erstellen, die die fünf aktuellsten Versionen der Artefakte in den Orphan-Tags speichert monday_bin, tuesday_bin, ..., friday_bin, sowie ein Orphan-Tag für jede Veröffentlichung 1.7.8bin 2.0.0bin, usw.Sie können die drehen weekday_bin und löschen Sie täglich alte Binärdateien.Auf diese Weise erhalten Sie das Beste aus zwei Welten:Du behältst das gesamte Verlauf Ihres Quellcodes, sondern nur die relevant Verlauf Ihrer binären Abhängigkeiten.Es ist auch sehr einfach, die Binärdateien für ein bestimmtes Tag abzurufen ohne Erhalten des gesamten Quellcodes mit seiner gesamten Historie: git init && git remote add <name> <url> && git fetch <name> <tag> sollte es für Sie tun.

SVN scheint binäre Deltas zu verarbeiten effizienter als Git.

Ich hatte auf einem Versionierungssystem für die Dokumentation (JPEG-Dateien, PDF-Dateien und ODT-Dateien) zu entscheiden. Getestet habe ich nur eine JPEG-Datei hinzufügen und Drehen um 90 Grad viermal (Wirksamkeit von binären Deltas zu überprüfen). Git Repository wuchs um 400%. SVN Repository nur um 11% gewachsen ist.

So ist es wie SVN aussieht, ist viel effizienter mit Binärdateien.

So ist meine Wahl Git für Quellcode und SVN für binäre Dateien wie Dokumentation.

git clone --filter von Git 2,19 + flache Klone

Diese neue Option könnte schließlich die endgültige Lösung für das Binärdatei Problem, wenn die Git und GitHub Devs werden und es benutzerfreundlich genug machen (was sie wohl habe für Submodule noch nicht erreicht zum Beispiel).

Es ermöglicht tatsächlich nur Dateien und Verzeichnisse zu holen, die Sie für den Server mögen, und wurde zusammen mit einer entfernten Protokollerweiterung eingeführt.

Damit können wir zunächst einen flachen Klon tun, und dann automatisieren, die für jede Art von Build mit dem Build-System zu holen Blobs.

Es gibt sogar schon ein --filter=blob:limit<size>, die die maximale Größe Klecks erlaubt Begrenzung zu holen.

Ich habe ein minimales ausführliches Beispiel zur Verfügung gestellt, wie das Merkmal sieht aus wie unter: Wie klone ich ein Unterverzeichnis nur von einer Git-Repository?

  

Ich bin auf der Suche nach Meinungen darüber, wie große binäre Dateien zu handhaben, auf das mein Quellcode (Web-Anwendung) abhängig ist. Was sind Ihre Erfahrungen / Gedanken über das?

Ich habe persönlich laufen in Synchronisierungsfehler mit Git mit einigen meiner Cloud-Rechner einmal meine Web-Anwendungen Binärdaten gekerbt über der 3 GB Marke . Ich betrachtete BFT Repo-Reiniger zu der Zeit, aber es fühlte sich wie ein Hack. Seitdem habe ich damit begonnen, nur Dateien halten außerhalb von Git Zuständigkeitsbereich, sondern nutzt Zweck gebauten Werkzeuge wie Amazon S3 für die Verwaltung von Dateien, Versionierung und Back-up.

  

Hat jemand Erfahrung mit mehreren Git-Repositories haben und sie in einem Projekt verwalten?

Ja. Hugo Themen auf diese Weise in erster Linie verwaltet werden. Es ist ein wenig kudgy, aber es wird die Arbeit erledigt.

Mein Vorschlag ist, auf Wählen Sie das richtige Werkzeug für den Job . Wenn es für ein Unternehmen ist und Sie die Verwaltung Ihrer Kodierzeilen auf GitHub das Geld zahlen und Git-LFS verwenden. Sonst könnte man mehr kreative Möglichkeiten wie dezentrale, verschlüsselte Dateispeicher mit blockchain rel="nofollow.

Weitere Optionen sind zu berücksichtigen Minio und s3cmd .

Hier finden Sie aktuelle camlistore . Es ist nicht wirklich Git-basierte, aber ich finde es besser geeignet für das, was Sie zu tun haben.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top