Lore: Warum Epic Games ein neues Versionskontrollsystem baut

Git ist so tief in unseren Alltag eingewachsen, dass wir uns kaum noch fragen, ob es eigentlich noch zeitgemäß ist. Im Juni 2026 hat Epic Games trotzdem eine Antwort gegeben, die nicht viele erwartet hätten: Lore, ein komplett neues, open-source Versionskontrollsystem unter MIT-Lizenz – kein Git-Fork, kein Plugin, kein Wrapper. Ein Neubau von Grund auf.

Auf den ersten Blick klingt das nach einem Nischenthema für Gamedev-Studios, die mit hunderten Gigabyte an Texturen und 3D-Assets jonglieren. Und ja, genau dafür ist Lore in erster Linie gebaut. Aber die Probleme, die Epic damit löst, sind dir wahrscheinlich auch bekannt: große Binärdateien im Repo, Docker-Layer die sich nicht sauber versionieren lassen, ML-Modelle die niemand wirklich in Git haben will, Monorepos die beim Clone eine gefühlte Ewigkeit brauchen. Lore zeigt, wie ein VCS aussieht, das dieses Problem von Anfang an mitdenkt statt es nachträglich mit LFS zu pflastern. Schauen wir uns an, was dahintersteckt – und wo sich ein zweiter Blick auch außerhalb von Gamedev lohnt.

Das Problem, das Git nicht wirklich löst

Git wurde für Code gebaut – für kleine, textbasierte Dateien, bei denen sich Diffs zeilenweise berechnen lassen. Für genau diesen Fall ist es bis heute schwer zu schlagen. Das Problem fängt an, sobald du Binärdateien ins Spiel bringst.

So sieht der Alltag mit Git und großen Binärdateien meistens aus:

• Du bindest Git LFS ein, weil dein Repo sonst nach ein paar Wochen unbrauchbar groß wird. LFS ist aber ein Aufsatz, keine native Lösung – es zeigt sich spätestens dann, wenn Pointer-Dateien plötzlich nicht auflösen oder der LFS-Server unter Last einknickt.
• Jeder Clone lädt erstmal alles. Sparse-Checkouts existieren zwar, fühlen sich aber wie eine nachträgliche Krücke an – speziell offline oder bei Netzwerkproblemen brechen sie gerne mit kryptischen Fehlern ab.
• Zwei Dateien mit fast identischem Inhalt werden trotzdem komplett neu gespeichert, weil Git bei Binärdaten nicht sinnvoll deduplizieren kann. Bei Texturen, Modell-Checkpoints oder Build-Artefakten läppert sich das schnell zu zweistelligen Gigabyte-Beträgen.
• Mehrere Teams im selben Repo? Git kennt kein natives Konzept für Mandantentrennung – jeder sieht potenziell alles, ob er will oder nicht.

Keines dieser Probleme macht Git schlecht. Es macht nur deutlich, dass Git für Code entworfen wurde und alles andere Nachrüstung ist. Genau an diesem Punkt setzt Lore an: Es behandelt große Binärdaten nicht als Sonderfall, sondern als Normalfall – von der Storage-Schicht aufwärts. Wie das konkret aussieht, kommt im nächsten Abschnitt.

Wie Lore das architektonisch löst

Lore ist kein Git mit ein paar Optimierungen, sondern von der Storage-Schicht aufwärts neu gedacht. Vier Konzepte tragen das Ganze:

• Content-addressed Storage & Merkle Trees: Jede Datei und jeder Repository-Zustand wird über ihren Hash referenziert, der komplette Stand als Baum von Hashes abgebildet. Das macht Vergleiche und Integritätsprüfungen schnell, weil sich zwei Zustände über ihre Hashes vergleichen lassen statt über Dateiinhalte.
• Immutable Revision Chain: Jede Revision leitet ihren eigenen Hash aus ihrem Zustand ab – inklusive der Hashes der Vorgänger-Revision und aller enthaltenen Daten. Damit ist die komplette Historie kryptografisch verkettet und nachträglich nicht unbemerkt veränderbar.
• Chunk-basierte Speicherung mit Dedup: Dateien werden nicht als Ganzes gespeichert, sondern in wiederverwendbare Chunks zerlegt. Ändert sich nur ein Teil einer riesigen Datei, muss nicht die ganze Datei neu abgelegt werden – ein Unterschied, der bei Gigabyte-großen Assets sofort spürbar wird.
• On-demand/Sparse Hydration: Statt beim Clone alles herunterzuladen, holt sich Lore Daten erst dann, wenn sie tatsächlich gebraucht werden. Das ist nativer Bestandteil des Systems, nicht wie bei Git ein nachträglich aufgesetztes Sparse-Checkout.

