[{"data":1,"prerenderedAt":773},["ShallowReactive",2],{"/de-de/blog/a-beginners-guide-to-the-git-reftable-format":3,"navigation-de-de":39,"banner-de-de":442,"footer-de-de":452,"blog-post-authors-de-de-Patrick Steinhardt":657,"blog-related-posts-de-de-a-beginners-guide-to-the-git-reftable-format":671,"blog-promotions-de-de":708,"next-steps-de-de":763},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":28,"isFeatured":12,"meta":29,"navigation":12,"path":30,"publishedDate":20,"seo":31,"stem":36,"tagSlugs":37,"__hash__":38},"blogPosts/de-de/blog/a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format",[7],"patrick-steinhardt",null,"open-source",{"slug":11,"featured":12,"template":13},"a-beginners-guide-to-the-git-reftable-format",true,"BlogPost",{"heroImage":15,"body":16,"authors":17,"updatedDate":19,"date":20,"title":21,"tags":22,"description":27,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","Bis vor Kurzem war das „files“-Format die einzige Möglichkeit in Git, Referenzen zu speichern. Mit der [Version Git 2.45.0](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) kann Git nun Referenzen im „reftable“-Format speichern. Dieses neue Format ist ein Binärformat, das deutlich komplexer als das alte “files” Format ist. Diese Komplexität ermöglicht es jedoch, einige Mängel des „files“-Formats zu beheben. Die Entwicklungsziele des „reftable“-Formats sind unter anderem folgende:\n\n- Die Suche nach einzelnen Referenzen und die Iterationen über zahlreichen Referenzen soll so effizient und schnell wie möglich sein.\n- Das konsistente Lesen von Referenzen soll unterstützt werden, sodass Git nie einen Zwischenzustand liest, wenn ein Update an mehreren Referenzen nur teilweise angewendet wurde.\n- Atomares Schreiben soll unterstützt werden, sodass die Aktualisierung von mehreren Referenzen nur entweder vollständig oder gar nicht möglich ist.\n- Effiziente Speicherung von Referenzen und Reflog-Einträgen.\n\nIn diesem Artikel kommen wir allen Feinheiten des „reftable“-Formats auf die Schliche und sehen uns genau an, wie es funktioniert.\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n## So speichert Git Referenzen\n\nBevor wir uns die Details des „reftable“-Formats ansehen, fassen wir nochmals kurz zusammen, wie Git in der Vergangenheit Referenzen gespeichert hat. Wenn du damit bereits vertraut bist, kannst du gleich zum nächsten Abschnitt springen.\n\nEin Git-Repository enthält zwei wesentliche Datenstrukturen:\n\n- [Objekte](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects), die die eigentlichen Daten deines Repositorys enthalten. Dazu gehören Commits, die Verzeichnisstruktur und die Blobs, die deinen Quellcode enthalten. Objekte verweisen aufeinander und bilden so einen Objektgraphen. Außerdem hat jedes Objekt eine Objekt-ID, durch die es eindeutig identifiziert wird.\n\n- Referenzen wie Branches und Tags sind Wegweiser im Objektgraphen, sodass du Objekten Namen geben kannst, die einfacher zu merken sind, und verschiedene Wege deines Entwicklungsverlaufs nachverfolgen kannst. Ein Repository kann zum Beispiel einen `main`-Branch enthalten, der eine Referenz mit dem Namen `refs/heads/main` ist und auf einen bestimmten Commit zeigt.\n\nReferenzen werden in der Referenzdatenbank gespeichert. Bis Git 2.45.0 gab es nur das Datenbankformat „files“. In diesem Format wird jede Referenz als einfache Datei gespeichert, die eines der folgenden Elemente enthält:\n\n- Eine normale Referenz, die die Objekt-ID des Commits enthält, auf den sie zeigt.\n- Eine symbolische Referenz, die den Namen einer anderen Referenz enthält. Dies ist ähnlich wie ein symbolischer Link, der auf eine andere Datei zeigt.\n\nIn regelmäßigen Abständen werden diese Referenzen in eine einzige `packed-refs`-Datei komprimiert, damit Referenzen effizienter durchsucht werden können.\n\nDie folgenden Beispiele sollen eine Vorstellung davon geben, wie das „files“-Format funktioniert:\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD ist eine symbolische Referenz, die auf refs/heads/main zeigt.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main ist eine normal Referenz, die auf einen Commit zeigt.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) komprimiert diese Referenzen in eine packed-refs Datei.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Hochrangige Struktur von reftables\n\nWenn du nun Git 2.45.0 oder eine neuere Version installiert hast, kannst du ein Repository mit dem „reftable“-Format erstellen, indem du den Switch `--ref-format=reftable` verwendest:\n\n```shell\n$ git init --ref-format=reftable .Initialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevante Dateien wurden für ein einfacheres Verständnis entfernt.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n  ├── 0x000000000001-0x000000000002-40a482a9.ref\n  └── tables.list\n\n4 directories, 6 files\n```\n\nSieh dir zunächst die Repository-Konfiguration an. Du wirst feststellen, dass sie den Schlüssel `extension.refstorage` enthält:\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n\n```\n\nDiese Konfiguration teilt Git mit, dass das Repository mit dem „reftable“-Format initialisiert wurde und gibt an, dass Git das „reftable“-Backend nutzen muss, um darauf zuzugreifen.\n\nSeltsamerweise enthält das Repository immer noch einige Dateien, die aussehen, als würde das „files“-Backend verwendet werden:\n\n- `HEAD` würde normalerweise eine symbolische Referenz sein, die auf deinen derzeit ausgecheckten Branch zeigt. Obwohl es nicht vom „reftable“-Backend verwendet wird, ist es für Git-Clients erforderlich, um das Verzeichnis als Git-Verzeichnis zu erkennen. Wenn du also das „reftable“-Format verwendest, ist `HEAD` ein Stub mit dem Inhalt `ref: refs/heads/.invalid`.\n\n- `refs/heads` ist eine Datei mit dem Inhalt `this repository uses the reftable format`. Git-Clients, die das Format „reftable“ nicht kennen, würden normalerweise erwarten, dass dieser Pfad ein Verzeichnis ist. Wenn du also diesen Pfad bewusst als Datei erstellst, führt dies dazu, dass ältere Git-Clients fehlschlagen, wenn sie versuchen, mit dem „files“-Backend auf das Repository zuzugreifen.\n\nDie tatsächlichen Referenzen werden im Verzeichnis `reftable/` gespeichert:\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├──0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nEs gibt hier zwei Dateien:\n\n- `0x000000000001-0x000000000001-794bd722.ref` ist eine Tabelle mit Referenzen und den Reflog-Einträgen in einem Binärformat.\n\n- `tables.list` ist eine Liste von Tabellen. Im aktuellen Status des Repositorys enthält die Datei eine Zeile, die der Name der Tabelle ist. Diese Datei verfolgt den aktuellen Satz aktiver Tabellen in der „reftable“-Datenbank und wird aktualisiert, wenn neue Tabellen zum Repository hinzugefügt werden.\n\nWenn du eine Referenz aktualisierst, wird eine neue Tabelle erstellt:\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├──0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nWie du sehen kannst, wurde die vorherige Tabelle durch eine neue ersetzt. Darüber hinaus wurde die Datei `tables.list` aktualisiert und enthält nun die neue Tabelle.\n\n## Die Struktur einer Tabelle\n\nWie bereits erwähnt, sind die eigentlichen Daten der Referenzdatenbank in Tabellen enthalten. Grob gesagt ist eine Tabelle in mehrere Abschnitte unterteilt:\n\n- Der „Header“ enthält Metadaten zur Tabelle. Dazu gehören unter anderem die Version des Formats, die Blockgröße und die vom Repository verwendete Hash-Funktion (z. B. SHA1 oder SHA256).\n- Der Abschnitt „Ref“ enthält deine Referenzen. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht und entweder auf eine Objekt-ID für reguläre Referenzen oder auf eine andere Referenz für symbolische Referenzen zeigt.\n- Der Abschnitt „Obj“ enthält die umgekehrte Zuordnung von Objekt-IDs zu den Referenzen, die auf diese Objekt-IDs zeigen. Diese ermöglichen es Git, effizient zu suchen, welche Referenzen auf eine bestimmte Objekt-ID zeigen.\n- Der Abschnitt „Log“ enthält deine Reflog-Einträge. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht, sowie einen Index, der die Nummer des Reflog-Eintrags darstellt. Außerdem enthalten sie die alten und neuen Objekt-IDs sowie die Nachricht für diesen Reflog-Eintrag.\n- Der „Footer“ enthält Zeiger zu den verschiedenen Abschnitten.\n\n![Lange Tabelle mit allen reftable-Abschnitten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nDie Abschnittstypen sind alle ähnlich strukturiert. Abschnitte enthalten eine Reihe von Datensätzen, die nach den Schlüsseln der einzelnen Datensätze sortiert sind. Wenn du zum Beispiel zwei Ref-Datensätze `refs/heads/aaaaa` und `refs/heads/bbb` hast, hast du zwei Ref-Datensätze mit diesen Referenznamen als jeweiligen Schlüssel, weshalb `refs/heads/aaaaa` vor `refs/heads/bbb` kommt.\n\nDarüber hinaus ist jeder Abschnitt in Blöcke mit einer festen Länge unterteilt. Diese Blocklänge ist im Header codiert und dient zwei Zwecken:\n\n- Da sie den Anfang des Abschnitts markieren und die Blockgröße angeben, weiß der bzw. die Leser(in) implizit, wo jeder der Blöcke beginnt. Dadurch kann Git gleich in die Mitte des Abschnitts springen, ohne vorherige Blocks lesen zu müssen. So kann die binäre Suche in Blöcken das Durchsuchen von Datensätzen beschleunigen.\n- Sie stellt sicher, dass Git weiß, wie viele Daten gleichzeitig von der Festplatte gelesen werden sollen. Folglich ist die Blockgröße standardmäßig auf 4 KiB eingestellt, was die häufigste Sektorgröße für Festplatten ist. Die maximale Blockgröße beträgt 16 MB.\n\nWenn wir zum Beispiel in einen „ref“-Abschnitt schauen, sieht er ungefähr wie die folgende Grafik aus. Achte darauf, wie die Datensätze lexikografisch in den Blocks, aber auch blockübergreifend sortiert sind.\n\n![Referenzblock, nicht komprimiert](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMit diesem Wissen können wir nun einen Datensatz finden, indem wir die folgenden Schritte befolgen:\n\n1. Führe eine Binärsuche über die Blocks durch, indem du dir die Schlüssel der jeweiligen ersten Datensätze ansiehst und den Block identifizierst, der unseren Datensatz enthalten muss.\n\n2. Führe eine lineare Suche in den Datensätzen dieses Blocks durch.\n\nBeide Schritte sind immer noch recht ineffizient. Wenn wir viele Blöcke haben, müssen wir logarithmisch viele davon in unserer Binärsuche lesen, um den gewünschten Block zu finden. Und wenn Blöcke viele Datensätze enthalten, müssen wir vielleicht bei der linearen Suche alle davon lesen.\n\nDas „reftable“-Format verfügt über zusätzliche integrierte Mechanismen, um diese Leistungsbedenken auszuräumen. Wir gehen in den nächsten Abschnitten darauf ein.\n\n### Präfix-Komprimierung\n\nWie du vielleicht bemerkt hast, haben alle Datensatzschlüssel das gleiche Präfix `refs/`. Dies ist häufig so in Git:\n\n- Alle Branches beginnen mit `refs/heads/`.\n- Alle Tags beginnen mit `refs/tags/`.\n\nDaher gehen wir davon aus, dass nachfolgende Datensätze höchstwahrscheinlich einen signifikanten Anteil ihres Schlüssels gemeinsam haben. Dies ist eine gute Gelegenheit, um wertvollen Speicherplatz zu sparen. Da wir wissen, dass die meisten Schlüssel ein gemeinsames Präfix haben, ist es sinnvoll, dies zu optimieren.\n\nDie Optimierung verwendet Präfix-Komprimierung. Jeder Datensatz kodiert eine Präfixlänge, die den Leser(innen) mitteilt, wie viele Bytes des Schlüssels des vorhergehenden Datensatzes wiederverwendet werden sollen. Wenn wir zwei Datensätze haben, `refs/heads/a` und `refs/heads/b`, kann letzterer kodiert werden, indem man eine Präfixlänge von 11 angibt und dann nur das Suffix `b` speichert. Die Leser(innen) nehmen dann die ersten 11 Bytes von `refs/heads/a`, was `refs/heads/` ist, und fügen das Suffix `b` hinzu.\n\n![Präfix-Komprimierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### Neustart-Punkte\n\nWie bereits erklärt, ist eine lineare Suche der beste Weg, mit unserem derzeitigen Wissen über das „reftable“-Format in einem Block nach einer Referenz zu suchen. Der Grund dafür ist, dass die Datensätze keine fixe Länge haben. Daher können wir nicht feststellen, wo Datensätze beginnen, ohne von Anfang an den Block zu durchsuchen. Auch wenn Datensätze eine fixe Länge hätten, könnten wir nicht in der Mitte eines Blocks suchen, da die Präfix-Kompression erfordert, dass wir auch die vorhergehenden Datensätze lesen.\n\nEine lineare Suche wäre ziemlich ineffizient, da Blöcke Hunderte oder sogar Tausende von Datensätzen enthalten können. Um dieses Problem zu beheben, codiert das „reftable“-Format sogenannte Neustart-Punkte in jeden Block. Neustart-Punkte sind unkomprimierte Datensätze, bei denen keine Präfix-Komprimierung verwendet wird. Folglich enthalten Datensätze an Neustart-Punkten immer ihren vollständigen Schlüssel, und es wird möglich, den Datensatz direkt zu suchen und zu lesen, ohne die vorhergehenden Datensätze lesen zu müssen. Diese Neustart-Punkte sind in der Fußzeile jedes Blocks aufgeführt.\n\nMit diesen Informationen können wir eine lineare Suche über den Block vermeiden. Stattdessen können wir jetzt eine Binärsuche über die Neustart-Punkte durchführen, bei der wir nach dem ersten Neustart-Punkt mit einem Schlüssel suchen, der lexikographisch größer ist als der gesuchte Schlüssel. Daraus folgt, dass sich der gewünschte Datensatz in dem Abschnitt befinden muss, der sich vom _vorhergehenden_ Neustart-Punkt bis zum identifizierten Neustart-Punkt erstreckt.\n\nDaher ist unser erstes Vorgehen bei der Suche nach einem Datensatz (Binärsuche nach dem Block, Linearsuche nach dem Datensatz) nun wie folgt:\n\n1. Führe eine Binärsuche über die Blocks durch und finde den Block, der unseren Datensatz enthalten muss.\n\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts.\n\n![Lineare Suche nach einem Datensatz](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Indizes\n\nDie Suche nach Datensätzen in einem Block wäre nun einigermaßen effizient. Es ist aber weiterhin ineffizient, den Block selbst zu finden. Eine Binärsuche kann bei ein paar Blöcken funktionieren, aber Repositories mit Millionen von Referenzen können Hunderte oder sogar Tausende von Blöcken haben. Ohne zusätzliche Datenstruktur würde dies durchschnittlich logarithmisch viele Festplattenzugriffe verursachen.\nUm dies zu vermeiden, kann auf jeden Abschnitt ein Indexabschnitt folgen, der eine effiziente Möglichkeit bietet, einen Block nachzuschlagen. Jeder Indexdatensatz enthält die folgenden Informationen:\n\n- Die Position des Blocks, den er indiziert.\n- Der Schlüssel des letzten Datensatzes des Blocks, den er indiziert.\n\nBei drei oder weniger Blöcken erfordert eine Binärsuche immer höchstens zwei Festplattenlesevorgänge, um den gewünschten Zielblock zu finden. Dies ist die gleiche Anzahl von Lesevorgängen, die wir mit einem Index hätten: einen, um den Index selbst zu lesen, und einen, um den gewünschten Block zu lesen. Folglich werden Indizes nur geschrieben, wenn sie tatsächlich einige Lesevorgänge einsparen würden, was ab vier indizierten Blöcken der Fall ist.\n\nNun stellt sich die Frage: Was passiert, wenn der Index selbst so groß wird, dass er sich über mehrere Blöcke erstreckt? Du hast es vielleicht erraten: Wir schreiben einen weiteren Index, der den Index indiziert. Diese mehrstufigen Indizes werden erst dann wirklich notwendig, wenn du Repositories mit hunderttausenden von Referenzen hast.\n\nMit diesen Indizes können wir jetzt das Verfahren zum Nachschlagen von Datensätzen noch effizienter machen:\n1. Finde heraus, ob es einen Index gibt, indem du dir die Fußzeile der Tabelle ansiehst.\n  - Wenn es einen gibt, führe eine Binärsuche über den Index durch, um den gewünschten Block zu finden. Dieser Block kann selbst auf einen Indexblock verweisen. In diesem Fall müssen wir diesen Schritt wiederholen, bis wir einen Datensatz des gewünschten Typs finden.\n  - Ansonsten führe eine Binärsuche über die Blöcke durch, wie wir es zuvor getan haben.\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts durch.\n\n## Mehrere Tabellen\n\nBis jetzt haben wir nur besprochen, wie man eine _einzelne_ Tabelle liest. Aber wie der Name `tables.list` schon sagt, kannst du tatsächlich eine Liste von Tabellen in deiner „reftable“-Datenbank haben.\n\nJedes Mal, wenn du eine Referenz in deinem Repository aktualisierst, wird eine neue Tabelle geschrieben und an `tables.list` angehängt. So hast du schließlich mehrere Tabellen:\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├──0x0000000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nUm den tatsächlichen Status eines Repositorys zu lesen, müssen wir diese mehreren Tabellen zu einer einzigen virtuellen Tabelle zusammenführen.\n\nDu fragst dich vielleicht: Wenn für jede Referenzaktualisierung eine Tabelle geschrieben wird und dieselbe Referenz mehrmals aktualisiert wird, woher kennt das „reftable“-Format den aktuellsten Wert einer bestimmten Referenz? Intuitiv könnte man davon ausgehen, dass der Wert derjenige aus der neuesten Tabelle ist, die die Referenz enthält.\n\nTatsächlich hat jeder einzelne Datensatz einen sogenannten Aktualisierungsindex, der die „Priorität“ eines Datensatzes kodiert. Wenn beispielsweise zwei Ref-Datensätze mit demselben Namen existieren, überschreibt derjenige mit dem höheren Aktualisierungsindex denjenigen mit dem niedrigeren Aktualisierungsindex.\n\nDiese Aktualisierungsindizes sind in der obigen Dateistruktur sichtbar. Die langen Hex-Zeichenfolgen (z. B. `0x000000000001`) sind die Aktualisierungsindizes, wobei die linke Seite des Tabellennamens der minimale Aktualisierungsindex ist, der in der Tabelle enthalten ist, und die rechte Seite der maximale Aktualisierungsindex ist.\n\nDas Zusammenführen der Tabellen erfolgt dann über eine [Vorrangwarteschlange](https://de.wikipedia.org/wiki/Vorrangwarteschlange), die nach dem Schlüssel des Ref-Datensatzes sowie dem Aktualisierungsindex geordnet ist. Angenommen, wir möchten alle Ref-Datensätze durchsuchen, würden wir wie folgt vorgehen:\n\n1. Füge für jede Tabelle ihren ersten Datensatz zur Vorrangwarteschlange hinzu.\n\n![Ersten Datensatz zur Vorrangwarteschlange hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Liefere den Kopf der Vorrangwarteschlange. Da die Warteschlange nach Aktualisierungsindex geordnet ist, muss sie die aktuellste Version sein. Füge das nächste Element aus dessen Tabelle zur Vorrangwarteschlange hinzu.\n\n![Head der Vorrangwarteschlange angeben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Ziehe alle Datensätze aus der Warteschlange, die den gleichen Namen haben. Diese Datensätze werden verschattet, was bedeutet, dass sie nicht angezeigt werden. Füge für jede Tabelle, für die wir Datensätze ablegen, den nächsten Datensatz zur Vorrangwarteschlange hinzu.\n\n![Alle Datensätze aus der Warteschlange ablegen, die den gleichen Namen haben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nJetzt können wir bereinigen und den Vorgang wiederholen, um Datensätze für andere Schlüssel zu lesen.\n\nTabellen können spezielle „tombstone“-Datensätze enthalten, die einen Datensatz als gelöscht markieren. So können wir Datensätze löschen, ohne den jeweiligen Datensatz aus allen Tabellen löschen zu müssen.\n\n### Autokomprimierung\n\nWährend die Idee hinter der Vorrangwarteschlange zwar einfach ist, wäre es allerdings eher ineffizient, Hunderte oder sogar nur Dutzende von Tabellen auf diese Weise zusammenzuführen. Es stimmt, dass jede Aktualisierung an deinen Referenzen eine neue Tabelle an deine `tables.list`-Datei anhängt. Das ist jedoch nur ein Teil der Wahrheit.\n\nDer andere Teil ist die Autokomprimierung: Nachdem eine neue Tabelle an die Liste der Tabellen angehängt wurde, überprüft das „reftable“-Backend, ob manche der Tabellen zusammengeführt werden sollen. Dies erfolgt durch eine einfache Heuristik. Wir überprüfen, ob die Liste der Tabellen eine [geometrische Folge](https://de.wikipedia.org/wiki/Geometrische_Folge) der Dateigrößen bildet. Jede Tabelle `n` muss mindestens doppelt so groß sein wie die nächstletzte Tabelle `n + 1`. Wenn gegen diese geometrische Folge verstoßen wird, komprimiert das Backend die Tabellen, sodass die geometrische Folge wiederhergestellt wird.\n\nIm Laufe der Zeit führt dies zu Strukturen, die wie folgt aussehen:\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nBeachte, wie für jede einzelne Tabelle die Eigenschaft `size(n) > size(n+1) * 2` gilt.\n\nEine der Folgen der Autokomprimierung ist, dass sich das „reftable“-Backend selbst erhält. Wir müssen somit nicht mehr den Befehl `git pack-refs` zum Optimieren der Referenzen ausführen.\n\n## Möchtest du mehr erfahren?\n\nDu solltest jetzt ein gutes Verständnis dafür haben, wie das neue „reftable“-Format im Detail funktioniert. Wenn du noch tiefer in das Format eintauchen möchtest, kannst du dir dessen [technische Dokumentation](https://git-scm.com/docs/reftable) des Git-Projekts ansehen.\n\n> Lies dir unsere [Zusammenfassung von Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) durch, um herauszufinden, was sonst noch in dieser Version von Git auf dich wartet.\n",[18],"Patrick Steinhardt","2024-07-29","2024-05-30","Der Anfängerleitfaden zum „reftable“-Format von Git",[23,24,25,26],"git","tutorial","open source","performance","In Git 2.45.0 hat GitLab das reftable Backend in Git eingeführt – dies verändert die Art und Weise, wie Referenzen gespeichert werden, von Grund auf. Erhalte detaillierte Einblicke, wie dieses neue Format funktioniert.","yml",{},"/de-de/blog/a-beginners-guide-to-the-git-reftable-format",{"ogTitle":21,"ogImage":15,"ogDescription":27,"ogSiteName":32,"noIndex":33,"ogType":34,"ogUrl":35,"title":21,"canonicalUrls":35,"description":27},"https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","de-de/blog/a-beginners-guide-to-the-git-reftable-format",[23,24,9,26],"gnbWuwwkufN_NteflqRC5TmnWCS3l_In2qReUkO8_Vc",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":370,"minimal":405,"duo":423,"pricingDeployment":432},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/de-de/","gitlab logo","header",{"text":47,"config":48},"Kostenlose Testversion anfordern",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Vertrieb kontaktieren",{"href":54,"dataGaName":55,"dataGaLocation":45},"/de-de/sales/","sales",{"text":57,"config":58},"Anmelden",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,185,190,291,351],{"text":63,"config":64,"cards":66},"Plattform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":70,"config":71},"Erkunde unsere Plattform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/de-de/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":77,"config":78},"Lerne GitLab Duo kennen",{"href":79,"dataGaName":80,"dataGaLocation":45},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":85,"config":86},"Mehr erfahren",{"href":87,"dataGaName":88,"dataGaLocation":45},"/de-de/why-gitlab/","why gitlab",{"text":90,"left":12,"config":91,"link":93,"lists":97,"footer":167},"Produkt",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":45},"/de-de/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":45,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatisierte Softwarebereitstellung",{"href":104,"dataGaLocation":45,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":45,"icon":130},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Application Security Testing",{"href":128,"dataGaName":135,"dataGaLocation":45},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":45,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software Compliance",{"href":144,"dataGaName":142,"dataGaLocation":45},"/de-de/solutions/software-compliance/",{"title":146,"link":147,"items":152},"Bewertung",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":45},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[153,157,162],{"text":154,"config":155},"Sichtbarkeit und Bewertung",{"href":150,"dataGaLocation":45,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Wertstrommanagement",{"href":160,"dataGaLocation":45,"dataGaName":161},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":163,"config":164},"Analysen und Einblicke",{"href":165,"dataGaLocation":45,"dataGaName":166},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab für",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":45,"dataGaName":174},"/de-de/enterprise/","enterprise",{"text":176,"config":177},"Kleinunternehmen",{"href":178,"dataGaLocation":45,"dataGaName":179},"/de-de/small-business/","small business",{"text":181,"config":182},"den öffentlichen Sektor",{"href":183,"dataGaLocation":45,"dataGaName":184},"/de-de/solutions/public-sector/","public sector",{"text":186,"config":187},"Preise",{"href":188,"dataGaName":189,"dataGaLocation":45,"dataNavLevelOne":189},"/de-de/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"Ressourcen",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"Alle Ressourcen anzeigen",{"href":197,"dataGaName":193,"dataGaLocation":45},"/de-de/resources/",[199,232,250],{"title":200,"items":201},"Erste Schritte",[202,207,212,217,222,227],{"text":203,"config":204},"Installieren",{"href":205,"dataGaName":206,"dataGaLocation":45},"/de-de/install/","install",{"text":208,"config":209},"Kurzanleitungen",{"href":210,"dataGaName":211,"dataGaLocation":45},"/de-de/get-started/","quick setup checklists",{"text":213,"config":214},"Lernen",{"href":215,"dataGaLocation":45,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Produktdokumentation",{"href":220,"dataGaName":221,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best-Practice-Videos",{"href":225,"dataGaName":226,"dataGaLocation":45},"/de-de/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrationen",{"href":230,"dataGaName":231,"dataGaLocation":45},"/de-de/integrations/","integrations",{"title":233,"items":234},"Entdecken",[235,240,245],{"text":236,"config":237},"Kundenerfolge",{"href":238,"dataGaName":239,"dataGaLocation":45},"/de-de/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":45},"/de-de/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"Vernetzen",[253,258,263,268,273],{"text":254,"config":255},"GitLab-Services",{"href":256,"dataGaName":257,"dataGaLocation":45},"/de-de/services/","services",{"text":259,"config":260},"Community",{"href":261,"dataGaName":262,"dataGaLocation":45},"/community/","community",{"text":264,"config":265},"Forum",{"href":266,"dataGaName":267,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"Veranstaltungen",{"href":271,"dataGaName":272,"dataGaLocation":45},"/events/","events",{"text":274,"config":275},"Partner",{"href":276,"dataGaName":277,"dataGaLocation":45},"/de-de/partners/","partners",{"backgroundColor":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":283,"config":284},"the source promo card",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"Lies die News",{"href":289,"dataGaName":290,"dataGaLocation":45},"/de-de/the-source/","the source",{"text":292,"config":293,"lists":295},"Unternehmen",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"Über",{"href":301,"dataGaName":302,"dataGaLocation":45},"/de-de/company/","about",{"text":304,"config":305,"footerGa":308},"Karriere",{"href":306,"dataGaName":307,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":45},{"text":312,"config":313},"Geschäftsführung",{"href":314,"dataGaName":315,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":317,"config":318},"Team",{"href":319,"dataGaName":320,"dataGaLocation":45},"/company/team/","team",{"text":322,"config":323},"Handbuch",{"href":324,"dataGaName":325,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"Investor Relations",{"href":329,"dataGaName":330,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"Trust Center",{"href":334,"dataGaName":335,"dataGaLocation":45},"/de-de/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":45},"/de-de/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Presse",{"href":349,"dataGaName":350,"dataGaLocation":45},"/press/","press",{"text":352,"config":353,"lists":354},"Kontakt",{"dataNavLevelOne":294},[355],{"items":356},[357,360,365],{"text":52,"config":358},{"href":54,"dataGaName":359,"dataGaLocation":45},"talk to sales",{"text":361,"config":362},"Support-Portal",{"href":363,"dataGaName":364,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":366,"config":367},"Kundenportal",{"href":368,"dataGaName":369,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"Schließen",{"text":373,"link":374},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":375,"config":376},"gitlab.com",{"href":59,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"Vorschläge",[382,384,389,391,396,401],{"text":74,"config":383},{"href":79,"dataGaName":74,"dataGaLocation":378},{"text":385,"config":386},"Code Suggestions (KI)",{"href":387,"dataGaName":388,"dataGaLocation":378},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":390},{"href":110,"dataGaName":108,"dataGaLocation":378},{"text":392,"config":393},"GitLab auf AWS",{"href":394,"dataGaName":395,"dataGaLocation":378},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":397,"config":398},"GitLab auf Google Cloud",{"href":399,"dataGaName":400,"dataGaLocation":378},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":402,"config":403},"Warum GitLab?",{"href":87,"dataGaName":404,"dataGaLocation":378},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":50,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLab-Symbol",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":200,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"Erfahre mehr über GitLab Duo",{"href":79,"dataGaName":427,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":429},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":431},{"src":418,"dataGaName":415,"dataGaLocation":410},{"freeTrial":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"Zurück zur Preisübersicht",{"href":188,"dataGaName":436,"dataGaLocation":410,"icon":437},"back to pricing","GoBack",{"altText":412,"config":439},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":441},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":443,"button":444,"config":449},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":445,"config":446},"GitLab Transcend jetzt ansehen",{"href":447,"dataGaName":448,"dataGaLocation":45},"/de-de/events/transcend/virtual/","transcend event",{"layout":450,"icon":451,"disabled":12},"release","AiStar",{"data":453},{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":649},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":456,"config":457},"Quelltext der Seite anzeigen",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"Diese Seite bearbeiten",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"Beteilige dich",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,555,582,616],{"title":63,"links":478,"subMenu":483},[479],{"text":480,"config":481},"DevSecOps-Plattform",{"href":72,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":186,"links":485},[486,490,495],{"text":487,"config":488},"Tarife anzeigen",{"href":188,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Vorteile von Premium",{"href":493,"dataGaName":494,"dataGaLocation":460},"/de-de/pricing/premium/","why premium",{"text":496,"config":497},"Vorteile von Ultimate",{"href":498,"dataGaName":499,"dataGaLocation":460},"/de-de/pricing/ultimate/","why ultimate",{"title":501,"links":502},"Lösungen",[503,508,511,513,518,523,527,530,533,538,540,542,545,550],{"text":504,"config":505},"Digitale Transformation",{"href":506,"dataGaName":507,"dataGaLocation":460},"/de-de/topics/digital-transformation/","digital transformation",{"text":509,"config":510},"Sicherheit und Compliance",{"href":128,"dataGaName":135,"dataGaLocation":460},{"text":120,"config":512},{"href":104,"dataGaName":105,"dataGaLocation":460},{"text":514,"config":515},"Agile Entwicklung",{"href":516,"dataGaName":517,"dataGaLocation":460},"/de-de/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"Cloud-Transformation",{"href":521,"dataGaName":522,"dataGaLocation":460},"/de-de/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":117,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":108,"config":528},{"href":110,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":158,"config":531},{"href":160,"dataGaName":532,"dataGaLocation":460},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":460},"/de-de/solutions/gitops/","gitops",{"text":171,"config":539},{"href":173,"dataGaName":174,"dataGaLocation":460},{"text":176,"config":541},{"href":178,"dataGaName":179,"dataGaLocation":460},{"text":543,"config":544},"Öffentlicher Sektor",{"href":183,"dataGaName":184,"dataGaLocation":460},{"text":546,"config":547},"Bildungswesen",{"href":548,"dataGaName":549,"dataGaLocation":460},"/de-de/solutions/education/","education",{"text":551,"config":552},"Finanzdienstleistungen",{"href":553,"dataGaName":554,"dataGaLocation":460},"/de-de/solutions/finance/","financial services",{"title":191,"links":556},[557,559,561,563,566,568,570,572,574,576,578,580],{"text":203,"config":558},{"href":205,"dataGaName":206,"dataGaLocation":460},{"text":208,"config":560},{"href":210,"dataGaName":211,"dataGaLocation":460},{"text":213,"config":562},{"href":215,"dataGaName":216,"dataGaLocation":460},{"text":218,"config":564},{"href":220,"dataGaName":565,"dataGaLocation":460},"docs",{"text":241,"config":567},{"href":243,"dataGaName":244,"dataGaLocation":460},{"text":236,"config":569},{"href":238,"dataGaName":239,"dataGaLocation":460},{"text":246,"config":571},{"href":248,"dataGaName":249,"dataGaLocation":460},{"text":254,"config":573},{"href":256,"dataGaName":257,"dataGaLocation":460},{"text":259,"config":575},{"href":261,"dataGaName":262,"dataGaLocation":460},{"text":264,"config":577},{"href":266,"dataGaName":267,"dataGaLocation":460},{"text":269,"config":579},{"href":271,"dataGaName":272,"dataGaLocation":460},{"text":274,"config":581},{"href":276,"dataGaName":277,"dataGaLocation":460},{"title":292,"links":583},[584,586,588,590,592,594,596,600,605,607,609,611],{"text":299,"config":585},{"href":301,"dataGaName":294,"dataGaLocation":460},{"text":304,"config":587},{"href":306,"dataGaName":307,"dataGaLocation":460},{"text":312,"config":589},{"href":314,"dataGaName":315,"dataGaLocation":460},{"text":317,"config":591},{"href":319,"dataGaName":320,"dataGaLocation":460},{"text":322,"config":593},{"href":324,"dataGaName":325,"dataGaLocation":460},{"text":327,"config":595},{"href":329,"dataGaName":330,"dataGaLocation":460},{"text":597,"config":598},"Sustainability",{"href":599,"dataGaName":597,"dataGaLocation":460},"/sustainability/",{"text":601,"config":602},"Vielfalt, Inklusion und Zugehörigkeit",{"href":603,"dataGaName":604,"dataGaLocation":460},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":606},{"href":334,"dataGaName":335,"dataGaLocation":460},{"text":342,"config":608},{"href":344,"dataGaName":345,"dataGaLocation":460},{"text":347,"config":610},{"href":349,"dataGaName":350,"dataGaLocation":460},{"text":612,"config":613},"Transparenzerklärung zu moderner Sklaverei",{"href":614,"dataGaName":615,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":617,"links":618},"Nimm Kontakt auf",[619,622,627,629,634,639,644],{"text":620,"config":621},"Sprich mit einem Experten/einer Expertin",{"href":54,"dataGaName":55,"dataGaLocation":460},{"text":623,"config":624},"Support",{"href":625,"dataGaName":626,"dataGaLocation":460},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":366,"config":628},{"href":368,"dataGaName":369,"dataGaLocation":460},{"text":630,"config":631},"Status",{"href":632,"dataGaName":633,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":635,"config":636},"Nutzungsbedingungen",{"href":637,"dataGaName":638,"dataGaLocation":460},"/terms/","terms of use",{"text":640,"config":641},"Datenschutzerklärung",{"href":642,"dataGaName":643,"dataGaLocation":460},"/de-de/privacy/","privacy statement",{"text":645,"config":646},"Cookie-Einstellungen",{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":460},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":460},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":12},[658],{"id":659,"title":18,"body":8,"config":660,"content":662,"description":8,"extension":28,"meta":666,"navigation":12,"path":667,"seo":668,"stem":669,"__hash__":670},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":661},"BlogAuthor",{"name":18,"config":663},{"headshot":664,"ctfId":665},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[672,683,696],{"content":673,"config":681},{"title":674,"description":675,"authors":676,"heroImage":677,"date":678,"category":9,"tags":679,"body":680},"Was ist neu in Git 2.54.0?","Erfahre mehr über die Beiträge zu diesem Release, darunter neue Repository-Wartung, ein neuer Befehl zur Bearbeitung der Commit-Historie, ein Ersatz für git-sizer(1) und mehr.",[18],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1776711651/sj7xxyyuimlarswbyft5.png","2026-04-20",[25,23,262],"Das Git-Projekt hat kürzlich [Git 2.54.0](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf einige bemerkenswerte Highlights dieses Releases, das Beiträge des Git-Teams bei GitLab enthält.\n\n\n## Pluggable Object Databases\n\n\nGit bietet bereits die Möglichkeit, Referenzen entweder mit dem \"files\"-Backend oder dem [\"reftable\"-Backend](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/) zu speichern. Dies wird durch geeignete Abstraktionen in Git ermöglicht, die verschiedene Backends zulassen.\n\n\nReferenzen sind aber nur einer der beiden wichtigen Datentypen, die in Repositories gespeichert werden – der andere sind Objekte. Objekte werden in der Object Database gespeichert, und jede Object Database wiederum besteht aus mehreren Objektquellen, aus denen Objekte gelesen oder in die geschrieben werden kann. Jede Objektquelle speichert einzelne Objekte entweder als sogenannte \"Loose\"-Objekte oder komprimiert mehrere Objekte in ein \"Packfile\" im Verzeichnis `.git/objects`.\n\n\nBisher hatten diese Quellen jedoch keine echte Abstraktionsschicht, sodass das Speicherformat für Objekte komplett in Git fest verdrahtet war. Das ändert sich nun endlich mit Pluggable Object Databases! Das Konzept ist unkompliziert und ähnlich wie bei Referenzen: Statt fest verdrahteter Codepfade für die Objektspeicherung wird eine Abstraktionsschicht eingeführt, die verschiedene Backends für die Objektspeicherung ermöglicht.\n\n\nObwohl die Idee einfach ist, ist die Umsetzung komplex, da es überall in Git fest verdrahtete Annahmen über die verwendeten Speicherformate gibt. Die Arbeit an diesem Thema begann bereits mit Git 2.48, das im Januar 2025 veröffentlicht wurde. Der anfängliche Fokus lag darauf, objektbezogene Subsysteme eigenständig zu machen und geeignete Subsysteme für die bestehenden Backends in Git zu erstellen.\n\n\nMit Git 2.54 wurde nun ein Meilenstein erreicht: Das Object-Database-Backend ist jetzt pluggable. Noch wird nicht die gesamte Funktionalität von Git abgedeckt, aber die Einführung eines alternativen Backends, das eine sinnvolle Teilmenge der Operationen verarbeitet, ist jetzt ein realistisches Unterfangen.\n\n\nDerzeit funktionieren nur lokale Workflows wie das Erstellen von Commits, das Anzeigen von Commit-Graphen oder das Durchführen von Merges mit einer solchen alternativen Implementierung. Ausgenommen ist insbesondere alles, was mit einem Remote interagiert, zum Beispiel beim Fetchen oder Pushen von Änderungen. Dennoch ist dies das Ergebnis von fast zwei Jahren Arbeit über fast 400 Commits, die Upstream gemergt wurden, und die Arbeit daran wird natürlich fortgesetzt.\n\n\nWarum ist das relevant? Die Idee ist, dass es praktikabel wird, neue Speicherformate in Git einzuführen. Beispiele könnten sein:\n\n- Ein Speicherformat, das große Binärdateien effizienter speichern kann als es Packfiles heute tun\n\n- Ein Speicherformat, das speziell auf GitLab zugeschnitten ist, um Repositories noch effizienter bereitstellen zu können\n\n\nDies ist ein groß angelegtes Vorhaben, das die Zukunft von Git und GitLab maßgeblich prägen dürfte.\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Einfachere Bearbeitung der Commit-Historie\n\n\nIn vielen Softwareentwicklungsprojekten ist es gängige Praxis, nicht nur den Code zu verfeinern, sondern auch die Commit-Historie zu bereinigen, damit sie leicht überprüfbar ist. Das Ergebnis ist eine Reihe kleiner, atomarer Commits, die jeweils eine Sache tun, mit einer guten Commit-Nachricht, die die Intention des Commits sowie spezifische Nuancen beschreibt.\n\n\nNatürlich entstehen diese atomaren Commits meist nicht einfach von selbst während des Entwicklungsprozesses. Stattdessen gewinnt die Person, die die Änderungen erstellt, durch Iteration ein besseres Verständnis dafür, und die Art und Weise, die Commits aufzuteilen, wird mit der Zeit klarer. Darüber hinaus kann der anschließende Review-Prozess zu Feedback führen, das Änderungen an den erstellten Commits erfordert.\n\n\nDie Konsequenz dieses Prozesses ist, dass die Commit-Historie im Laufe der Entwicklung viele Male umgeschrieben werden muss. Historisch hat Git dafür [interaktive Rebases](https://git-scm.com/docs/git-rebase#_interactive_mode) vorgesehen. Diese interaktiven Rebases sind ein extrem leistungsfähiges Werkzeug: Sie ermöglichen es, Commits umzuordnen, Commit-Nachrichten umzuschreiben, mehrere Commits zusammenzufassen oder beliebige Bearbeitungen an jedem Commit vorzunehmen.\n\n\nAllerdings sind sie auch etwas kryptisch und schwer zu verstehen. Man muss den Basis-Commit für den Rebase bestimmen, verstehen, wie ein etwas obskures \"Instruction Sheet\" zu bearbeiten ist, und sich mit dem zustandsbehafteten Rebase-Prozess auskennen. Zum Beispiel wird beim Rebase eines Topic-Branch ein Instruction Sheet wie das folgende angezeigt:\n\n\n```shell\npick b60623f382 # t: detect errors outside of test cases # empty\npick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`\npick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`\npick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`\npick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`\npick ed0e7ca2b5 # t: detect errors outside of test cases\n```\n\n\nInteraktive Rebases sind also zwar leistungsfähig, aber auch ziemlich einschüchternd für durchschnittliche Nutzende.\n\n\nDas muss aber nicht so sein. Tools wie [Jujutsu](https://www.jj-vcs.dev/latest/) bieten Interfaces, die im Vergleich zu Git deutlich einfacher zu benutzen sind – zum Beispiel kann man einfach `jj split` ausführen, um einen Commit in zwei aufzuteilen. Bei Git mit interaktiven Rebases erfordert dieser Anwendungsfall viele verschiedene Schritte mit verwirrenden Befehlszeilenargumenten.\n\n\nInspiriert von Jujutsu wurde daher ein neuer Befehl git-history(1) in Git eingeführt, der die Grundlage für eine bessere Bearbeitung der Historie bildet. Derzeit hat dieser Befehl zwei Unterbefehle:\n\n\n- `git history reword` ermöglicht das einfache Umschreiben einer Commit-Nachricht. Man gibt den Commit an, dessen Nachricht umformuliert werden soll, Git fragt nach der neuen Commit-Nachricht, und das war's.\n\n- `git history split` ermöglicht das Aufteilen eines Commits in zwei, inspiriert von `jj split`. Man gibt einen Commit an, Git fragt, welche Änderungen in welchen Commit aufgenommen werden sollen und nach den beiden Commit-Nachrichten, und dann ist man fertig.\n\n\nDas ist natürlich erst der Anfang, und im Laufe der Zeit sollen weitere Unterbefehle hinzukommen. Zum Beispiel:\n\n\n- `git history fixup` um gestagete Änderungen automatisch in einen bestimmten Commit einzufügen\n\n- `git history drop` um einen Commit zu entfernen\n\n- `git history reorder` um die Reihenfolge von Commits zu ändern\n\n- `git history squash` um eine Reihe von Commits zusammenzufassen\n\n\nAber das ist noch nicht alles! Zusätzlich zur einfachen Bearbeitung der Historie kann dieser neue Befehl auch automatisch alle lokalen Branches rebasen, die den bearbeiteten Commit zuvor enthielten. Das bedeutet, man kann sogar einen Commit bearbeiten, der nicht auf dem aktuellen Branch liegt, und alle Branches, die den Commit enthalten, werden umgeschrieben.\n\n\nEs mag zunächst überraschend erscheinen, dass Git automatisch abhängige Branches rebast, da dies eine deutliche Abweichung von der Funktionsweise von git-rebase(1) darstellt. Dies ist aber Teil eines größeren Vorhabens, um bessere Unterstützung für Stacked Diffs in Git zu bringen – eine Methode, eine Reihe mehrerer abhängiger Branches zu erstellen, die unabhängig voneinander überprüft werden können, aber gemeinsam auf ein größeres Ziel hinarbeiten.\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) mit Unterstützung von [Elijah Newren](https://github.com/newren) geleitet.*\n\n\n## Ein nativer Ersatz für git-sizer(1)\n\n\nDie Größe eines Git-Repositorys ist ein wichtiger Faktor, der bestimmt, wie gut Git und GitLab damit umgehen können. Aber die Größe allein ist nicht der einzige Faktor, da die Performance eines Repositorys letztlich eine Kombination aus mehreren verschiedenen Dimensionen ist:\n\n\n- Die Tiefe der Commit-Historie\n\n- Die Struktur des Verzeichnisbaums\n\n- Die Größe der im Repository gespeicherten Dateien\n\n- Die Anzahl der Referenzen\n\n\nDas sind nur einige der Dimensionen, die berücksichtigt werden müssen, wenn man vorhersagen will, ob Git ein Repository gut verarbeiten kann.\n\n\nObwohl klar ist, dass die reine Repository-Größe nicht ausreicht, bietet Git selbst keine Tools, die einen einfachen Überblick über diese Metriken geben. Stattdessen ist man auf Drittanbieter-Tools wie [git-sizer(1)](https://github.com/github/git-sizer) angewiesen, um diese Lücke zu füllen. Dieses Tool leistet hervorragende Arbeit bei der Darstellung dieser Informationen, ist aber kein Bestandteil von Git und muss daher separat installiert werden.\n\n\nObservability von Repository-Interna ist bei GitLab entscheidend, daher wurde in [Git 2.52 ein neuer `git repo structure`-Befehl eingeführt](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-52-0/#new-subcommand-for-git-repo1-to-display-repository-metrics), um Repository-Metriken anzuzeigen, der in Git 2.53 erweitert wurde, um [inflated und Disk-Sizes für Objekte nach Typ anzuzeigen](https://about.gitlab.com/blog/whats-new-in-git-2-53-0/#more-data-collected-in-git-repo-structure).\n\n\nIn Git 2.54 wird dieser Befehl weiter ausgebaut, sodass nicht nur die Gesamtgröße angezeigt wird, sondern auch die größten Objekte nach Typ:\n\n\n```shell\n$ git clone https://gitlab.com/git-scm/git.git\n$ cd git\n$ git repo structure\nCounting objects: 410445, done.\n| Repository structure      | Value       |\n| ------------------------- | ----------- |\n| * References              |             |\n|   * Count                 |    1.01 k   |\n|     * Branches            |       1     |\n|     * Tags                |    1.00 k   |\n|     * Remotes             |       9     |\n|     * Others              |       0     |\n|                           |             |\n| * Reachable objects       |             |\n|   * Count                 |  410.45 k   |\n|     * Commits             |   83.99 k   |\n|     * Trees               |  164.46 k   |\n|     * Blobs               |  161.00 k   |\n|     * Tags                |    1.00 k   |\n|   * Inflated size         |    7.46 GiB |\n|     * Commits             |   57.53 MiB |\n|     * Trees               |    2.33 GiB |\n|     * Blobs               |    5.07 GiB |\n|     * Tags                |  737.48 KiB |\n|   * Disk size             |  181.37 MiB |\n|     * Commits             |   33.11 MiB |\n|     * Trees               |   40.58 MiB |\n|     * Blobs               |  107.11 MiB |\n|     * Tags                |  582.67 KiB |\n|                           |             |\n| * Largest objects         |             |\n|   * Commits               |             |\n|     * Maximum size    [1] |   17.23 KiB |\n|     * Maximum parents [2] |      10     |\n|   * Trees                 |             |\n|     * Maximum size    [3] |   58.85 KiB |\n|     * Maximum entries [4] |    1.18 k   |\n|   * Blobs                 |             |\n|     * Maximum size    [5] | 1019.51 KiB |\n|   * Tags                  |             |\n|     * Maximum size    [6] |    7.13 KiB |\n\n[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf\n[2] 16d7601e176cd53f3c2f02367698d06b85e08879\n[3] 203ee97047731b9fd3ad220faa607b6677861a0d\n[4] 203ee97047731b9fd3ad220faa607b6677861a0d\n[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543\n[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc\n```\n\n\nMit diesen Informationen ist die Funktionsparität mit git-sizer(1) nahezu erreicht. Ganz fertig ist die Arbeit aber noch nicht – geplant sind weitere Features wie:\n\n\n- Severity Levels wie sie in git-sizer(1) existieren\n\n- Graphen, die die Verteilung der Objektgrößen visualisieren\n\n- Die Möglichkeit, Objekte zu scannen, die über eine Teilmenge von Referenzen erreichbar sind\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n## Neue Infrastruktur für Repository-Wartung\n\n\nBeim Schreiben von Daten in ein Git-Repository entstehen in der Regel weitere Loose-Objekte. Ohne Verwaltung führt dies zu einer großen Anzahl separater Dateien im Verzeichnis `.git/objects/`, was mehrere Operationen verlangsamt, die auf viele Objekte gleichzeitig zugreifen wollen. Git packt diese Objekte daher regelmäßig in \"Packfiles\", um eine gute Performance sicherzustellen.\n\n\nDas ist aber nicht die einzige Datenstruktur, die im Laufe der Zeit ineffizient werden kann: Das Aktualisieren von Referenzen kann Loose-Referenzen erzeugen, Reflogs müssen getrimmt, Worktrees können veralten, und Caches wie Commit-Graphen müssen regelmäßig aktualisiert werden.\n\n\nAll diese Aufgaben wurden historisch von [git-gc(1)](https://git-scm.com/docs/git-gc) verwaltet. Dieses Tool hat jedoch eine monolithische Architektur, in der es im Grunde alle erforderlichen Aufgaben sequenziell ausführt. Diese Grundlage ist schwer erweiterbar und bietet wenig Flexibilität, wenn die Wartung leicht angepasst werden soll.\n\n\nDas Git-Projekt führte in Git 2.29 das neue Tool [git-maintenance(1)](https://git-scm.com/docs/git-maintenance) ein. Im Gegensatz zu git-gc(1) ist git-maintenance(1) nicht monolithisch, sondern um Tasks herum strukturiert. Diese Tasks sind frei konfigurierbar, sodass kontrolliert werden kann, welche Tasks ausgeführt werden, was eine deutlich feinere Kontrolle über die Repository-Wartung ermöglicht.\n\n\nSchließlich wurde Git standardmäßig auf git-maintenance(1) umgestellt. Zu Beginn war allerdings der einzige standardmäßig aktivierte Task der git-gc(1)-Task, der – wie der Name vermuten lässt – einfach `git gc` ausführt. Um die Wartung manuell mit dem neuen Befehl auszuführen, kann `git maintenance run` aufgerufen werden, aber Git führt dies auch automatisch nach verschiedenen anderen Befehlen aus.\n\n\nIn den letzten Releases wurden alle einzelnen Tasks implementiert, die von git-gc(1) unterstützt werden, auch in git-maintenance(1), um Funktionsparität zwischen den beiden Tools sicherzustellen.\n\n\nDarüber hinaus wurde ein neuer Task implementiert, der Gits moderne Architektur für das Repacking von Objekten mit [Geometric Compaction](https://git-scm.com/docs/git-repack#Documentation/git-repack.txt---geometricfactor) nutzt. Geometric Compaction eignet sich deutlich besser für große Monorepos, und mit den Arbeiten zur Kompatibilität mit Partial Clones, [die in Git 2.53 eingeflossen sind](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-53-0/#geometric-repacking-support-with-promisor-remotes), stellen sie jetzt einen vollständigen Ersatz für die bisherige Repacking-Strategie in Git dar.\n\n\nMit Git 2.54 wurde nun ein weiterer bedeutender Meilenstein erreicht: Statt der bisherigen git-gc(1)-basierten Strategie wird jetzt standardmäßig Geometric Repacking mit feingranularen individuellen Wartungs-Tasks verwendet! Neben der höheren Effizienz für große Monorepos stellt dies auch eine einfachere Grundlage für zukünftige Weiterentwicklungen sicher.\n\n\n*Die git-maintenance(1)-Infrastruktur wurde ursprünglich von [Derrick Stolee](https://github.com/derrickstolee) implementiert, und Geometric Maintenance wurde von [Taylor Blau](https://github.com/ttaylorr) eingeführt. Die Arbeit zur Einführung der neuen feingranularen Tasks und die Migration zur neuen Wartungsstrategie wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Weiterlesen\n\n\nDieser Artikel hat nur einige der Beiträge hervorgehoben, die von GitLab und der breiteren Git-Community zu diesem aktuellen Release geleistet wurden. Weitere Informationen dazu finden sich in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u) des Git-Projekts. Außerdem lohnt sich ein Blick in die [früheren Git-Release-Blogposts](https://about.gitlab.com/blog/tags/git/), um weitere vergangene Highlights der Beiträge von GitLab-Teammitgliedern zu sehen.\n",{"slug":682,"featured":33,"template":13},"whats-new-in-git-2-54-0",{"content":684,"config":694},{"title":685,"description":686,"authors":687,"heroImage":689,"date":690,"body":691,"category":9,"tags":692,"updatedDate":690},"Kubernetes: Container-Orchestrierung verstehen und einsetzen","Kubernetes (K8s) für containerisierte Anwendungen: Dieser Artikel erklärt Architektur, Vorteile, Grenzen und den Einsatz mit GitLab.",[688],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660215/Blog/Hero%20Images/kubernetes-container-orchestration-solution.jpg","2026-03-02","Kubernetes automatisiert die Bereitstellung und Verwaltung\ncontainerisierter Anwendungen in großem Maßstab. Mit der Zeit ist\nKubernetes zu einem zentralen Werkzeug für die Anwendungsentwicklung\ngeworden – etwa in den Bereichen\n[Microservices](https://about.gitlab.com/de-de/topics/microservices/),\nWebanwendungen und Datenbanken. Leistungsfähigkeit und Skalierbarkeit\nmachen K8s heute zum anerkannten Standard im Container-Management.\n\nDieser Artikel bietet einen umfassenden Einstieg in Kubernetes.\n\n## Was ist Kubernetes?\n\nKubernetes ist ein Open-Source-System zur effizienten Orchestrierung von\nContainern einer Softwareanwendung. Containerisierung ist ein weit\nverbreiteter Ansatz in der Anwendungsentwicklung – besonders im Bereich\nder digitalen Transformation und der Cloud.\n\nZur Erinnerung: **Containerisierung ist eine Methode der\nAnwendungsentwicklung, bei der die Komponenten einer Anwendung in\nstandardisierte, geräte- und betriebssystemunabhängige Einheiten –\nsogenannte Container – zusammengefasst werden.** Durch die Isolierung von\nAnwendungen von ihrer Umgebung erleichtert diese Technologie die\nBereitstellung und Portabilität und reduziert Kompatibilitätsprobleme.\n\nHier kommt Kubernetes ins Spiel. Container ermöglichen zwar die Aufteilung\nvon Anwendungen in kleinere, eigenständige Module, die leichter\nbereitzustellen sind. Damit Container jedoch innerhalb einer Anwendung\nzusammenarbeiten können, ist ein übergeordnetes Verwaltungssystem\nerforderlich. Genau das leistet Kubernetes: Die Plattform steuert, wo und\nwie Container ausgeführt werden, und ermöglicht so die Orchestrierung und\nPlanung containerisierter Anwendungen in großem Maßstab.\n\n> Weitere [GitLab-Artikel zu Kubernetes](https://about.gitlab.com/de-de/blog/tags/kubernetes/).\n\n## Wie funktioniert eine Kubernetes-Architektur?\n\nUm die Kubernetes-Architektur zu verstehen, sind einige grundlegende\nKonzepte wichtig – allen voran das des Clusters, der die umfassendste\nEinheit innerhalb der Architektur darstellt. Ein Kubernetes-Cluster ist\ndie Gesamtheit der virtuellen oder physischen Maschinen, auf denen eine\ncontainerisierte Anwendung betrieben wird.\n\n![Komponenten von\nKubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673941/Blog/Content%20Images/components-of-kubernetes.png)\n\nQuelle:\n[Kubernetes](https://kubernetes.io/docs/concepts/overview/components/).\n\nEin Cluster besteht aus verschiedenen Elementen:\n- Node: Eine Arbeitseinheit im Kubernetes-Cluster – eine virtuelle oder\nphysische Maschine, die Aufgaben im Auftrag der Anwendung übernimmt.\n- Pod: Der kleinste bereitstellbare Baustein in Kubernetes. Ein Pod ist\neine Gruppe von Containern, die gemeinsam auf demselben Node ausgeführt\nwerden. Container innerhalb eines Pods teilen dasselbe Netzwerk und\nkommunizieren über localhost miteinander.\n- Service: Ein Kubernetes-Service macht einen Pod für das Netzwerk oder\nandere Pods zugänglich und bietet einen stabilen, klar definierten\nZugangspunkt zu den in Pods gehosteten Anwendungen.\n- Volume: Eine Ordnerabstraktion, die Probleme beim Teilen und Abrufen\nvon Dateien innerhalb eines Containers löst.\n- Namespace: Ein Namespace ermöglicht die Gruppierung und Isolierung von\nRessourcen zu einem virtuellen Cluster.\n\nDie Kubernetes-Architektur basiert auf zwei Knotentypen: dem Master Node\nund den Worker Nodes. Der Master Node ist für die übergeordnete Verwaltung\ndes Kubernetes-Clusters und die Kommunikation mit den Worker Nodes\nzuständig. Zu seinen zentralen Komponenten zählt die API als\nKommunikationszentrum zwischen Nutzenden und Cluster. Das\n[etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd)\nist die Key-Value-Datenbank, in der Konfigurationen, Systemzustand und\nObjekt-Metadaten gespeichert werden. Der Controller Manager koordiniert\nHintergrundoperationen wie die Pod-Replikation, der Scheduler platziert\nPods auf Nodes entsprechend der verfügbaren Ressourcen.\n\nWorker Nodes hingegen sind die Maschinen, auf denen die in den Pods\nenthaltenen Anwendungen ausgeführt und verwaltet werden. Das\n[kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet)\nist der Agent, der auf jedem Node läuft und mit dem Master kommuniziert,\num Befehle zu empfangen und den Status der Pods zu übermitteln. Der\nNetzwerk-Proxy\n[kube-proxy](https://kubernetes.io/docs/concepts/overview/components/)\npflegt die Netzwerkregeln auf den Nodes und ermöglicht so den Zugriff auf\nServices von außerhalb des Kubernetes-Clusters. Die Container-Runtime\nschließlich ist die Software, die für die Ausführung und Verwaltung der\nContainer innerhalb der Pods verantwortlich ist.\n\n### Die Rolle von Docker\n\nBei allen Komponenten eines K8s-Clusters ist die Wahl der Runtime innerhalb\nder Worker Nodes von Bedeutung. Verschiedene Softwarelösungen stehen dafür\nzur Verfügung, etwa CRI-O – Docker ist jedoch das am häufigsten eingesetzte\nWerkzeug.\n\n### Was ist der Unterschied zwischen Docker und Kubernetes?\n\nDocker ist eine Open-Source-Lösung, die speziell auf Container-Ebene\neingesetzt wird. Sie ermöglicht die Paketierung von Containern in einem\nstandardisierten und schlanken Format, was ihre Portabilität in\nverschiedenen Umgebungen erhöht. Docker ist damit ein ergänzendes Werkzeug\nzu K8s: Es vereinfacht die Verwaltung der Container selbst, während\nKubernetes deren Integration und Kommunikation innerhalb der Anwendung\nerleichtert.\n\n## Welche Vorteile bietet Kubernetes?\n\nSeit dem Start durch Google im Jahr 2014 und der ersten stabilen Version\nim Juli 2015 hat sich Kubernetes als Referenz im Bereich der\nContainer-Orchestrierung etabliert – insbesondere für\nMicroservice-orientierte Architekturen. Diese Verbreitung ist vor allem\nauf die Leistungsfähigkeit von K8s in der Container-Orchestrierung\nzurückzuführen.\n\nDie Vorteile von Kubernetes im Überblick:\n- Automatisierung: Kubernetes erleichtert die Automatisierung von Aufgaben\nrund um Bereitstellung, Skalierung und Aktualisierung containerisierter\nAnwendungen.\n- Flexibilität: Die Software passt sich an unterschiedliche\nContainer-Technologien sowie verschiedene Hardware-Architekturen und\nBetriebssysteme an.\n- Skalierbarkeit: K8s ermöglicht die Bereitstellung und Verwaltung\ntausender Container – unabhängig von deren Status: laufend, pausiert oder\ngestoppt.\n- Migration: Anwendungen lassen sich zu Kubernetes migrieren, ohne den\nQuellcode ändern zu müssen.\n- Multi-Cluster-Unterstützung: Kubernetes verwaltet zentral mehrere\nContainer-Cluster, die über verschiedene Infrastrukturen verteilt sind.\n- Update-Management: Die Software unterstützt Rolling-Update-Deployments,\num Anwendungen ohne Serviceunterbrechung zu aktualisieren.\n\n## Ein robustes und skalierbares Ökosystem\n\nKubernetes zeichnet sich durch die Fähigkeit aus, Container effizient und\nzuverlässig zu verwalten und dabei unabhängig von Cloud-Infrastrukturanbietern\nzu bleiben. Die modulare Architektur passt sich den spezifischen\nAnforderungen jedes Unternehmens an und unterstützt ein breites Spektrum\nan Anwendungen und Diensten – von Webservices über Datenverarbeitung bis\nhin zu mobilen Anwendungen.\n\nKubernetes profitiert dabei von einem umfangreichen und aktiven\nOpen-Source-Ökosystem. Verwaltet von der Cloud Native Computing Foundation\n([CNCF](https://www.cncf.io/)), wird K8s von tausenden Entwicklerinnen\nund Entwicklern weltweit unterstützt, die kontinuierlich zur\nWeiterentwicklung des Projekts und seiner Funktionen beitragen.\n\n## Was sind die Grenzen von Kubernetes?\n\nDie Stärken von Kubernetes machen es für viele Entwicklungsteams im\nCloud-nativen Bereich zur soliden Grundlage. Dennoch lohnt es sich,\neinige Einschränkungen zu benennen. Kubernetes erfordert fundierte\ntechnische Kenntnisse sowie die Einarbeitung in neue Entwicklungskonzepte\nund -methoden. Die Konfiguration kann zu Beginn eines Projekts komplex\nsein – ist dabei aber entscheidend, insbesondere für die Absicherung der\nPlattform. Ein erfahrenes Entwicklungsteam mit K8s-Kenntnissen ist daher\nein wesentlicher Vorteil.\n\nEine weitere Herausforderung ist die Implementierung und Wartung einer\nK8s-Architektur, die Zeit und Ressourcen erfordert – vor allem für die\nAktualisierung der verschiedenen Komponenten und Softwareteile. Dabei\nstellt sich auch die Frage nach möglichem Oversizing: Bei kleineren\nAnwendungen oder Projekten ohne besondere Skalierungsanforderungen kann\neine einfachere Architektur ausreichend und wirtschaftlicher sein.\n\n## Kubernetes im Unternehmenseinsatz\n\nZehntausende Unternehmen haben eine Kubernetes-Architektur für ihre\ndigitale Transformation übernommen. K8s wird von Organisationen aller\nGrößen genutzt – von Startups bis zu multinationalen Konzernen.\n\nEin Beispiel für eine erfolgreiche Integration ist Haven Technologies.\nDas Unternehmen hat seine SaaS-Dienste zu K8s migriert. Dabei setzt es\nauf eine Kubernetes-Strategie mit der GitLab-DevSecOps-Plattform –\nmit messbaren Verbesserungen bei Effizienz, Sicherheit und\nEntwicklungsgeschwindigkeit. Weitere Details in der\n[Kundenreferenz](https://about.gitlab.com/customers/haven-technologies/).\n\n## Kubernetes, Git und GitLab\n\nKubernetes, Git und GitLab sind zentrale Bausteine der DevOps-Landschaft.\nKubernetes bietet hohe Flexibilität bei der Bereitstellung und Verwaltung\nder verschiedenen Anwendungskomponenten. GitLab – aufgebaut auf Git und\ndessen nativer Versionskontrolle – ermöglicht eine präzise Nachverfolgung\nvon Quellcode und Änderungen und stellt eine umfassende Werkzeugsammlung\nfür den gesamten Software-Entwicklungslebenszyklus bereit.\n\nDiese Kombination schafft gemeinsam mit einem\n[GitOps-Ansatz](https://about.gitlab.com/de-de/topics/gitops/), der die\nAutomatisierung moderner Cloud-Infrastrukturen zum Ziel hat, eine agile\nUmgebung für Anwendungsentwicklung und -bereitstellung. Alle\n[GitLab-Lösungen für den Einsatz mit Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/)\nim Überblick.\n\n## Kubernetes FAQ\n\n### Welche Alternativen zu K8s gibt es?\n\nEs gibt verschiedene Alternativen zu Kubernetes, darunter Docker Swarm\nund Marathon. Kubernetes gilt jedoch als die ausgereifteste und am\nweitesten verbreitete Lösung auf dem Markt. Die große Nutzerbasis,\numfangreiche Dokumentation und eine aktive Community machen K8s zur\nsoliden Wahl für alle, die ein Container-Orchestrierungssystem einsetzen\nmöchten.\n\n### Was ist ein Kubernetes-Cluster?\n\nEin Kubernetes-Cluster besteht aus einem Master Node und mehreren Worker\nNodes. Der Master Node koordiniert die Aufgaben im Cluster, während die\nWorker Nodes diese Orchestrierungsaufgaben ausführen und die Container\nhosten. K8s-Cluster sind hoch skalierbar – Nodes lassen sich hinzufügen\noder entfernen, um die Clusterressourcen an die Anforderungen der Anwendung\nanzupassen.\n\n### Wie startet man mit Kubernetes?\n\nZunächst ist die Installation der Kubernetes-Software in einer kompatiblen\nUmgebung (Linux, macOS oder Windows) erforderlich. Kubernetes lässt sich\nsowohl in einer klassischen Hosting-Umgebung als auch in der Cloud\ninstallieren – etwa auf Google Kubernetes Engine oder Amazon EKS. Nach\ndem Download und der Installation von der offiziellen Website folgt die\nErstkonfiguration zur Verbindung von Master und Worker Nodes. Danach ist\ndie erste Anwendung mit Kubernetes einsatzbereit.\n\n### Warum Kubernetes wählen?\n\nKubernetes bietet hohe Flexibilität und vollständige Portabilität zwischen\nverschiedenen Cloud-Plattformen oder On-Premises-Infrastrukturen. Durch\ndie Automatisierung von Orchestrierungsaufgaben lassen sich Ressourcen\noptimieren und Betriebskosten senken. Das Kubernetes-Ökosystem ist\numfangreich und wird von einer großen Open-Source-Community\nkontinuierlich weiterentwickelt.\n\n## Mehr erfahren\n\n- [Logs über das GitLab Dashboard für Kubernetes streamen](https://about.gitlab.com/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes/)\n- [Kubernetes-Überblick: Cluster-Daten im Frontend verwalten](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/)\n- [Cloud-Account-Management für Kubernetes-Zugriff vereinfachen](https://about.gitlab.com/blog/simplify-your-cloud-account-management-for-kubernetes-access/)\n",[693,25],"kubernetes",{"slug":695,"featured":33,"template":13},"kubernetes-the-container-orchestration-solution",{"content":697,"config":706},{"title":698,"description":699,"authors":700,"date":702,"body":703,"heroImage":704,"category":9,"tags":705},"Was ist neu in Git 2.53.0?","Alles, was du über dieses Release wissen musst, darunter Fixes für geometrisches Repacking, Updates zu den Commit-Signature-Handling-Optionen von git-fast-import(1) und mehr.",[701],"Justin Tobler","2026-02-02","Das Git-Projekt hat kürzlich [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) veröffentlicht. Schauen wir uns einige Highlights dieses Releases an, das auch Beiträge vom Git-Team bei GitLab enthält.\n\n## Unterstützung für geometrisches Repacking mit Promisor Remotes\n\nNeu geschriebene Objekte in einem Git-Repository werden oft als einzelne Loose Files gespeichert. Um gute Performance und optimale Nutzung des Speicherplatzes zu gewährleisten, werden diese Loose Objects regelmäßig in sogenannte Packfiles komprimiert. Die Anzahl der Packfiles in einem Repository wächst im Laufe der Zeit durch die Aktivitäten des Users, wie das Schreiben neuer Commits oder das Fetchen von einem Remote. Je mehr Packfiles sich in einem Repository befinden, desto mehr Arbeit hat Git beim Nachschlagen einzelner Objekte. Um die optimale Repository-Performance zu erhalten, werden Packfiles daher regelmäßig über git-repack(1) neu gepackt, um die Objekte in weniger Packfiles zu konsolidieren. Beim Repacking gibt es zwei Strategien: „All-into-One\" und „Geometric\".\n\nDie All-into-One-Strategie ist relativ unkompliziert und derzeit der Standard. Wie der Name schon sagt, werden alle Objekte im Repository in ein einziges Packfile gepackt. Aus Performance-Sicht ist das großartig für das Repository, da Git nur ein einzelnes Packfile durchsuchen muss, um Objekte nachzuschlagen. Der Hauptnachteil dieser Repacking-Strategie ist, dass die Berechnung eines einzigen Packfiles für ein Repository bei großen Repositories erheblich viel Zeit in Anspruch nehmen kann.\n\nDie Geometric-Strategie hilft, dieses Problem zu entschärfen, indem sie eine geometrische Progression von Packfiles basierend auf ihrer Größe beibehält, anstatt immer in ein einziges Packfile neu zu packen. Also: Beim Repacking pflegt Git eine Reihe von Packfiles, die nach Größe geordnet sind, wobei jedes Packfile in der Sequenz mindestens doppelt so groß sein soll wie das vorhergehende Packfile. Wenn ein Packfile in der Sequenz diese Eigenschaft verletzt, werden Packfiles bei Bedarf kombiniert, bis die Progression wiederhergestellt ist. Diese Strategie hat den Vorteil, dass sie die Anzahl der Packfiles in einem Repository minimiert und gleichzeitig den Arbeitsaufwand für die meisten Repacking-Operationen minimiert.\n\nEin Problem mit der geometrischen Repacking-Strategie war, dass sie nicht mit Partial Clones kompatibel war. Partial Clones ermöglichen es dir, nur Teile eines Repositorys zu klonen, indem du zum Beispiel alle Blobs größer als 1 Megabyte überspringst. Das kann die Größe eines Repositorys erheblich reduzieren, und Git weiß, wie es fehlende Objekte nachträglich abrufen kann, auf die es zu einem späteren Zeitpunkt zugreifen muss.\n\nDas Ergebnis ist ein Repository, dem einige Objekte fehlen, und jedes Objekt, das möglicherweise nicht vollständig verbunden ist, wird in einem „Promisor\"-Packfile gespeichert. Beim Repacking muss diese Promisor-Eigenschaft für Packfiles, die ein Promisor-Objekt enthalten, beibehalten werden, damit bekannt ist, ob ein fehlendes Objekt erwartet wird und vom Promisor Remote nachgeladen werden kann. \n\nBei einem All-into-One-Repack weiß Git, wie es Promisor-Objekte richtig behandelt und speichert sie in einem separaten Promisor-Packfile. Leider wusste die geometrische Repacking-Strategie nicht, Promisor-Packfiles eine Sonderbehandlung zu geben, und würde sie stattdessen mit normalen Packfiles zusammenführen, ohne zu berücksichtigen, ob sie auf Promisor-Objekte verweisen. Glücklicherweise schlägt aufgrund eines Bugs das zugrunde liegende git-pack-objects(1) fehl, wenn geometrisches Repacking in einem Partial-Clone-Repository verwendet wird. Das bedeutet, dass Repositories in dieser Konfiguration sowieso nicht neu gepackt werden konnten, was nicht großartig ist, aber besser als Repository-Korruption.\n\nMit dem Release von Git 2.53 funktioniert geometrisches Repacking jetzt mit Partial-Clone-Repositories. Bei einem geometrischen Repack werden Promisor-Packfiles separat behandelt, um die Promisor-Markierung zu erhalten, und nach einer separaten geometrischen Progression neu gepackt. Mit diesem Fix rückt die geometrische Strategie näher daran, die Standard-Repacking-Strategie zu werden. Für weitere Informationen schau dir den entsprechenden [Mailing-List-Thread](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/) an.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## git-fast-import(1) hat gelernt, nur gültige Signaturen zu erhalten\n\nIn unserem [Git 2.52 Release-Artikel](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-52-0/) haben wir signatur-bezogene Verbesserungen an git-fast-import(1) und git-fast-export(1) behandelt. Schau dir diesen Post unbedingt an für eine detailliertere Erklärung dieser Befehle, wie sie verwendet werden und welche Änderungen in Bezug auf Signaturen vorgenommen werden.\n\nUm es kurz zusammenzufassen: git-fast-import(1) bietet ein Backend zum effizienten Importieren von Daten in ein Repository und wird von Tools wie [git-filter-repo(1)](https://github.com/newren/git-filter-repo) verwendet, um die History eines Repositorys in großem Umfang neu zu schreiben. Im Git 2.52 Release hat git-fast-import(1) die Option `--signed-commits=\u003Cmode>` gelernt, ähnlich wie die gleiche Option in git-fast-export(1). Mit dieser Option wurde es möglich, Signaturen von Commits/Tags ohne Bedingung beizubehalten oder zu entfernen.\n\nIn Situationen, in denen nur ein Teil der Repository-History neu geschrieben wurde, wird jede Signatur für neu geschriebene Commits/Tags ungültig. Das bedeutet, dass git-fast-import(1) darauf beschränkt ist, entweder alle Signaturen zu entfernen oder alle Signaturen zu behalten, selbst wenn sie ungültig geworden sind. Aber ungültige Signaturen zu behalten, macht nicht viel Sinn, daher führt das Neuschreiben der History mit git-filter-repo(1) dazu, dass alle Signaturen entfernt werden, selbst wenn der zugrunde liegende Commit/Tag nicht neu geschrieben wurde. Das ist schade, denn wenn der Commit/Tag unverändert ist, ist seine Signatur noch gültig, und es gibt daher keinen wirklichen Grund, sie zu entfernen. Was wirklich benötigt wird, ist eine Möglichkeit, Signaturen für unveränderte Objekte zu erhalten, aber ungültige zu entfernen.\n\nMit dem Release von Git 2.53 hat die Option `--signed-commits=\u003Cmode>` von git-fast-import(1) einen neuen Modus `strip-if-invalid` gelernt, der, wenn angegeben, nur Signaturen von Commits entfernt, die durch das Neuschreiben ungültig werden. Mit dieser Option wird es also möglich, einige Commit-Signaturen bei der Verwendung von git-fast-import(1) zu erhalten. Das ist ein entscheidender Schritt zur Bereitstellung der Grundlage für Tools wie git-filter-repo(1), um gültige Signaturen zu erhalten und schließlich ungültige Signaturen neu zu signieren.\n\nDieses Projekt wurde von [Christian Couder](https://gitlab.com/chriscool) geleitet.\n\n## Mehr Daten in git-repo-structure gesammelt\n\nIm Git 2.52 Release wurde der „structure\"-Subcommand zu git-repo(1) eingeführt. Die Absicht dieses Befehls war es, Informationen über das Repository zu sammeln und schließlich ein nativer Ersatz für Tools wie [git-sizer(1)](https://github.com/github/git-sizer) zu werden. Bei GitLab hosten wir einige extrem große Repositories, und Einblicke in die allgemeine Struktur eines Repositorys sind entscheidend, um seine Performance-Charakteristiken zu verstehen. In diesem Release sammelt der Befehl jetzt auch Informationen zur Gesamtgröße von erreichbaren Objekten in einem Repository, um die Gesamtgröße des Repositorys zu verstehen. In der folgenden Ausgabe kannst du sehen, dass der Befehl jetzt sowohl die gesamten Inflated- als auch Disk-Größen von erreichbaren Objekten nach Objekttyp sammelt.\n\n```shell\n\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n\n```\n\nWer genau hinschaut, dem fällt vielleicht auch auf, dass die Größenwerte in der Tabellenausgabe jetzt auch benutzerfreundlicher mit angehängten Einheiten aufgelistet werden. In zukünftigen Releases hoffen wir, die Ausgabe dieses Befehls weiter zu erweitern, um zusätzliche Datenpunkte bereitzustellen, wie zum Beispiel die größten einzelnen Objekte im Repository.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## Mehr erfahren\n\nDieser Artikel hat nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses neueste Release hervorgehoben. Du kannst mehr über diese aus der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) des Git-Projekts erfahren. Schau dir auch unsere [früheren Git-Release-Blogposts](https://about.gitlab.com/blog/tags/git/) an, um andere vergangene Highlights von Beiträgen der GitLab-Teammitglieder zu sehen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[25,23,262],{"featured":33,"template":13,"slug":707},"whats-new-in-git-2-53-0",{"promotions":709},[710,724,737,749],{"id":711,"categories":712,"header":714,"text":715,"button":716,"image":721},"ai-modernization",[713],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":717,"config":718},"Get your AI maturity score",{"href":719,"dataGaName":720,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":722},{"src":723},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":725,"categories":726,"header":729,"text":715,"button":730,"image":734},"devops-modernization",[727,728],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":731,"config":732},"Get your DevOps maturity score",{"href":733,"dataGaName":720,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":738,"categories":739,"header":741,"text":715,"button":742,"image":746},"security-modernization",[740],"security","Are you trading speed for security?",{"text":743,"config":744},"Get your security maturity score",{"href":745,"dataGaName":720,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":747},{"src":748},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":750,"paths":751,"header":754,"text":755,"button":756,"image":761},"github-azure-migration",[752,753],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":757,"config":758},"See how GitLab compares to GitHub",{"href":759,"dataGaName":760,"dataGaLocation":244},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":762},{"src":736},{"header":764,"blurb":765,"button":766,"secondaryButton":771},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":767,"config":768},"Kostenlosen Test starten",{"href":769,"dataGaName":50,"dataGaLocation":770},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":52,"config":772},{"href":54,"dataGaName":55,"dataGaLocation":770},1777302577177]