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 verä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 von großen Bildern oder nur einer Vielzahl von Bildern zu einer großen Größe wird.

Wird dies als Best Practice angesehen? Welche anderen Alternativen zum Freigeben von Binärdateien sind für Projekte erforderlich, auf die ein verteiltes Team problemlos zugreifen kann?

Handelt es sich bei Ihren Bildern um Originale oder können sie (garantiert?) Von einem anderen Ort wiederhergestellt werden? Werden sie benötigt, um eine Softwareeinheit aus dem Quellcode zu versenden? Wenn sie original sind, müssen sie gesichert werden. Legen Sie sie in Ihre Versionskontrolle, wenn sie sich nie ändern, entspricht die Speicherplatzstrafe einer Sicherung, 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 revisionskontrolliert sein. Warum einen anderen Weg gehen, wenn Sie bereits eine perfekte Lösung haben? Warum die Versionskontrolle "Kopieren und Umbenennen" aus dem dunklen Zeitalter einführen?

Ich habe gesehen, wie die Originalgrafiken eines gesamten Projekts "kaputt" wurden, als die MacBook-Festplatte des Grafikdesigners ausfiel, weil jemand mit unendlicher Weisheit entschied, dass "Binärdateien nicht in die Revisionskontrolle gehören", und Grafikdesigner (zumindest diese) ) sind in der Regel nicht gut mit Backups.

Gleiches gilt für alle Binärdateien, die den obigen Kriterien entsprechen.

Der einzige Grund, warum dies nicht der Fall ist, ist der Speicherplatz. Ich habe Angst um 100 $ / Terabyte, diese Ausrede ist ein bisschen dünn.

Warum zur Hölle nicht? :)

Das Speichern von Binärdateien wird als schlechte Praxis angesehen, aber ich habe mich nie zu sehr um Bilder gekümmert.

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

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

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

(Abgesehen davon strahlt 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:

• Speichern von Bilddateien in SubVersion / Git
• Git vs SVN mit Nicht-Text-Dateien
• Große Binärdateien mit Git und Git-Submodul verwalten

Diese Frage ist ziemlich alt, aber diese Frage taucht häufig auf, wenn es um Git geht, und seit der letzten Antwort sind einige Fortschritte bei modernen Lösungen zum Speichern großer Dateien in einem Git-Repo zu verzeichnen.

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

• git-annex - Das gibt es schon eine Weile, aber ehrlich gesagt steht ihm die Komplexität im Weg.
• 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 zu schätzen weiß, ist mein Hauptanliegen bei Plugins, dass es ziemlich unbekannt ist und von 1 Person gepflegt wird (vollständige Offenlegung, ich bin der einzige andere Committer zu diesem Zeitpunkt und es war für ein triviales Problem).
• git-lfs - Obwohl ich das nicht ausgiebig benutzt habe, scheint es der heilige Gral zu sein. Es wird von Github unterstützt und ist ab Oktober 2015 für alle Repos verfügbar. Die komplexe Dateiverwaltung wird durch die Speicherung Ihrer Repos vor Ort erleichtert. Einziger Nachteil ist , dass diese ziemlich neu ist, so über Github es nicht viel Unterstützung, obwohl Gitlab auch Unterstützung hat , wie Gitea tut , und Bitbucket hat erwähnt in Zukunft zu unterstützen .

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

Das Ganze "Keine Binärdateien in der Quellcodeverwaltung speichern" hat einen bestimmten Grund: Wenn Sie kompilierten Quellcode haben, speichern Sie nicht die eigentliche Kompilierung, sondern nur den Quellcode. Bilder und visuelle Assets haben keine "Quelle", daher sollten sie in der Versionskontrolle verfolgt werden.

Ich glaube, die empfohlene Methode für Git ist die Verwendung eines Submoduls (eingeführt in Git 1.5.3), das im Grunde genommen ein separates Repository ist, das dem Hauptmodul 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, dass ein Repository als Unterverzeichnis ein Auschecken eines externen Projekts enthält. Submodule behalten ihre eigene Identität bei. Die Submodul-Unterstützung speichert lediglich den Speicherort des Submodul-Repositorys und die Commit-ID, so dass andere Entwickler, die das enthaltende Projekt klonen ( superproject ") kann problemlos alle Submodule mit derselben Revision klonen. Teilweise Auschecken 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 ausführen, um die Größe zu verringern / zu verringern, z. B .:

git gc
git gc-aggressive
git prune

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 gibst 2.0 frei. Einige Kunden, die 1.0 verwenden und kein Upgrade auf 2.0 durchführen können, möchten das Programm in einer anderen Sprache. Sie geben dir $ 1G dafür, also sagst du 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 können Sie Änderungen an Bildern (unter anderem) vornehmen, erstellen und freigeben. 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.

Wenn es Teil des Projekts ist, muss es sich im VCS befinden . Wie dies am besten erreicht wird, 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 setzen.

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 ist es nicht zu heiß mit Binärdateien. Sie werden Probleme mit der Größe der Daten haben, die übertragen werden, wenn Sie klonen oder pushen, Ihre .git-Verzeichnisse werden größer und Sie könnten beim Zusammenführen in ein richtiges Chaos geraten (dh wie führen Sie 2 Bilder zusammen!)

Eine Antwort ist die Verwendung von Submodulen, da dies bedeutet, dass die Verbindung zwischen Ihrem Projekt und den Bildern schwächer wird. Sie müssen die Bilder also nicht so verwalten, als wären sie Teil Ihrer Quelle, behalten sie jedoch weiterhin die Kontrolle und haben keine Probleme beim Verzweigen - vorausgesetzt, das Teilprojekt ist nur ein 'flaches' Datenarchiv, das während des üblichen Entwicklungsprozesses nicht dieselbe Abwanderung durchläuft.

Die andere Antwort ist, sie in ein anderes Projekt einzufügen, es nie zu verzweigen und sicherzustellen, dass jeder, der sich für dieses Projekt engagiert, es sofort in den Upstream schiebt - lassen Sie niemals zu, dass 2 Personen dieselbe Version der Datei ändern - das wird Ihnen am schwersten fallen Aspekt wie Git ist nicht für einen solchen nicht verteilten Workflow ausgelegt. Sie müssen altmodische Kommunikationsmethoden verwenden, um diese Regel festzulegen.

Eine dritte Antwort besteht darin, sie in ein anderes SCM zu stellen, das sich besser für die Arbeit mit Bildern eignet.

Beachten Sie, dass die Größe einen großen Einfluss auf die Antwort von @ haylem hat. Abhängig vom VCS funktioniert dies möglicherweise nicht mit vielen 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 zu groß."

Ich stimme definitiv zu, dass eine technische und wirtschaftliche Lagerung möglich ist. Frage Ich würde wie folgt lauten: "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 es sich um ein separates Problem für ein separates VCS handelt.