[{"data":1,"prerenderedAt":764},["ShallowReactive",2],{"/de-de/blog/keeping-git-commit-history-clean":3,"navigation-de-de":37,"banner-de-de":441,"footer-de-de":451,"blog-post-authors-de-de-Kushal Pandya":656,"blog-related-posts-de-de-keeping-git-commit-history-clean":670,"assessment-promotions-de-de":714,"next-steps-de-de":754},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":28,"path":29,"publishedDate":20,"seo":30,"stem":34,"tagSlugs":35,"__hash__":36},"blogPosts/de-de/blog/keeping-git-commit-history-clean.yml","Keeping Git Commit History Clean",[7],"kushal-pandya",null,"engineering",{"slug":11,"featured":12,"template":13},"keeping-git-commit-history-clean",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22,"updatedDate":25},"4 Situationen, in denen sich eine aufgeräumte Git-Commit-Historie lohnt ","Erfahre, warum eine saubere Git-Commit-Historie die Nachvollziehbarkeit verbessert, Fehler behebt und die Codequalität steigert.",[18],"Kushal Pandya","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659457/Blog/Hero%20Images/keep-git-commit-history-clean.jpg","2018-06-07","Git-Commits sind einer der Eckpfeiler eines Git-Repositorys. Die Commit-Nachrichten sind wie ein Lebensprotokoll für das Repository. Während sich das Projekt/Repository im Laufe der Zeit entwickelt – sei es durch das Hinzufügen neuer Funktionen, das Beheben von Fehlern oder die Überarbeitung der Architektur – geben die Commit-Nachrichten Aufschluss darüber, was genau geändert wurde. Daher ist es entscheidend, dass diese Nachrichten die zugrunde liegende Änderung präzise und kurz wiedergeben. Die Commit-Historie kann leicht verfälscht werden. In diesem Artikel erfährst du, wie du sie korrigieren kannst!\n\n> **Nahezu 100 % Uptime: NVIDIA skaliert mit GitLab global – ohne Ausfallzeiten** Verteilte Teams bei NVIDIA profitieren mit GitLab Geo von schneller verfügbaren Repositories, häufigeren Upgrades ohne Ausfallzeiten und global-synchronen sowie -sicheren Projekten. Erfahre, wie GitLab Premium hilft, Stabilität, Transparenz und Effizienz zu verbessern. **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/nvidia/)**\n\n## Warum eine aussagekräftige Git-Commit-Historie wichtig ist\n\nWas bewirkt ein Git-Commit? Git-Commit-Nachrichten sind die Fingerabdrücke, die du auf dem Code hinterlässt, den du bearbeitest. Wenn du heute einen Code festlegst, ist es wichtig, eine klare und aussagekräftige Commit-Nachricht zu schreiben, damit du diese auch später noch nachvollziehen kannst. Indem Git-Commits kontextabhängig isoliert werden, ist ein Fehler, der durch einen einzelnen Commit verursacht wurde, schneller zu finden. Zudem ist es einfacher, den Commit rückgängig zu machen, der den Fehler verursacht hat.\n\nBei der Arbeit an großen Projekten haben wir oft mit vielen verschiedenen Komponenten, die aktualisiert, hinzugefügt oder entfernt werden, zu tun. In solchen Fällen kann es schwierig sein, die Commit-Nachrichten zu pflegen, insbesondere wenn sich die Entwicklung über Tage, Wochen oder sogar Monate erstreckt. Um die Wartung eines übersichtlichen Commit-Verlaufs zu erleichtern, findest du nachfolgend die vier häufigsten Situationen, mit denen ein Entwickler(innen) bei der Arbeit an einem Git-Repository konfrontiert werden kann.\n\n1. Situation 1: Ich muss den letzten Commit ändern\n2. Situation 2: Ich muss einen bestimmten Commit ändern\n3. Situation 3: Ich muss Commits hinzufügen, entfernen oder kombinieren\n4. Situation 4: Mein Commit-Verlauf macht keinen Sinn, ich muss nochmal von vorne anfangen\n\nBevor wir jedoch tiefer eintauchen, werfen wir einen kurzen Blick auf einen typischen Entwicklungsablauf in unserer hypothetischen Ruby-Anwendung.\n\n__Hinweis:__ In diesem Artikel wird vorausgesetzt, dass du mit den Grundlagen von Git vertraut bist und weißt, wie Branches funktionieren, wie nicht übertragene Änderungen eines Branches zum Staging-Bereich hinzugefügt und wie Änderungen übertragen werden. Wenn du unsicher bist, bietet unsere Dokumentation einen guten Ausgangspunkt.\n\n## Beispielprojekt: Neue Navigationsansicht\n\nNachfolgend siehst du ein Ruby-on-Rails-Projekt, in dem eine Navigationsansicht auf der Homepage hinzugefügt werden muss. Dazu müssen mehrere Dateien aktualisiert und hinzugefügt werden. Im Folgenden findest du eine schrittweise Aufschlüsselung des gesamten Ablaufs:\n\n- Du startest die Arbeit an einem Feature, indem du eine einzelne Datei aktualisierst. Zum Beispiel: `application_controller.rb`\n- Für dieses Feature musst du auch eine Ansicht aktualisieren: `index.html.haml`\n- Du hast einen Teilbereich hinzugefügt, der auf der Indexseite verwendet wird: `_navigation.html.haml`\n- Die Formatvorlagen für die Seite müssen ebenfalls aktualisiert werden, um den hinzugefügten Teil widerzuspiegeln: `styles.css.scss`\n- Das Feature ist nun mit den gewünschten Änderungen fertiggestellt. Jetzt musst du die Tests aktualisieren. Dazu gehören die folgenden Dateien:\n  - `application_controller_spec.rb`\n  - `navigation_spec.rb`\n- Die Tests wurden aktualisiert und laufen wie erwartet. Jetzt werden die Änderungen übertragen.\n\nDa alle Dateien zu verschiedenen Bereichen der Architektur gehören, werden die Änderungen isoliert voneinander übertragen. Dies gewährleistet, dass jede Übertragung einen spezifischen Kontext repräsentiert und in einer bestimmten Reihenfolge durchgeführt wird. Im Allgemeinen wird die Reihenfolge von Backend -> Frontend bevorzugt. Dies bedeutet, dass die meisten Backend-bezogenen Änderungen zuerst übertragen werden, gefolgt von der mittleren Schicht und dann von den Frontend-bezogenen Änderungen in den Git-Commits.\n\n1. `application_controller.rb` & `application_controller_spec.rb`: __Hinzufügen von Routen für die Navigation.__\n2. `_navigation.html.haml` & `navigation_spec.rb`: __Ansicht der Seitennavigation.__\n3. `index.html.haml`: __Navigation teilweise rendern.__\n4. `styles.css.scss`: __Stile für die Navigation hinzufügen.__\n\nNachdem die Änderungen übertragen wurden, wird eine Anfrage zur Zusammenführung mit dem Branch erstellt. Sobald du eine Merge-Anfrage geöffnet hast, wird sie in der Regel von deinem Peer überprüft, bevor die Änderungen im Master-Branch des Repositories zusammengeführt werden. Im Folgenden werden die verschiedenen Situationen beschrieben, die bei der Codeüberprüfung auftreten können.\n\n## Situation 1: Ändern des letzten Git-Commits\n\nIm Fall, dass der Prüfer die Datei `styles.css.scss` überprüft und eine Änderung vorgeschlagen hat, ist es recht einfach, die Änderung vorzunehmen, da die Stylesheet-Änderungen Teil des __letzten__ Commits in deinem Branch sind. So kannst du damit umgehen:\n\n- Führe die erforderlichen Änderungen an `styles.css.scss` direkt in deinem aktuellen Branch durch.\n- Sobald du mit den Änderungen fertig bist, füge sie zum Staging-Bereich hinzu, indem du `git add styles.css.scss` ausführst.\n- Nachdem die Änderungen bereitgestellt wurden, füge sie zu deinem letzten Commit hinzu, indem du `git commit --amend` ausführst.\n    - __Aufschlüsselung des Befehls__: Mit dem `git commit`-Befehl werden alle Änderungen, die sich im Staging-Bereich befinden, dem letzten Commit hinzugefügt.\n- Dadurch wird der von Git definierte Texteditor geöffnet, der die Commit-Nachricht __„Stile für die Navigation hinzufügen”__ enthält, die bereits beim vorherigen Commit festgelegt wurde.\n- Da nur die CSS-Deklaration aktualisiert wurde, muss die Commit-Nachricht nicht geändert werden. An dieser Stelle kannst du einfach speichern und den Texteditor, den Git für dich geöffnet hat, beenden. Deine Änderungen werden dann in den Commit übernommen.\n\nDa du ein bestehendes Git-Commit geändert hast, müssen diese Änderungen zwangsweise in dein Repository übertragen werden. Dazu nutzt du  `git push --force-with-lease \u003Cremote_name> \u003Cbranch_name>`. Dieser Befehl überschreibt das Commit `Add styles for navigation` im entfernten Repository mit dem aktualisierten Commit, das gerade im lokalen Repository vorgenommen wurde.\n\nWenn mehrere Personen an einem Branch arbeiten, kann ein erzwungener Push von Branches dazu führen, dass andere Benutzer Probleme bekommen, wenn sie versuchen, ihre Änderungen auf einen entfernten Branch zu pushen, in dem bereits neue Commits gepusht wurden. Daher sollte diese Funktion mit Bedacht eingesetzt werden. Weitere Informationen zu den Force-Push-Optionen von Git findest du [hier](https://git-scm.com/docs/git-push#git-push---no-force-with-lease \"hier\").\n\n## Situation 2: Ändern einer bestimmten Git-Commit-Änderung\n\nIn der vorherigen Situation war die Änderung des Git-Commits recht einfach, da nur der letzte Git-Commit geändert werden musste. Stell dir jedoch vor, ein Prüfer würde vorschlagen, etwas in `_navigation.html.haml` zu ändern. In diesem Fall handelt es sich um den zweiten Commit von oben, sodass die Änderung nicht so direkt ist wie in der ersten Situation. \n\nJeder Commit in einem Branch wird durch eine eindeutige SHA-1-Hash-Zeichenkette identifiziert. Diese dient als eine Art eindeutige ID, die einen Commit von einem anderen unterscheidet. Du kannst alle vorherigen Commits zusammen mit ihren SHA-1-Hashes in einem Branch anzeigen, indem du den Befehl `git log` ausführst. Das Ergebnis ist eine Liste von Commits, wobei die neuesten Commits ganz oben stehen.\n\n```text\ncommit aa0a35a867ed2094da60042062e8f3d6000e3952 (HEAD -> add-page-navigation)\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\nDate: Wed May 2 15:24:02 2018 +0530\n\n    Add styles for navigation\n\ncommit c22a3fa0c5cdc175f2b8232b9704079d27c619d0\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\nDate: Wed May 2 08:42:52 2018 +0000\n\n    Render navigation partial\n\ncommit 4155df1cdc7be01c98b0773497ff65c22ba1549f\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\nDate: Wed May 2 08:42:51 2018 +0000\n\n    Page Navigation View\n\ncommit 8d74af102941aa0b51e1a35b8ad731284e4b5a20\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\nDate: Wed May 2 08:12:20 2018 +0000\n\n    Add routes for navigation\n\n```\n\nAn dieser Stelle kommt der Befehl `git rebase` ins Spiel. Wenn wir einen bestimmten Commit mit `git rebase` bearbeiten wollen, müssen wir zunächst unseren Branch neu erstellen, indem wir HEAD bis zu dem Punkt vor dem Commit zurücksetzen, den wir bearbeiten wollen. In unserem Fall müssen wir den Commit ändern, der `Page Navigation View` lautet.\n\n![Ansicht Page Navigation View](https://about.gitlab.com/images/blogimages/keeping-git-commit-history-clean/GitRebase.png){: .shadow.center.medium}\n\n- Achte auf den Hash des Commits, der direkt vor dem Commit liegt, den wir ändern möchten. Kopiere den Hash und führe die folgenden Schritte aus:\n- Verschiebe den Branch auf einen Commit vor unserem Ziel-Commit; führe `git rebase -i8d74af102941aa0b51e1a35b8ad731284e4b5a20` aus.\n    - __Aufschlüsselung der Git-Befehle:__ Hier führen wir den Git-Befehl `rebase` im interaktiven Modus aus und geben einen SHA-1-Hash als Commit an, auf den `rebase` erfolgen soll.\n- Dieser Befehl führt den rebase-Befehl für Git im interaktiven Modus aus und öffnet den Texteditor, der alle Commits anzeigt, die auf den Commit folgen, auf den du den `rebase` durchführen möchtest. Der Texteditor sollte in etwa so aussehen:\n\n```text\npick 4155df1cdc7 Page Navigation View\npick c22a3fa0c5c Render navigation partial\npick aa0a35a867e Add styles for navigation\n\n# Rebase 8d74af10294..aa0a35a867e onto 8d74af10294 (3 commands)\n#\n# Commands:\n# p, pick = use commit\n# r, reword = use commit, but edit the commit message\n# e, edit = use commit, but stop for amending\n# s, squash = use commit, but meld into previous commit\n# f, fixup = like \"squash\", but discard this commit's log message\n# x, exec = run command (the rest of the line) using shell\n# d, drop = remove Git commit\n#\n# These lines can be re-ordered; they are executed from top to bottom.\n#\n# If you remove a line here THAT COMMIT WILL BE LOST.\n#\n# However, if you remove everything, the rebase will be aborted.\n#\n# Note that empty commits are commented out\n```\n\nBeachte, dass jedem Commit das Wort `pick` vorangestellt ist. Im Inhalt unten sind alle möglichen Schlüsselwörter aufgeführt, die du verwenden kannst. Da du eine Übertragung bearbeiten möchtest, musst du `pick 4155df1cdc7 Page Navigation View in edit 4155df1cdc7 Page Navigation View` ändern. Speichere die Änderungen und verlasse den Editor.\n\nDer Branch wird nun auf den Zeitpunkt vor der Commit-Übergabe zurückgesetzt, die die Datei `_navigation.html.haml` enthielt. Öffne die Datei und führe die gewünschten Änderungen gemäß dem Feedback der Überprüfung durch. Sobald du mit den Änderungen fertig bist, füge sie zum Staging-Bereich hinzu, indem du `git add _navigation.html.haml` ausführst.\n\nNachdem die Änderungen bereitgestellt wurden, ist es an der Zeit, den Branch HEAD wieder auf den ursprünglichen Commit zurückzusetzen, wobei auch die neu hinzugefügten Änderungen berücksichtigt werden. Führe `git rebase --continue` aus. Dadurch wird dein Standardeditor im Terminal geöffnet und zeigt die Commit-Nachricht an, die während des Rebase bearbeitet wurde; in diesem Fall Page `Navigation View`. Du kannst diese Nachricht ändern, wenn du möchtest – zunächst bleibt sie jedoch unverändert. Speichere und beende den Editor.\n\nJetzt zeigt Git alle Commits an, die auf den Commit folgten, den du gerade bearbeitet hast. Der Branch `HEAD` ist jetzt wieder auf dem ursprünglichen obersten Commit. Er enthält auch die neuen Änderungen, die du an einem der Commits vorgenommen hast.\n\nDa du erneut einen Commit geändert hast, der bereits im entfernten Repository vorhanden ist, musst du diesen Branch noch einmal mit `git push --force-with-lease \u003Cremote_name> \u003Cbranch_name>` pushen.\n\n## Situation 3: Hinzufügen, Entfernen oder Kombinieren von Git-Commits\n\nEs kommt häufig vor, dass mehrere Commits gemacht wurden, nur um etwas zu korrigieren, das bereits zuvor committed wurde. Jetzt möchtest du diese Commits so weit wie möglich reduzieren und mit den ursprünglichen Commits kombinieren.\n\nDazu musst du einfach den interaktiven Rebase wie in den anderen Szenarien starten.\n\n```text\npick 4155df1cdc7 Page Navigation View\npick c22a3fa0c5c Render navigation partial\npick aa0a35a867e Add styles for navigation\npick 62e858a322 Fix a typo\npick 5c25eb48c8 Ops another fix\npick 7f0718efe9 Fix 2\npick f0ffc19ef7 Argh Another fix!\n```\n\nNun stell dir vor, du möchtest all diese Korrekturen in `c22a3fa0c5c Render navigation partial` kombinieren. Dazu musst du nur Folgendes tun:\n\n1. Verschiebe die Korrekturen nach oben, sodass sie sich direkt unter der Commit-Übergabe befinden, die du am Ende behalten möchtest.\n2. Ändere `pick` auf `squash` oder `fixup` für jede der Korrekturen.\n\n*Hinweis:* `squash` behält die Commit-Nachrichten der Git-Fixes in der Beschreibung bei. `fixup` vergisst die Commit-Nachrichten der Fixes und behält das Original bei.\nDas Ergebnis sieht dann etwa so aus:\n\n```text\npick 4155df1cdc7 Page Navigation View\npick c22a3fa0c5c Render navigation partial\nfixup 62e858a322 Fix a typo\nfixup 5c25eb48c8 Ops another fix\nfixup 7f0718efe9 Fix 2\nfixup f0ffc19ef7 Argh Another fix!\npick aa0a35a867e Add styles for navigation\n```\n\nSpeichere die Änderungen, beende den Editor und schon bist du fertig! Dies ist der resultierende Verlauf:\n\n```text\npick 4155df1cdc7 Page Navigation View\npick 96373c0bcf Render navigation partial\npick aa0a35a867e Add styles for navigation\n```\n\nWie zuvor musst du jetzt nur noch `git push --force-with-lease \u003Cremote_name> \u003Cbranch_name>` ausführen, damit die Änderungen sichtbar sind.\n\nWenn du einen Git-Commit vollständig aus dem Branch entfernen möchtest, schreibe statt `squash` oder `fixup` einfach `drop` oder lösche diese Zeile.\n\n## Vermeiden von Konflikten bei Git-Commits\n\nUm Konflikte zu vermeiden, solltest du sicherstellen, dass die Commits, die du in der Zeitleiste nach vorne schiebst, nicht dieselben Dateien berühren, die von den Commits nach ihnen bearbeitet werden.\n\n```text\npick 4155df1cdc7 Page Navigation View\npick c22a3fa0c5c Render navigation partial\nfixup 62e858a322 Fix a typo                 # this changes styles.css\nfixup 5c25eb48c8 Ops another fix            # this changes image/logo.svg\nfixup 7f0718efe9 Fix 2                      # this changes styles.css\nfixup f0ffc19ef7 Argh Another fix!          # this changes styles.css\npick aa0a35a867e Add styles for navigation  # this changes index.html (no conflict)\n```\n\n## Extra-Tipp: Schnelle Git commit fixups\n\nWenn du genau weißt, welchen Commit du reparieren möchtest, musst du beim Commit keine Zeit damit verschwenden, dir gute temporäre Namen für \"Fix 1\", \"Fix 2\", ..., \"Fix 42\" auszudenken.\n\n### Step 1: `--fixup`\n\nNachdem du die Änderungen vorgenommen hast, um das zu reparieren, was repariert werden muss, übergibst du einfach alle Änderungen mit Git wie folgt:\n\n```shell\ngit commit --fixup c22a3fa0c5c\n```\n(Dies ist der Hash für den Commit `c22a3fa0c5c Render navigation partial`)\nDadurch wird diese Commit-Nachricht erzeugt: `fixup! Render navigation partial`.\n\n### Step 2: `--autosquash`\n\nEinfaches interaktives Rebase. Du kannst `git` die `fixups` automatisch an der richtigen Stelle platzieren lassen.\n\n`git rebase -i 4155df1cdc7 --autosquash`\n\nDer Verlauf wird folgendermaßen dargestellt:\n\n```text\npick 4155df1cdc7 Page Navigation View\npick c22a3fa0c5c Render navigation partial\nfixup 62e858a322 Fix a typo\nfixup 5c25eb48c8 Ops another fix\nfixup 7f0718efe9 Fix 2\nfixup f0ffc19ef7 Argh Another fix!\npick aa0a35a867e Add styles for navigation\n```\n\nDu kannst sie einfach überprüfen und fortsetzen. \n\nFalls du experimentierfreudig bist, besteht die Möglichkeit, ein nicht interaktives Rebase mit `git rebase --autosquash` durchzuführen. Dies sollte jedoch mit Vorsicht geschehen, da du keine Möglichkeit hast, die Squashs vor ihrer Anwendung zu überprüfen, was potenziell zu unerwarteten Ergebnissen führen kann.\n\n## Situation 4: Der Verlauf meiner Git-Commits ergibt keinen Sinn, ich möchte von vorn beginnen!\n\nWenn wir an einer umfangreichen Funktion arbeiten, ist es üblich, dass wir mehrere Korrekturen und Rückmeldungen vornehmen, die häufig übertragen werden. Anstatt den Branch ständig zu ändern, können wir das Aufräumen der Git-Commits bis zum Ende der Entwicklung aufschieben.\n\nIn solchen Fällen erweisen sich Patch-Dateien als äußerst praktisch. Bevor Git-basierte Dienste wie GitLab den Entwickler(inne)n zur Verfügung standen, waren Patch-Dateien die wichtigste Methode, um bei der Zusammenarbeit an großen Open-Source-Projekten Code per E-Mail auszutauschen.\n\nAngenommen, du hast einen solchen Branch (z. B. \"`add-page-navigation`\"), in dem es tonnenweise Commits gibt, die die zugrunde liegenden Änderungen nicht klar vermitteln, dann kannst du folgendermaßen eine Patch-Datei für alle Änderungen erstellen, die du in diesem Branch vorgenommen hast:\n\n- Um eine Patch-Datei zu erstellen, muss zunächst sichergestellt werden, dass der Branch alle Änderungen aus dem `master`-Branch enthält und keine Konflikte damit aufweist.\n- Um alle Änderungen vom Master-Branch in deinen `add-page-navigation`-Branch zu übernehmen, kannst du entweder `git rebase master` oder `git merge master` ausführen, während du im `add-page-navigation-Branch` ausgecheckt bist.\n- Nun erstellst du die Patch-Datei. Führe `git diff master add-page-navigation > ~/add_page_navigation.patch` aus.\n  - __Aufschlüsselung des Befehls:__ Hier verwenden wir die Diff-Funktion von Git und fordern einen Vergleich zwischen dem `master`-Branch und dem `add-page-navigation`-Branch an. Die Ausgabe wird über das \"`>`\"-Symbol in eine Datei namens `add_page_navigation.patch` in unserem Benutzerverzeichnis (typischerweise ~/ in Unix-basierten Betriebssystemen) umgeleitet.\n  - Du kannst einen beliebigen Pfad angeben, in dem die Datei gespeichert werden soll. Der Dateiname und die Erweiterung können beliebig gewählt werden.\n  - Sobald der Befehl ausgeführt wurde und keine Fehler angezeigt werden, wird die Patch-Datei erstellt.\n  - Checke jetzt den `master`-Branch aus; führe `git checkout master` aus.\n  - Du kannst den Branch `add-page-navigation` aus deinem lokalen Repository löschen, indem du `git branch -D add-page-navigation` ausführst. Denke daran, dass die Änderungen dieses Branchs bereits in einer erstellten Patch-Datei enthalten sind.\n  - Erstelle nun einen neuen Branch mit demselben Namen (während `master` ausgecheckt ist); führe `git checkout -b add-page-navigation` aus.\n  - Zu diesem Zeitpunkt ist dies ein neuer Branch, der noch keine der Änderungen enthält.\n  - Zum Schluss werden die Änderungen aus der Patch-Datei übernommen; `git apply ~/add_page_navigation.patch`.\n  - Hier werden alle Änderungen in einen Branch übernommen und erscheinen als \"uncommitted\", so, als ob du alle Änderungen vorgenommen hättest, aber keine der Änderungen tatsächlich in den Branch übernommen wurden.\n  - Jetzt kannst du einzelne Dateien oder nach Einflussbereich gruppierte Dateien in der gewünschten Reihenfolge mit prägnanten Commit-Nachrichten übertragen.\n\nWie in vorherigen Situationen wurde der gesamte Branch geändert, also ist es an der Zeit, einen Push zu erzwingen!\n\n## Gründe, deine Git-Commit-Historie aufzuräumen\n\nBasierend auf den beschriebenen Situationen, gibt es sechs wichtige Gründe, deine Git-Commit-Historie aufzuräumen:\n\n- __Bessere Nachvollziehbarkeit:__ Eine übersichtliche Commit-Historie erleichtert es Entwickler(innen)n, den [Verlauf des Codes](https://about.gitlab.com/de-de/solutions/source-code-management/ \"Verlauf des Codes\") zu verstehen und Änderungen nachzuvollziehen.\n- __Effiziente Fehlerbehebung:__ Durch klare Commit-Nachrichten und eine strukturierte Historie können Fehler schneller identifiziert und behoben werden.\n- __Verbesserte Zusammenarbeit:__ Ein aufgeräumter Commit-Verlauf erleichtert die Zusammenarbeit im Team, da Entwickler(innen)schnell den Kontext und den Zweck früherer Änderungen verstehen können.\n- __Effizientere Wartung:__ Weniger Zeit wird mit der Suche nach spezifischen Änderungen und deren Kontext verschwendet, was die Wartung des Codes effizienter macht.\n- __Verbesserte Codequalität:__ Eine saubere Commit-Historie fördert bewusstere Entscheidungen beim Committen und trägt so zur Verbesserung der Codequalität bei.\n- __Gesamtproduktivität steigern:__ Indem Entwickler(innen) weniger Zeit mit der Suche nach Informationen in der Commit-Historie verbringen, können sie sich besser auf die eigentliche Entwicklung konzentrieren und die Gesamtproduktivität des Teams steigern.\n\nWenn du dich mit den Tipps vertraut gemacht hast, kannst du in der [offiziellen Git-Dokumentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History \"offiziellen Git-Dokumentation\") mehr über fortgeschrittene Konzepte zu diesem Thema erfahren. Viel Spaß mit Git!\n",[23,24],"git","workflow","2024-10-10","yml",{},true,"/de-de/blog/keeping-git-commit-history-clean",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},"https://about.gitlab.com/blog/keeping-git-commit-history-clean","https://about.gitlab.com","article","de-de/blog/keeping-git-commit-history-clean",[23,24],"x30Loq0RPXfYOqmSPV4XFTJEatNzvUZjEaZgX8hw1Jw",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":368,"minimal":403,"duo":421,"pricingDeployment":431},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/de-de/","gitlab logo","header",{"text":45,"config":46},"Kostenlose Testversion anfordern",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Vertrieb kontaktieren",{"href":52,"dataGaName":53,"dataGaLocation":43},"/de-de/sales/","sales",{"text":55,"config":56},"Anmelden",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,183,188,289,349],{"text":61,"config":62,"cards":64},"Plattform",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":68,"config":69},"Erkunde unsere Plattform",{"href":70,"dataGaName":63,"dataGaLocation":43},"/de-de/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":75,"config":76},"Lerne GitLab Duo kennen",{"href":77,"dataGaName":78,"dataGaLocation":43},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":83,"config":84},"Mehr erfahren",{"href":85,"dataGaName":86,"dataGaLocation":43},"/de-de/why-gitlab/","why gitlab",{"text":88,"left":28,"config":89,"link":91,"lists":95,"footer":165},"Produkt",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"Alle Lösungen anzeigen",{"href":94,"dataGaName":90,"dataGaLocation":43},"/de-de/solutions/",[96,121,143],{"title":97,"description":98,"link":99,"items":104},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/de-de/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Quellcodeverwaltung",{"href":115,"dataGaLocation":43,"dataGaName":116},"/de-de/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Automatisierte Softwarebereitstellung",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"Schutz der Software-Lieferkette",{"href":137,"dataGaLocation":43,"dataGaName":138},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":140,"dataGaLocation":43},"/de-de/solutions/software-compliance/",{"title":144,"link":145,"items":150},"Bewertung",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":43},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"Sichtbarkeit und Bewertung",{"href":148,"dataGaLocation":43,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"Wertstrommanagement",{"href":158,"dataGaLocation":43,"dataGaName":159},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"Analysen und Einblicke",{"href":163,"dataGaLocation":43,"dataGaName":164},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLab für",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":43,"dataGaName":172},"/de-de/enterprise/","enterprise",{"text":174,"config":175},"Kleinunternehmen",{"href":176,"dataGaLocation":43,"dataGaName":177},"/de-de/small-business/","small business",{"text":179,"config":180},"den öffentlichen Sektor",{"href":181,"dataGaLocation":43,"dataGaName":182},"/de-de/solutions/public-sector/","public sector",{"text":184,"config":185},"Preise",{"href":186,"dataGaName":187,"dataGaLocation":43,"dataNavLevelOne":187},"/de-de/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":276},"Ressourcen",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"Alle Ressourcen anzeigen",{"href":195,"dataGaName":191,"dataGaLocation":43},"/de-de/resources/",[197,230,248],{"title":198,"items":199},"Erste Schritte",[200,205,210,215,220,225],{"text":201,"config":202},"Installieren",{"href":203,"dataGaName":204,"dataGaLocation":43},"/de-de/install/","install",{"text":206,"config":207},"Kurzanleitungen",{"href":208,"dataGaName":209,"dataGaLocation":43},"/de-de/get-started/","quick setup checklists",{"text":211,"config":212},"Lernen",{"href":213,"dataGaLocation":43,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"Produktdokumentation",{"href":218,"dataGaName":219,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"Best-Practice-Videos",{"href":223,"dataGaName":224,"dataGaLocation":43},"/de-de/getting-started-videos/","best practice videos",{"text":226,"config":227},"Integrationen",{"href":228,"dataGaName":229,"dataGaLocation":43},"/de-de/integrations/","integrations",{"title":231,"items":232},"Entdecken",[233,238,243],{"text":234,"config":235},"Kundenerfolge",{"href":236,"dataGaName":237,"dataGaLocation":43},"/de-de/customers/","customer success stories",{"text":239,"config":240},"Blog",{"href":241,"dataGaName":242,"dataGaLocation":43},"/de-de/blog/","blog",{"text":244,"config":245},"Remote",{"href":246,"dataGaName":247,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"Vernetzen",[251,256,261,266,271],{"text":252,"config":253},"GitLab-Services",{"href":254,"dataGaName":255,"dataGaLocation":43},"/de-de/services/","services",{"text":257,"config":258},"Community",{"href":259,"dataGaName":260,"dataGaLocation":43},"/community/","community",{"text":262,"config":263},"Forum",{"href":264,"dataGaName":265,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"Veranstaltungen",{"href":269,"dataGaName":270,"dataGaLocation":43},"/events/","events",{"text":272,"config":273},"Partner",{"href":274,"dataGaName":275,"dataGaLocation":43},"/de-de/partners/","partners",{"backgroundColor":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":281,"config":282},"the source promo card",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"Lies die News",{"href":287,"dataGaName":288,"dataGaLocation":43},"/de-de/the-source/","the source",{"text":290,"config":291,"lists":293},"Unternehmen",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"Über",{"href":299,"dataGaName":300,"dataGaLocation":43},"/de-de/company/","about",{"text":302,"config":303,"footerGa":306},"Karriere",{"href":304,"dataGaName":305,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":43},{"text":310,"config":311},"Geschäftsführung",{"href":312,"dataGaName":313,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":315,"config":316},"Team",{"href":317,"dataGaName":318,"dataGaLocation":43},"/company/team/","team",{"text":320,"config":321},"Handbuch",{"href":322,"dataGaName":323,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"Investor Relations",{"href":327,"dataGaName":328,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"Trust Center",{"href":332,"dataGaName":333,"dataGaLocation":43},"/de-de/security/","trust center",{"text":335,"config":336},"AI Transparency Center",{"href":337,"dataGaName":338,"dataGaLocation":43},"/de-de/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"Newsletter",{"href":342,"dataGaName":343,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"Presse",{"href":347,"dataGaName":348,"dataGaLocation":43},"/press/","press",{"text":350,"config":351,"lists":352},"Kontakt",{"dataNavLevelOne":292},[353],{"items":354},[355,358,363],{"text":50,"config":356},{"href":52,"dataGaName":357,"dataGaLocation":43},"talk to sales",{"text":359,"config":360},"Support-Portal",{"href":361,"dataGaName":362,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":364,"config":365},"Kundenportal",{"href":366,"dataGaName":367,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":369,"login":370,"suggestions":377},"Schließen",{"text":371,"link":372},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":373,"config":374},"gitlab.com",{"href":57,"dataGaName":375,"dataGaLocation":376},"search login","search",{"text":378,"default":379},"Vorschläge",[380,382,387,389,394,399],{"text":72,"config":381},{"href":77,"dataGaName":72,"dataGaLocation":376},{"text":383,"config":384},"Code Suggestions (KI)",{"href":385,"dataGaName":386,"dataGaLocation":376},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":388},{"href":108,"dataGaName":106,"dataGaLocation":376},{"text":390,"config":391},"GitLab auf AWS",{"href":392,"dataGaName":393,"dataGaLocation":376},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":395,"config":396},"GitLab auf Google Cloud",{"href":397,"dataGaName":398,"dataGaLocation":376},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":400,"config":401},"Warum GitLab?",{"href":85,"dataGaName":402,"dataGaLocation":376},"Why GitLab?",{"freeTrial":404,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":405,"config":406},"Kostenlos testen",{"href":407,"dataGaName":48,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLab-Symbol",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":198,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":422,"mobileIcon":427,"desktopIcon":429},{"text":423,"config":424},"Erfahre mehr über GitLab Duo",{"href":425,"dataGaName":426,"dataGaLocation":408},"/de-de/gitlab-duo/","gitlab duo",{"altText":410,"config":428},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":430},{"src":416,"dataGaName":413,"dataGaLocation":408},{"freeTrial":432,"mobileIcon":437,"desktopIcon":439},{"text":433,"config":434},"Zurück zur Preisübersicht",{"href":186,"dataGaName":435,"dataGaLocation":408,"icon":436},"back to pricing","GoBack",{"altText":410,"config":438},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":440},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":442,"button":443,"config":448},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":444,"config":445},"GitLab Transcend jetzt ansehen",{"href":446,"dataGaName":447,"dataGaLocation":43},"/de-de/events/transcend/virtual/","transcend event",{"layout":449,"icon":450},"release","AiStar",{"data":452},{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":455,"config":456},"Quelltext der Seite anzeigen",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"Diese Seite bearbeiten",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"Beteilige dich",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,554,581,615],{"title":61,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOps-Plattform",{"href":70,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":184,"links":484},[485,489,494],{"text":486,"config":487},"Tarife anzeigen",{"href":186,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Vorteile von Premium",{"href":492,"dataGaName":493,"dataGaLocation":459},"/de-de/pricing/premium/","why premium",{"text":495,"config":496},"Vorteile von Ultimate",{"href":497,"dataGaName":498,"dataGaLocation":459},"/de-de/pricing/ultimate/","why ultimate",{"title":500,"links":501},"Lösungen",[502,507,510,512,517,522,526,529,532,537,539,541,544,549],{"text":503,"config":504},"Digitale Transformation",{"href":505,"dataGaName":506,"dataGaLocation":459},"/de-de/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"Sicherheit und Compliance",{"href":126,"dataGaName":133,"dataGaLocation":459},{"text":118,"config":511},{"href":102,"dataGaName":103,"dataGaLocation":459},{"text":513,"config":514},"Agile Entwicklung",{"href":515,"dataGaName":516,"dataGaLocation":459},"/de-de/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"Cloud-Transformation",{"href":520,"dataGaName":521,"dataGaLocation":459},"/de-de/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":115,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":106,"config":527},{"href":108,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":156,"config":530},{"href":158,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/de-de/solutions/gitops/","gitops",{"text":169,"config":538},{"href":171,"dataGaName":172,"dataGaLocation":459},{"text":174,"config":540},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":542,"config":543},"Öffentlicher Sektor",{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":545,"config":546},"Bildungswesen",{"href":547,"dataGaName":548,"dataGaLocation":459},"/de-de/solutions/education/","education",{"text":550,"config":551},"Finanzdienstleistungen",{"href":552,"dataGaName":553,"dataGaLocation":459},"/de-de/solutions/finance/","financial services",{"title":189,"links":555},[556,558,560,562,565,567,569,571,573,575,577,579],{"text":201,"config":557},{"href":203,"dataGaName":204,"dataGaLocation":459},{"text":206,"config":559},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":561},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":563},{"href":218,"dataGaName":564,"dataGaLocation":459},"docs",{"text":239,"config":566},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":234,"config":568},{"href":236,"dataGaName":237,"dataGaLocation":459},{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":459},{"text":252,"config":572},{"href":254,"dataGaName":255,"dataGaLocation":459},{"text":257,"config":574},{"href":259,"dataGaName":260,"dataGaLocation":459},{"text":262,"config":576},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":267,"config":578},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":580},{"href":274,"dataGaName":275,"dataGaLocation":459},{"title":290,"links":582},[583,585,587,589,591,593,595,599,604,606,608,610],{"text":297,"config":584},{"href":299,"dataGaName":292,"dataGaLocation":459},{"text":302,"config":586},{"href":304,"dataGaName":305,"dataGaLocation":459},{"text":310,"config":588},{"href":312,"dataGaName":313,"dataGaLocation":459},{"text":315,"config":590},{"href":317,"dataGaName":318,"dataGaLocation":459},{"text":320,"config":592},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":594},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":596,"config":597},"Sustainability",{"href":598,"dataGaName":596,"dataGaLocation":459},"/sustainability/",{"text":600,"config":601},"Vielfalt, Inklusion und Zugehörigkeit",{"href":602,"dataGaName":603,"dataGaLocation":459},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":605},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":340,"config":607},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":345,"config":609},{"href":347,"dataGaName":348,"dataGaLocation":459},{"text":611,"config":612},"Transparenzerklärung zu moderner Sklaverei",{"href":613,"dataGaName":614,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":616,"links":617},"Nimm Kontakt auf",[618,621,626,628,633,638,643],{"text":619,"config":620},"Sprich mit einem Experten/einer Expertin",{"href":52,"dataGaName":53,"dataGaLocation":459},{"text":622,"config":623},"Support",{"href":624,"dataGaName":625,"dataGaLocation":459},"/support/","get help",{"text":364,"config":627},{"href":366,"dataGaName":367,"dataGaLocation":459},{"text":629,"config":630},"Status",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"Nutzungsbedingungen",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"Datenschutzerklärung",{"href":641,"dataGaName":642,"dataGaLocation":459},"/de-de/privacy/","privacy statement",{"text":644,"config":645},"Cookie-Einstellungen",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":28},[657],{"id":658,"title":18,"body":8,"config":659,"content":661,"description":8,"extension":26,"meta":665,"navigation":28,"path":666,"seo":667,"stem":668,"__hash__":669},"blogAuthors/en-us/blog/authors/kushal-pandya.yml",{"template":660},"BlogAuthor",{"name":18,"config":662},{"headshot":663,"ctfId":664},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659454/Blog/Author%20Headshots/kushalpandya-headshot.png","kushalpandya",{},"/en-us/blog/authors/kushal-pandya",{},"en-us/blog/authors/kushal-pandya","5usuoILmHesSGmSO_7xZlme00WJWoDZxY1ccCfTzrwY",[671,685,699],{"content":672,"config":683},{"category":9,"tags":673,"body":675,"date":676,"heroImage":677,"authors":678,"title":681,"description":682},[674,23,106],"tutorial","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/ee/user/permissions.html) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[679,680],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":28,"template":13,"slug":684},"migration-from-azure-devops-to-gitlab",{"content":686,"config":697},{"heroImage":687,"title":688,"description":689,"authors":690,"date":692,"category":9,"tags":693,"body":696},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","Wie wir die größte GitLab-Instanz 12-mal täglich bereitstellen","Systematische Deployment-Pipeline mit mehrstufigen Rollouts, Canary-Strategie (5% Traffic) und Datenbank-Migrationen für Millionen Entwickler(innen) weltweit.",[691],"John Skarbek","2025-12-01",[694,695],"product","inside GitLab","GitLab führt täglich bis zu 12 Code-Bereitstellungen auf der weltweit größten GitLab-Instanz – GitLab.com – ohne Ausfallzeiten durch. Diese Bereitstellungen nutzen GitLabs eigene CI/CD-Plattform und betreffen Millionen Entwickler(innen) weltweit. Die hohe Bereitstellungsfrequenz dient als primäres Qualitätstor und Belastungstest. Organisationen, die auf GitLab für ihre DevOps-Workflows setzen, nutzen eine auf der eigenen Infrastruktur im Enterprise-Maßstab bewährte Plattform.\n\nIn regulierten Branchen wie dem Finanzwesen und der Automobilproduktion sind Zero-Downtime-Bereitstellungen keine Option, sondern Voraussetzung. Die NIS2-Richtlinie fordert in Artikel 21 systematische Risikoanalyse und Business-Continuity-Management – genau das, was GitLab.coms progressive Rollout-Strategie in der Praxis demonstriert. Durch mehrstufige Validierung mit isoliertem Canary-Traffic (5% aller Anfragen) werden potenzielle Probleme erkannt, bevor Millionen Nutzer(innen) betroffen sind.\n\n## Die Herausforderung: Frequenz trifft Skalierung\n\n**Für GitLab:** Bereitstellungsfrequenz ist geschäftskritisch. Schnelle Deployment-Zyklen ermöglichen Reaktion auf Kundenfeedback innerhalb von Stunden, sofortige Security-Patches und Validierung neuer Features in Production vor Skalierung.\n\n**Für Kund(inn)en:** Jede Bereitstellung auf GitLab.com validiert die Deployment-Praktiken, die GitLab seinen Nutzer(inne)n empfiehlt. Features werden auf der weltweit größten GitLab-Instanz getestet, bevor sie Kundenumgebungen erreichen. Dies liefert:\n\n* Neueste Features sofort verfügbar (Stunden statt Wochen)\n* Bewährte Zuverlässigkeit im Maßstab\n* Zero-Downtime-Bereitstellungen garantieren durchgängigen Zugriff\n* Dokumentation basiert auf tatsächlichen Production-Praktiken\n\n## Code-to-Production-Architektur\n\nDie Deployment-Pipeline durchläuft strukturierte Phasen, wobei jede Phase als Checkpoint auf dem Weg zur Production-Bereitstellung fungiert:\n\n```mermaid\n    graph TD\n        A[Code Proposed] --> B[Merge Request Created]\n        B --> C[Pipeline Triggered]\n        C --> D[Build & Test]\n        D --> E{Spec/Integration/QA Tests Pass?}\n        E -->|No| F[Feedback Loop]\n        F --> B\n        E -->|Yes| G[Merge to default branch]\n        G -->|Periodically| H[Auto-Deploy Branch]\n\n        subgraph \"Deployment Pipeline\"\n            H --> I[Package Creation]\n            I --> K[Canary Environment]\n            K --> L[QA Validation]\n            L --> M[Main Environment]\n\n        end\n```\n\n## Progressive Rollout-Strategie\n\n### Build und Paket-Erstellung\n\nGitLab erstellt sowohl Omnibus-Pakete als auch Cloud Native GitLab (CNG) Images. Omnibus-Pakete werden auf der Gitaly-Flotte bereitgestellt (Git-Storage-Layer), während CNG-Images alle anderen Komponenten als containerisierte Workloads ausführen. Eine geplante Pipeline sucht regelmäßig nach dem jüngsten Commit mit erfolgreicher Pipeline und erstellt daraus einen Auto-Deploy-Branch.\n\n```mermaid\n    graph LR\n        A[Create branch] --> B[Build]\n        B --> C[Choose Built package]\n        C --> D[Start Deploy Pipeline]\n```\n\n### Canary-Strategie und mehrstufige Validierung\n\nGitLabs QA-Prozess arbeitet Hand in Hand mit der Canary-Strategie durch umgebungsbasierte Validierung. [Etwa 5% des gesamten Traffics durchlaufen die Canary-Stage](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Dieser Ansatz erhöht die Komplexität von Datenbankmigrationen, gewährleistet aber nahtlose Bereitstellung eines zuverlässigen Produkts.\n\n**Progressive Rollout-Phasen:**\n\n1. **Staging Canary:** Initiale Validierungsumgebung\n2. **Production Canary:** Limitierter Production-Traffic\n3. **Staging Main:** Vollständige Staging-Umgebung\n4. **Production Main:** Vollständiger Production-Rollout\n\n```mermaid\n    graph TD\n        C[Staging Canary Deploy]\n        C --> D[QA Smoke Main Stage Tests]\n        C --> E[QA Smoke Canary Stage Tests]\n        D --> F\n        E --> F{Tests Pass?}\n        F -->|Yes| G[Production Canary Deploy]\n        G --> S[QA Smoke Main Stage Tests]\n        G --> T[QA Smoke Canary Stage Tests]\n        F -->|No| H[Issue Creation]\n        H --> K[Fix & Backport]\n        K --> C\n\n        S --> M[Canary Traffic Monitoring]\n        T --> M[Canary Traffic Monitoring baking period]\n        M --> U[Production Safety Checks]\n        U --> N[Staging Main]\n        N --> V[Production Main]\n```\n\nQA-Validierung erfolgt an mehreren Checkpoints: nach jeder Canary-Bereitstellung und nach Post-Deploy-Migrationen. Weitere Details zur [GitLab-Teststrategie](https://handbook.gitlab.com/handbook/engineering/testing/) finden sich im Handbook.\n\n## Deployment-Pipeline-Stages\n\nGitLab.com repräsentiert reale Deployment-Komplexität im Maßstab. Als größte bekannte GitLab-Instanz nutzen Bereitstellungen denselben offiziellen GitLab Helm Chart und dasselbe Linux-Paket wie Kund(inn)en. Mehr zur [GitLab.com-Architektur](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) im Handbook.\n\n**Dogfooding im Maßstab:** GitLab nutzt dieselben Verfahren, die für [Zero-Downtime-Upgrades](https://docs.gitlab.com/update/zero_downtime/) dokumentiert sind. Was bei GitLab nicht reibungslos funktioniert, wird Kund(inn)en nicht empfohlen.\n\nFolgende Stages laufen für alle Environment- und Stage-Upgrades:\n\n```mermaid\n    graph LR\n        a[prep] --> c[Regular Migrations - Canary stage only]\n        a --> f[Assets - Canary stage only]\n        c --> d[Gitaly]\n        d --> k8s\n\n        subgraph subGraph0[\"VM workloads\"]\n          d[\"Gitaly\"]\n        end\n\n        subgraph subGraph1[\"Kubernetes workloads\"]\n          k8s[\"k8s\"]\n        end\n\n        subgraph fleet[\"fleet\"]\n          subGraph0\n          subGraph1\n        end\n```\n\n**Stage-Details:**\n\n* **Prep:** Validiert Deployment-Bereitschaft und führt Pre-Deployment-Checks durch\n* **Migrations:** Führt reguläre Datenbankmigrationen aus (nur Canary-Stage)\n* **Assets:** Lädt statische Assets in GCS-Bucket hoch (nur Canary-Stage)\n* **Gitaly:** Aktualisiert Gitaly-VM-Storage-Layer via Omnibus-Paket\n* **Kubernetes:** Deployed containerisierte GitLab-Komponenten via Helm Chart\n\n### Multi-Version-Kompatibilität: Die versteckte Herausforderung\n\nWährend der Bereitstellung existiert eine Zeitspanne, in der das Datenbankschema dem Code voraus ist, den die Main-Stage kennt. Dies geschieht, weil die Canary-Stage bereits neuen Code deployed und reguläre Datenbankmigrationen ausführt, während die Main-Stage noch die vorherige Code-Version ausführt.\n\n**Beispiel:** Bei Hinzufügen eines neuen `merge_readiness`-Felds zu Merge Requests laufen manche Server mit Code, der dieses Feld erwartet, während andere nichts davon wissen. Schlechte Handhabung würde GitLab.com für Millionen Nutzer(innen) unterbrechen. Gute Handhabung bleibt unbemerkt.\n\nMit wenigen Ausnahmen läuft die Mehrheit der Services für eine gewisse Zeit in leicht neuerer Version in Canary. Diese Szenarien sind transiente Zustände, können aber mehrere Stunden oder Tage in Live-Production-Umgebung persistieren. Daher müssen sie mit derselben Sorgfalt wie permanente Zustände behandelt werden.\n\n## Datenbank-Operationen\n\nDatenbankmigrationen stellen eine besondere Herausforderung im Canary-Deployment-Modell dar. Schemaänderungen müssen neue Features unterstützen und gleichzeitig Rollback-Fähigkeit bewahren:\n\n* **Regular Migrations:** Laufen während Canary-Stage, rückwärtskompatibel, nur reversible Änderungen\n* **Post-Deploy-Migrations:** \"Point of no Return\"-Migrationen, die erst nach mehreren erfolgreichen Bereitstellungen laufen\n\n```mermaid\n    graph LR\n        A[Regular Migrations] --> B[Canary Stage Deploy]\n        B --> C[Main Stage Deploy]\n        C --> D[Post Deploy Migrations]\n```\n\nPost-Deploy-Migrationen enthalten oft Änderungen, die nicht einfach rückgängig gemacht werden können – Datentransformationen, Column-Drops oder strukturelle Änderungen, die ältere Code-Versionen unterbrechen würden. Durch Ausführung nach Erlangung von Vertrauen durch mehrere erfolgreiche Bereitstellungen wird sichergestellt:\n\n1. Neuer Code ist stabil, Rollback unwahrscheinlich\n2. Performance-Charakteristiken in Production verstanden\n3. Edge Cases erkannt und adressiert\n4. Blast Radius minimiert, falls etwas schiefgeht\n\nDieser Ansatz bietet optimale Balance: schnelle Feature-Bereitstellung durch Canary-Releases bei gleichzeitiger Rollback-Fähigkeit bis Vertrauen in Deployment-Stabilität besteht.\n\n**Expand-Migrate-Contract-Pattern:** Datenbank-, Frontend- und Anwendungskompatibilitäts-Änderungen folgen einem sorgfältig orchestrierten dreiphasigen Ansatz:\n\n1. **Expand:** Neue Strukturen hinzufügen, alte funktional belassen\n2. **Migrate:** Neuen Application-Code deployen, der neue Strukturen nutzt\n3. **Contract:** Alte Strukturen in Post-Deploy-Migrationen entfernen\n\n**Beispiel für `merge_readiness`-Column:**\n\n1. **Expand:** Neue Column mit Default-Value hinzufügen; bestehender Code ignoriert sie\n2. **Migrate:** Code deployen, der neue Column liest und schreibt, alten Ansatz weiter unterstützt\n3. **Contract:** Nach mehreren erfolgreichen Bereitstellungen alte Column in Post-Deploy-Migration entfernen\n\nAlle Datenbank-Operationen, Application-Code und Frontend-Code unterliegen Guidelines, dokumentiert in der [Multi-Version-Compatibility-Dokumentation](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n## Ergebnisse und Auswirkungen\n\n**Für GitLab:**\n\n* Bis zu 12 Bereitstellungen täglich auf GitLab.com\n* Zero-Downtime-Bereitstellungen für Millionen Entwickler(innen)\n* Security-Patches erreichen Production innerhalb von Stunden\n* Neue Features in Production im Maßstab validiert vor General Availability\n\n**Für Kunden:**\n\n* Bewährte Deployment-Patterns für eigene Anwendungen\n* Features auf weltweit größter GitLab-Instanz getestet vor Erreichen der Kundenumgebung\n* Dokumentation reflektiert tatsächliche Production-Praktiken\n* Vertrauen, dass GitLabs empfohlene Upgrade-Prozeduren in jedem Maßstab funktionieren\n\n## Erkenntnisse für Engineering-Teams\n\nDie hier beschriebenen Muster – von Expand-Migrate-Contract für Datenbankmigrationen bis zur Multi-Version-Kompatibilität – sind auf kleinere Deployments übertragbar. Nicht jede Organisation benötigt 12 Bereitstellungen täglich, aber die systematische Herangehensweise an Rollback-Fähigkeit und Validierungspunkte gilt unabhängig von der Skalierung.\n\nGitLabs Deployment-Pipeline repräsentiert ein ausgereiftes System, das Deployment-Geschwindigkeit mit operationaler Zuverlässigkeit ausbalanciert. Das progressive Deployment-Modell, umfassende Testing-Integration und robuste Rollback-Fähigkeiten bieten Grundlage für zuverlässige Software-Auslieferung im Maßstab.\n\n**Zentrale Überlegungen für Engineering-Teams:**\n\n* **Automatisiertes Testing:** Umfassende Test-Coverage durch Deployment-Pipeline\n* **Progressive Rollouts:** Gestufte Bereitstellungen zur Risikominimierung und schnellen Wiederherstellung\n* **Monitoring-Integration:** Umfassende Observability über alle Deployment-Stages\n* **Incident Response:** Schnelle Erkennungs- und Lösungsfähigkeiten für Deployment-Probleme\n\nGitLabs Architektur demonstriert, wie moderne CI/CD-Systeme Komplexität großskaliger Bereitstellungen managen und gleichzeitig Geschwindigkeit für wettbewerbsfähige Software-Entwicklung bewahren.\n\n## Vollständige technische Dokumentation\n\nDieser Artikel beschreibt die Deployment-Patterns und systematische Herangehensweise für GitLab.com. Für vollständige Implementierungsdetails, spezifische Konfigurationsbeispiele und tiefergehende technische Architekturbeschreibungen siehe die [englische Originalversion](https://about.gitlab.com/blog/continuously-deploying-the-largest-gitlab-instance/).\n\nWeitere Dokumentation zu Auto-Deploy und Verfahren:\n\n* [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n* [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n* [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)\n\n## Weitere Ressourcen\n\n* [How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n* [How we supercharged GitLab CI statuses with WebSockets](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n* [How we reduced MR review time with Value Stream Management](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)",{"featured":28,"template":13,"slug":698},"continuously-deploying-the-largest-gitlab-instance",{"content":700,"config":712},{"title":701,"description":702,"authors":703,"heroImage":705,"date":706,"category":9,"tags":707,"body":711},"MR-Review-Zeit mit Value Stream Management reduzieren","GitLab Engineering nutzt VSM zur Identifikation von Engpässen im MR-Review-Prozess. Systematische Analyse mit Custom Stages.",[704],"Haim Snir","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097876/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097875817.png","2025-10-30",[694,708,709,24,710],"features","DevSecOps platform","solutions architecture","Das GitLab Engineering-Team nutzt die eigenen Produkte intern – eine Praxis, die im Englischen als \"Dogfooding\" bezeichnet wird. Diese Selbstnutzung hat zu Verbesserungen bei der Beschleunigung der Software-Delivery-Zyklen für Kunden geführt. Dieser Artikel beleuchtet einen spezifischen Anwendungsfall, bei dem [GitLab Value Stream Management (VSM)](https://about.gitlab.com/solutions/value-stream-management/) Verbesserungen für unser Engineering-Team ermöglicht hat. Es wird gezeigt, wie VSM dabei half, zwei zentrale Herausforderungen anzugehen: die Messung des Wegs von der Idee bis zur Fertigstellung eines Merge Requests und die Optimierung der Deployment-Workflows.\n\nValue Stream Management ist in der deutschen Industrie als Wertstromanalyse etabliert – insbesondere in der Fertigung und Automobilbranche wird diese Lean-Methode zur Identifikation von Verschwendung eingesetzt. GitLabs VSM-Funktionen übertragen diesen systematischen Ansatz auf Software-Entwicklungsprozesse und ermöglichen die Unterscheidung zwischen wertschöpfenden und nicht-wertschöpfenden Aktivitäten im Entwicklungsworkflow.\n\n## Die Herausforderung: Engpässe in MR-Reviews identifizieren\n\nTrotz gut definierter Workflows stellte ein Team fest, dass Merge Requests länger als erwartet brauchten, um geprüft und gemerged zu werden. Die Herausforderung bestand nicht nur in den Verzögerungen selbst, sondern darin zu verstehen, wo im Review-Prozess diese Verzögerungen auftraten und warum.\n\nDas Ziel des Teams war klar:\n\n- Identifizieren, wo Zeit vom initialen Konzept bis zum finalen Merge eines MR verbracht wurde\n- Spezifische Engpässe im Review-Prozess lokalisieren\n- Verstehen, wie MR-Größe, Komplexität oder Dokumentationsqualität die Review-Zeit beeinflussen\n\n## Der Ansatz: MR-Review-Zeit in GitLab Value Stream Analytics messen\n\nValue Stream Analytics (VSA) ermöglicht es Organisationen, ihren gesamten Workflow von der Idee bis zur Auslieferung abzubilden und dabei zwischen wertschöpfenden Aktivitäten (VA) und nicht-wertschöpfenden Aktivitäten (NVA) im Prozessfluss zu unterscheiden. Durch die Berechnung des Verhältnisses von wertschöpfender Zeit zur gesamten Lead Time kann das Team verschwenderische Aktivitäten identifizieren, die zu Verzögerungen bei MR-Reviews führen.\n\nUm die notwendigen Metriken zu erhalten, passte das Team GitLab VSA an, um bessere Sichtbarkeit in den MR-Review-Prozess zu erhalten.\n\n### 1. Custom Stage für MR-Review einrichten\n\nDas Team fügte eine [neue Custom Stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) in VSA mit dem Namen **Review Time to Merge** hinzu, um spezifisch die Zeit vom ersten Zuweisen eines Reviewers bis zum Merge des MR zu tracken.\n\n- Start-Event: MR first reviewer assigned\n- End-Event: MR merged\n\nDurch die Definition dieser Stage begann VSA, die Dauer des MR-Review-Prozesses zu messen und lieferte präzise Daten darüber, wo Zeit verbracht wurde.\n\n![Defining stage of VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097883929.png)\n\n### 2. Total Time Chart für Klarheit nutzen\n\nMit der Custom Stage eingerichtet, nutzte das Team das [**Total Time Chart** auf der VSA Overview-Seite](https://about.gitlab.com/blog/value-stream-total-time-chart/) (**Analyze > Value Stream**), um zu visualisieren, wie viel Zeit während der neuen MR-Review-Stage verbracht wurde. Durch den Vergleich der Werte, die durch jeden Bereich im Chart dargestellt wurden, konnte das Team schnell identifizieren, wie diese Stage zur gesamten Software-Delivery-Lifecycle-Zeit (SDLC) beitrug.\n\n![total time chart for VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097883930.png)\n\n### 3. Für tiefere Erkenntnisse detailliert analysieren\n\nUm spezifische Verzögerungen zu untersuchen, nutzte das Team die **Stage Navigation Bar**, um tiefer in die MR-Review-Stage einzutauchen. Diese Ansicht ermöglichte:\n\n- MRs nach Review-Zeit sortieren: Die Stage-Tabelle zeigte alle zugehörigen MRs sortiert nach Review-Dauer, sodass langsame MRs leicht erkennbar waren\n- Individuelle MRs analysieren: Für jeden MR konnte das Team Faktoren wie Verzögerungen bei der Reviewer-Zuweisung, mehrere Feedback-Runden, Leerlaufzeit nach Approval und MR-Größe/Komplexität untersuchen\n\n## Das Ergebnis: Umsetzbare Erkenntnisse und Verbesserungen\n\nDurch die Anpassung von VSA zur Verfolgung der [MR-Review-Zeit](https://docs.gitlab.com/user/project/merge_requests/reviews/) deckte das Team mehrere zentrale Erkenntnisse auf:\n\n- **Verzögerungen bei Reviewer-Zuweisung:** Einige MRs erfuhren Verzögerungen, weil Reviewer spät zugewiesen wurden oder Reviewer zu viele MRs in ihrer Queue hatten\n- **Langsame Review-Start-Zeiten:** Selbst nach Zuweisung lagen bestimmte MRs untätig, bevor Reviews begannen – oft aufgrund von Kontextwechseln oder konkurrierenden Prioritäten\n- **Mehrere Feedback-Schleifen:** Größere MRs erforderten oft mehrere Feedback-Runden, was die Review-Zeit erheblich verlängerte\n- **Leerlaufzeit nach Approval:** Einige MRs wurden approved, aber nicht zeitnah gemerged – oft aufgrund von Deployment-Koordinationsproblemen\n\nFür den Engineering Manager im Team erwies sich VSA als wertvoll für die Verwaltung des Team-Workflows: \"Ich habe VSA genutzt, um zu begründen, wo wir Zeit bei der MR-Fertigstellung verbrachten. Wir haben VSA auf unsere Bedürfnisse angepasst, und es war sehr hilfreich für unsere Untersuchungen nach Verbesserungsmöglichkeiten.\"\n\nAus dieser Dogfooding-Erfahrung entwickeln wir nun eine wichtige Erweiterung zur Verbesserung der Sichtbarkeit in den Review-Prozess. Wir fügen ein neues Event zu VSA hinzu – [Merge request last approved at](https://gitlab.com/gitlab-org/gitlab/-/issues/503754) – das eine Stage erzeugt, die MR-Review-Schritte noch granularer aufschlüsselt.\n\n## Die Kraft datengestützter Entscheidungen\n\nDurch die Nutzung von GitLabs VSA haben wir nicht nur Engpässe identifiziert – wir erhielten umsetzbare Erkenntnisse, die zu Verbesserungen bei der MR-Review-Zeit und der allgemeinen Entwickler-Produktivität führten. Wir optimierten Merge-Request-Review-Zyklen und erhöhten den Entwickler-Durchsatz, was unser Commitment zu kontinuierlicher Verbesserung durch Messung bestätigt.\n\n> Möchtest du erfahren, wie VSA deinem Team helfen kann? [Starte eine kostenlose GitLab Ultimate-Testversion](https://about.gitlab.com/free-trial/), passe deine Value Streams an und sieh, wie du Verbesserungen im gesamten SDLC für deine Teams erreichen kannst. [Teile dann dein Feedback und deine Erfahrungen in diesem Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/520962).\n\n## Weiterführende Informationen\n\n- [Optimize value stream efficiency to do more with less, faster](https://about.gitlab.com/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/)\n- [New Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Value stream analytics documentation](https://docs.gitlab.com/user/group/value_stream_analytics/)\n- [Value stream management: Total Time Chart simplifies top-down optimization flow](https://about.gitlab.com/blog/value-stream-total-time-chart/)\n",{"slug":713,"featured":12,"template":13},"how-we-reduced-mr-review-time-with-value-stream-management",{"promotions":715},[716,730,742],{"id":717,"categories":718,"header":720,"text":721,"button":722,"image":727},"ai-modernization",[719],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":723,"config":724},"Get your AI maturity score",{"href":725,"dataGaName":726,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":728},{"src":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":731,"categories":732,"header":734,"text":721,"button":735,"image":739},"devops-modernization",[694,733],"devsecops","Are you just managing tools or shipping innovation?",{"text":736,"config":737},"Get your DevOps maturity score",{"href":738,"dataGaName":726,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":740},{"src":741},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":743,"categories":744,"header":746,"text":721,"button":747,"image":751},"security-modernization",[745],"security","Are you trading speed for security?",{"text":748,"config":749},"Get your security maturity score",{"href":750,"dataGaName":726,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":752},{"src":753},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":755,"blurb":756,"button":757,"secondaryButton":762},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":758,"config":759},"Kostenlosen Test starten",{"href":760,"dataGaName":48,"dataGaLocation":761},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":50,"config":763},{"href":52,"dataGaName":53,"dataGaLocation":761},1772652043753]