it-swarm.dev

Sollten Bilder in einem Git-Repository gespeichert werden?

Sollten für ein verteiltes Team, das Git und Github als Versionskontrolle verwendet, Bilder auch im Git-Repository gespeichert werden?

Die Bilder werden größtenteils nicht geändert. Der Ordner, der sie enthält, wird nur größer, wenn Bilder hinzugefügt werden. Es besteht die Sorge, dass der Bildordner im Laufe der Zeit durch die Kombination großer oder nur vieler Bilder zu einer großen Größe wird.

Wird dies als Best Practice angesehen? Welche anderen Alternativen gibt es zum Teilen von Binärdateien, die in Projekten benötigt werden, auf die ein verteiltes Team problemlos zugreifen kann?

209
spong

Handelt es sich bei Ihren Bildern um Originalarbeiten oder können sie von einem anderen Ort wiederhergestellt werden (garantiert?)? Werden sie benötigt, um eine aus der Quelle erstellte Softwareeinheit zu versenden? Wenn sie original sind, müssen sie gesichert werden. Fügen Sie sie in Ihre Revisionskontrolle ein. Wenn sie sich nie ändern, entspricht die Platzstrafe der eines Backups und sie sind dort, wo Sie sie benötigen.

Können sie bearbeitet werden, um das Erscheinungsbild der Software versehentlich oder absichtlich zu ändern? Ja - dann MÜSSEN sie irgendwie revisionsgesteuert sein. Warum anders, wenn Sie bereits eine perfekte Lösung haben? Warum sollte man die Versionskontrolle "Kopieren und Umbenennen" aus dem dunklen Zeitalter einführen?

Ich habe gesehen, wie die Originalvorlage eines ganzen Projekts "patzig" wurde, als die MacBook-Festplatte des Grafikdesigners ausfiel, alles nur, weil jemand mit unendlicher Weisheit entschieden hatte, dass "Binärdateien nicht zur Drehzahlregelung gehören", und Grafikdesigner (zumindest diese) ) neigen nicht dazu, gut mit Backups umzugehen.

Gleiches gilt für alle Binärdateien, die die oben genannten Kriterien erfüllen.

Der einzige Grund, dies nicht zu tun, ist Speicherplatz. Ich fürchte, bei 100 Dollar/Terabyte ist diese Ausrede etwas dünn.

192
mattnz

Warum zur Hölle nicht? :) :)

Das Speichern von Binärdateien wird als schlechte Praxis angesehen, aber ich habe mir nie zu viele Sorgen um Bilder gemacht.

Im schlimmsten Fall, wenn Sie Tonnen haben, speichern Sie sie woanders oder verwenden Sie externe Geräte oder eine Erweiterung für die binäre Unterstützung. Und wenn die Bilder nicht so oft geändert werden, wo liegt dann das Problem? Sie werden kein großes fettes Delta bekommen. Und wenn sie im Laufe der Zeit entfernt werden, leidet nur Ihr Server ein wenig unter dem Speichern des Verlaufs, aber Clients sehen nichts.

Meiner Meinung nach sollten Sie sich darüber keine Sorgen machen - vorausgesetzt, Sie speichern keine GBs davon.

Was Sie jedoch tun könnten , ist, nur "Quell" -Bilder zu speichern: SVGs, LaTeX-Makros usw. ... und die endgültigen Bilder von Ihrem Build generieren zu lassen System. Das ist wahrscheinlich noch besser, wenn du kannst. Wenn nicht, dann kümmere dich nicht darum.

(Abgesehen davon glänzt Git für Textdateien, ist aber nicht das beste VCS für Bilder. Geben Sie uns mehr Kontext und Metriken, wenn Sie können)


Weitere Informationen finden Sie in den folgenden Fragen und Antworten:

66
haylem

Diese Frage ist ziemlich alt, aber dies ist eine häufig gestellte Frage, die beim Umgang mit Git auftaucht. Seit der letzten Antwort wurden bei modernen Lösungen zum Speichern großer Dateien in einem Git-Repo einige Fortschritte erzielt.

