Sie können sich Lösungen wie git-annex ansehen, die sich mit der Verwaltung von (großen) Dateien mit git beschäftigen, ohne die Dateiinhalte in git einzuchecken(!)
(Feb 2015: Ein Service-Hosting wie GitLab integriert es nativ:
Siehe "Unterstützt GitLab große Dateien über git-annex oder anderweitig?")
git verwaltet keine großen Dateien, wie von Amber in ihrer Antwort erklärt.
Das bedeutet jedoch nicht, dass git eines Tages nicht besser sein wird.
Von GitMinutes Episode 9 (Mai 2013, siehe auch unten), von Peff (Jeff King), bei 36'10'':
(Transkript)
Es gibt eine ganz andere Welt großer Repositories, in der die Leute daran interessiert sind, 20 oder 30 oder 40 GB, manchmal sogar TB-große Repositories zu speichern, und ja, das kommt vom Vorhandensein einer Menge Dateien, aber ein Großteil stammt von wirklich großen Dateien und wirklich großen binären Dateien, die nicht so gut miteinander umgehen.
Das ist sozusagen ein offenes Problem. Es gibt ein paar Lösungen: git-annex ist wahrscheinlich die ausgereifteste davon, bei der sie im Grunde genommen das Asset nicht in git legen, sondern das große Asset auf einem Asset-Server ablegen und einen Zeiger in git setzen.
Ich würde gerne so etwas machen, wo das Asset konzep tionell in git liegt, d. h. die SHA1 dieses Objekts ist Teil des SHA1, der in den Baum, der in die Commit-ID und all diese Dinge eingeht.
Also aus der Perspektive von git ist es Teil des Repositories, aber auf einer tieferen Ebene, auf der Objektspeicherebene, auf einer Ebene unterhalb des konzep t ionellen Verlaufsbildes, wo wir bereits mehrere Möglichkeiten haben, ein Objekt zu speichern: Wir haben lose Objekte, wir haben gepackte Objekte, ich hätte vielleicht gerne eine neue Möglichkeit, ein Objekt zu speichern, die besagt "wir haben es hier nicht, aber es ist über einen Asset-Server verfügbar", oder so etwas.
(Thomas Ferris Nicolaisen) Oh cool...
Das Problem bei Dingen wie git-annex ist: Wenn Sie sie einmal benutzen, sind Sie ... für immer an die Entscheidungen gebunden, die Sie zu diesem Zeitpunkt getroffen haben. Sie wissen, dass Sie sich entscheiden können, oh, 200 MB sind groß, und wir werden sie auf einem Asset-Server speichern, und dann entscheiden Sie später, dass es doch 300 MB hätte sein sollen, naja, Pech gehabt: das ist für immer in Ihrer Geschichte codiert.
Und indem Sie konzep t ionell auf Ebene von git sagen, dass dieses Objekt im git-Repository ist, nicht irgendein Zeiger darauf, nicht ein Zeiger auf einen Asset-Server, das tatsächliche Objekt ist da, und dann sich um diese Details auf niedriger Ebene, auf der Speicherebene, kümmern, dann sind Sie frei, viele verschiedene Entscheidungen zu treffen und sogar Ihre Entscheidung später darüber zu ändern, wie Sie die Daten tatsächlich auf der Festplatte speichern möchten.
Derzeit kein Projekt mit hoher Priorität ...
3 Jahre später, im April 2016, enthält Git Minutes 40 ein Interview mit Michael Haggerty von GitHub um 31' (Danke Christian Couder für das Interview).
Er ist schon seit geraumer Zeit auf Referenz-Backends spezialisiert, wie in spezialisiert.
Er zitiert David Turners Arbeit an Back-End als derzeit interessantsten. (Siehe Davids aktuellen "pluggable-backends"-Zweig seiner git/git-Fork))
(Transkript)
Christian Couder (CD): Das Ziel ist es, Git-Referenzen in einer Datenbank zu speichern, zum Beispiel? Michael Haggerty (MH): Ja, ich sehe darin zwei interessante Aspekte: Der erste besteht einfach darin, die Möglichkeit zu haben, verschiedene Quelleintrag-Referenzen zu integrieren. Eintrag-Referenzen werden im Dateisystem gespeichert, als Kombination aus lose Referenzen und gepackten Referenzen.
Loose-Referenz ist eine Datei pro Referenz, und gepackte Referenz ist eine große Datei, die eine Liste vieler vieler Referenzen enthält.
Das ist ein gutes System, vor allem für den lokalen Gebrauch; es hat keine echten Leistungsprobleme für normale Menschen, aber es hat einige Probleme, z.B. können Sie Referenz-Reflogs nicht speichern, nachdem die Referenzen gelöscht wurden, da Konflikte mit neueren Referenzen auftreten können, die mit ähnlichen Namen erstellt wurden. Es besteht auch ein Problem darin, dass Referenznamen im Dateisystem gespeichert sind, sodass Sie Referenzen haben können, die ähnlich benannt sind, aber mit unterschiedlicher Großschreibung.
Diese Dinge könnten also durch ein allgemeines Referenz-Back-End-System behoben werden.
Der andere Aspekt von David Turners Patchserie ist eine Änderung, Referenzen in einer Datenbank namens lmdb zu speichern, das ist eine wirklich schnelle speicherbasierte Datenbank, die einige Leistungsvorteile gegenüber dem Datei-Backend hat.
[folgen weitere Überlegungen zur schnelleren Packung und Anzeigen von Referenzpatches]