Zusammen ergibt das ein VCS, das große Binärdaten so behandelt, wie Git Textdateien behandelt: als Normalfall, nicht als Sonderfall. Wie genau Merkle Trees und die Revision Chain unter der Haube arbeiten, schauen wir uns in einem eigenen Architektur-Deep-Dive an – hier reicht das Prinzip, um den nächsten Punkt einzuordnen.

Warum das auch für Java/Spring/DevOps-Leute relevant ist

Du baust wahrscheinlich kein AAA-Game. Trotzdem tauchen die Probleme, die Lore löst, in ganz anderen Ecken deines Stacks auf:

• ML-Modelle und Artefakte: Model-Checkpoints landen in vielen Teams entweder in einem separaten Artifact-Store oder – schlechter – direkt im Git-Repo mit LFS. Genau das Szenario, für das Chunk-Dedup und On-demand-Hydration gedacht sind: nur die geänderten Teile eines Modells übertragen statt jedes Mal Gigabytes neu hochzuladen.
• Docker-Layer und Build-Artefakte: Wenn dein CI/CD-Setup große, sich häufig ändernde Binärartefakte versioniert (Images, JARs mit gebündelten Ressourcen, generierte Reports), ist das strukturell dasselbe Problem wie bei Epics Texturen – nur kleiner skaliert.
• Monorepos mit gemischtem Inhalt: Sobald Code und Daten im selben Repo leben, merkst du schnell, dass Git für diese Kombination nicht gebaut wurde. Sparse Checkouts, die tatsächlich zuverlässig funktionieren, sind hier kein Nice-to-have, sondern der Unterschied zwischen einem Clone in Sekunden und einem in Minuten.

Das heißt nicht, dass du morgen dein Git-Repo migrieren solltest – dazu kommen wir gleich. Aber die Prinzipien hinter Lore sind ein gutes Beispiel dafür, wie man Versionierung für Daten denkt statt nur für Code. Das lohnt sich zu verstehen, selbst wenn du weiterhin bei Git bleibst.

Aktueller Stand & Ausblick

Lore ist Mitte 2026 unter MIT-Lizenz open-source gegangen und liegt auf GitHub unter der Epic-Games-Organisation, inklusive Dokumentation zur Systemarchitektur. Das Projekt ist explizit als offener Ansatz positioniert – Epic wirbt damit, dass ein wirklich offenes Ökosystem nicht von einer einzelnen Firma allein gebaut werden kann, sondern nur gemeinsam mit der Community.

Was schon funktioniert: das Kernsystem mit Content-Addressing, Chunking und Revision Chain. Was laut Epic noch aussteht:

• Erweiterte Workflows für sehr große Repositories (VFS, Windows Service)
• OAuth-Integration
• Skalierbares Locking für parallele Bearbeitung derselben Assets
• Multi-Server-Replikation
• Client- und Server-seitige Hooks
• Ein VS-Code-Plugin
• Ein offizieller, open-source Desktop- und Web-Client

Das ist eine ehrliche Ansage: Lore ist ein frühes Projekt, kein fertiges Produkt. Für die meisten bestehenden Teams ist ein Umstieg heute weder nötig noch sinnvoll – Git bleibt für Code die richtige Wahl, und ein VCS-Wechsel ist selten eine Entscheidung, die man leichtfertig trifft. Für Studios mit massiven Binärdaten-Problemen oder für alle, die einfach beobachten wollen, wie eine große Firma das VCS-Problem 2026 neu denkt, lohnt sich aber ein Blick aufs Repository.

Fazit

Lore ist kein Git-Killer und will das auch gar nicht sein – dafür ist es zu früh und zu sehr auf ein bestimmtes Problem zugeschnitten. Was es aber ist: ein durchdachtes Beispiel dafür, wie ein Versionskontrollsystem aussieht, wenn man große Binärdaten von Anfang an mitdenkt statt sie nachträglich mit LFS zu flicken. Content-Addressing, Chunk-Dedup und On-demand-Hydration sind keine neuen Ideen für sich genommen – neu ist, sie konsequent zum Fundament eines VCS zu machen.

Ob du Lore je einsetzt oder nicht: Ein Blick auf die Prinzipien dahinter schärft den Blick für die eigenen Datenversionierungs-Probleme, egal ob es um ML-Modelle, Docker-Layer oder Monorepos geht. Wie Merkle Trees, die immutable Revision Chain und das Chunking bei Lore im Detail funktionieren, schauen wir uns im nächsten Artikel genauer an.