Zum Speichern großer Dateien in Git gibt es folgende Projekte:

  • git-annex - Das gibt es schon eine Weile, aber ehrlich gesagt stört seine Komplexität.
  • git-media - Keine persönlichen Erfahrungen mit diesem. Scheint auch ziemlich komplex zu sein.
  • git-fit - Ein Versuch, ein einfacheres Plugin zu erstellen. Benötigt S3-Speicher. Obwohl ich die Einfachheit schätze, ist mein Hauptanliegen mit dem Plugin, dass es ziemlich unbekannt ist und von einer Person gepflegt wird (vollständige Offenlegung, ich bin der einzige andere Committer zu diesem Zeitpunkt und es war ein triviales Problem).
  • git-lfs - Obwohl ich dies nicht ausgiebig benutzt habe, scheint es der heilige Gral zu sein. Es wird von Github unterstützt und ist verfügbar auf allen Repos ab Oktober 2015 und stellt die Komplexität der Dateiverwaltung vor Ort zur Verfügung, in der Ihre Repos gespeichert werden. Der einzige Nachteil ist, dass dies ziemlich neu ist, so dass es jenseits von Github nicht viel Unterstützung gibt, obwohl Gitlab hat auch Unterstützung , wie Gitea und Bitbucket hat angedeutet, um in Zukunft zu unterstützen .

TLDR: Wenn Sie können, verwenden Sie git-lfs , um Bilder oder andere Binärdateien in git zu speichern.

51
James McMahon

Das gesamte "Speichern Sie keine Binärdateien in der Quellcodeverwaltung" ist aus einem bestimmten Grund aufgeführt: Wenn Sie über einen zu kompilierenden Quellcode verfügen, speichern Sie nicht die eigentliche Kompilierung, sondern nur den Quellcode. Bilder und visuelle Elemente haben keine "Quelle", daher werden sie sollten in der Versionskontrolle verfolgt.

45

Ich glaube, der empfohlene Weg mit Git ist die Verwendung eines Submoduls (eingeführt in Git 1.5.3), das im Grunde ein separates Repository ist, das dem Haupt-Repository zugeordnet ist. Sie speichern Ihre Bilder (und andere binäre Assets) im Untermodul. Dies kann dann mit dem Haupt-Repository ausgecheckt oder verlassen werden, je nachdem, was erforderlich ist.

Von http://book.git-scm.com/5_submodules.html

"Die Submodul-Unterstützung von Git ermöglicht es einem Repository, als Unterverzeichnis das Auschecken eines externen Projekts zu enthalten. Submodule behalten ihre eigene Identität bei. Die Submodul-Unterstützung speichert nur den Speicherort des Submoduls und die Festschreibungs-ID, sodass andere Entwickler das enthaltende Projekt klonen (" Superprojekt ") kann problemlos alle Submodule mit derselben Revision klonen. Teilweise Überprüfungen des Superprojekts sind möglich: Sie können Git anweisen, keine, einige oder alle Submodule zu klonen."

Außerdem sollte die Größe kein wesentliches Problem sein, wenn sich die Bilder nicht häufig ändern. Sie können auch Befehle zum Beschneiden/Reduzieren der Größe ausführen, z.

git gc
git gc-aggressive
git Prune
21
Dan Diplo

Ja.

Nehmen wir an, Sie veröffentlichen die Softwareversion 1.0. Für Version 2.0 entscheiden Sie sich, alle Bilder mit Schatten zu wiederholen. Also machst du das und veröffentlicht 2.0. Dann entscheidet ein Kunde, der 1.0 verwendet und nicht auf 2.0 aktualisieren kann, dass er das Programm in einer anderen Sprache haben möchte. Sie geben Ihnen $ 1G, um es zu tun, also sagen Sie sicher. Aber in einer anderen Kultur machen einige Ihrer Bilder keinen Sinn, deshalb müssen Sie sie ändern ...

Wenn Sie Ihre Bilder in der Quellcodeverwaltung behalten möchten, ist dies einfach. Basierend auf 1.0 nehmen Sie Änderungen an Bildern (unter anderem) vor, erstellen sie und veröffentlichen sie. Wenn Sie diese nicht in der Quellcodeverwaltung hätten, hätten Sie es viel schwerer, da Sie die alten Bilder finden, ändern und dann erstellen müssten.

7
earlNameless

Wenn es Teil des Projekts ist, muss es im VCS sein. Wie Sie dies am besten erreichen, hängt möglicherweise vom VCS ab oder davon, wie Sie ein Projekt organisieren. Vielleicht ein Repo für die Designer und nur die Ergebnisse im Repo des Codierers oder nur die 'Bildquellen' (ich hatte einmal ein Projekt mit nur einer .svg-Datei und die Bilder wurden über make/inscape cli generiert).

Aber wenn ein VCS damit nicht umgehen kann oder unbrauchbar wird, würde ich sagen, dass es nicht das richtige Werkzeug für Ihren Job ist.

Bisher hatte ich keine Probleme damit, "übliche" Mengen an Grafiken (Modelle, Konzepte und Seitengrafiken) für Webprojekte in Git zu platzieren.

7
keppla

Sollten Sie Ihre Bilder in SCM speichern: ja. Ohne jeden Zweifel.

Sollten Sie Ihre Bilder in Git speichern: Dies wird schwieriger.

git ist sehr gut mit Textdateien, aber von Natur aus nicht zu heiß mit Binärdateien. Sie werden Probleme mit der Größe der übertragenen Daten haben, wenn Sie klonen oder pushen, Ihre .git-Verzeichnisse wachsen und Sie könnten beim Zusammenführen in ein richtiges Chaos geraten (dh wie können Sie 2 Bilder zusammenführen!).

Eine Antwort ist die Verwendung von Submodulen, da dies bedeutet, dass die Verbindung zwischen Ihrem Projekt und den Bildern schwächer ist. Sie müssen die Bilder also nicht so verwalten, als wären sie Teil Ihrer Quelle, behalten sie jedoch weiterhin unter Kontrolle und haben sie nicht Sorgen bei der Verzweigung - vorausgesetzt, das Teilprojekt ist nur ein "flaches" Repository von Daten, die während des üblichen Entwicklungsprozesses nicht dieselbe Abwanderung durchlaufen.

Die andere Antwort besteht darin, sie in ein anderes Projekt einzufügen, es niemals zu verzweigen und sicherzustellen, dass jeder, der sich für dieses Projekt engagiert, es sofort in den Upstream überträgt - lassen Sie niemals zwei Personen dieselbe Version der Datei ändern - Sie werden dies am schwierigsten finden Aspekt wie Git ist nicht für einen solchen nicht verteilten Workflow ausgelegt. Sie müssen altmodische Kommunikationsmethoden verwenden, um diese Regel zu erfüllen.

Eine dritte Antwort besteht darin, sie in ein völlig anderes SCM zu integrieren, das besser auf die Arbeit mit Bildern ausgerichtet ist.

5
gbjbaanb

Beachten Sie, dass die Größe bei der Antwort von @ haylem eine große Rolle spielt. Abhängig vom VCS funktioniert es möglicherweise nicht gut mit Tonnen von Bildern. Wenn Klone oder große Pushs die ganze Nacht dauern, ist es wirklich zu spät, da sich alle Bilder bereits in Ihrem Repository befinden.

Planen Sie große Bilder und zukünftiges Wachstum. Du willst nicht zwei Jahre in dieses Projekt einsteigen und einen "Oh Mist, vielleicht ist das Repo ein bisschen z groß" haben.

0
TheLQ

Ich stimme definitiv zu, dass eine technische und wirtschaftliche Lagerung möglich ist. Frage würde ich wie ist "Sind diese Bilder Teil des Versandprodukts oder Teil des Inhalts eines Versandprodukts?" Nicht, dass Sie Inhalte nicht in GIT (oder einem anderen VCS) speichern können, sondern dass dies ein separates Problem für ein separates VCS ist.

0
Wyatt Barnett