[{"data":1,"prerenderedAt":760},["ShallowReactive",2],{"/de-de/blog/what-is-open-source-software":3,"navigation-de-de":36,"banner-de-de":440,"footer-de-de":450,"blog-post-authors-de-de-GitLab Germany Team":654,"blog-related-posts-de-de-what-is-open-source-software":669,"assessment-promotions-de-de":709,"next-steps-de-de":750},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":12,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":33,"tagSlugs":34,"__hash__":35},"blogPosts/de-de/blog/what-is-open-source-software.yml","What Is Open Source Software",[7],"gitlab-germany-team",null,"open-source",{"slug":11,"featured":12,"template":13},"what-is-open-source-software",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Open Source & OSS: Was es ist, was es dir bringt","Der ultimative Open-Source-Software-Guide: OSS Definition, Beispiele, Projekte, Empfehlungen und Hilfe bei der Umsetzung.",[18],"GitLab Germany Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749690483/Blog/Hero%20Images/blog-image-template-1800x945__11_.png","2025-04-02","# Open Source & OSS: Was es ist und was es dir bringt\n\nUm Open-Source-Software (OSS) ranken sich viele Missverständnisse und scheinbare Widersprüche.\n\nEinerseits stieg die Zahl der Unternehmen in Deutschland, die OSS nutzen, alleine zwischen 2019 und 2023 um knapp 15 %: über drei Viertel aller Betriebe nutzen heute zumindest teilweise Open-Source-Software.  Und sogar die weltweit führende Unternehmensberatung PWC urteilte angesichts dieser Entwicklung: „Open-Source-Software ist mittlerweile der Stand der Technik in der deutschen Wirtschaft.”\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\nAndererseits aber fällt vielen Betrieben die praktische Einbindung von OSS in ihre IT-Struktur und Prozesse schwer. Wie auch Computer Weekly in einem ausführlichen Spezial zum Thema klarstellte: „Der Einsatz von OSS stellt insbesondere mittelständische Unternehmen häufig vor erhebliche Herausforderungen. Ohne [...] Initialinvestition wird jedes Open-Source-Projekt scheitern, ehe es begann.”\n\nDas freilich scheint der beliebten Vorstellung zu widersprechen, dass OSS sich gerade deswegen rechne, weil sie nichts koste.\n\nWie passen diese beiden Perspektiven zusammen? In diesem Artikel helfen wir dir, Antworten auf diese Frage zu finden. Wir erklären, welche Vorteile du aus OSS ziehen kannst, was dich OSS in der Praxis kostet und wie du Umsetzungsschwierigkeiten überwindest.\n\nZunächst aber:\n\n## Was bedeutet Open Source?\n\nÜblicherweise betrachten wir Open Source und Open-Source-Software als Synonyme. Aber die damit verbundene Idee – der freie Austausch bestimmter Technologien, Ideen und Konzepte – existiert schon sehr viel länger.\n\nEines der frühesten und am häufigsten angeführten Beispiele stammt aus den frühen Jahren der amerikanischen Automobilindustrie. Für einen gewissen Zeitraum beschlossen die Hersteller, neue Entwicklungen nicht zu patentieren. Der Gedanke dahinter war, dass es besser für alle Beteiligten sein könnte, wenn der Markt als Ganzes wächst. Auch heute arbeiten konkurrierende Automobilproduzenten zusammen an Open-Source-Projekten.\n\nIn den 1950ern und -60ern teilte auch IBM seine Software-Geheimnisse mit der Welt. Das war seinerzeit ein äußerst innovativer Schachzug. Doch muss man der Ehrlichkeit halber hinzufügen, dass Software damals als nahezu wertlos galt und das Unternehmen sein Geld mit dem Vermieten seiner Hardwarekomponenten verdiente.\n\nDiese frühen Open-Source-Beispiele haben eines gemeinsam: Statt die Ergebnisse der eigenen Forschungsarbeit vor anderen Betrieben zu schützen, wurden sie großzügig der Öffentlichkeit zur Verfügung gestellt.\n\n## Open-Source-Software: Definition\n\nIm Softwarebereich entfaltete der Open-Source-Gedanke eine Wirkung, die weit über die Grenzen der Branche hinausging.\n\nIn Open-Source-Projekten wie den Open-Source-Seeds – Saatgut, welches ganz gezielt nicht patentiert wird – lebt er bis heute in vielen Bereichen weiter (wohl auch deswegen, weil sich genetische Codes sehr leicht als Software betrachten lassen).\n\nDie  Definition von Open-Source-Software lautet:\n\n**Eine Software kann als Open Source bezeichnet werden, wenn ihr Quellcode offen geteilt wird und eingesehen und verändert werden kann. Anderen Programmierern steht es frei, abgeleitete Werke aus ihr zu erstellen oder die Software in ihre eigenen Projekte einzubauen.**\n\nDiese Open-Source-Software-Definition schließt noch nicht alle Details mit ein. Auch gibt es ein paar Feinheiten bei der Frage von Lizenzen zu beachten – auf diese werden wir später im Artikel noch genauer eingehen. Als Einstieg in die Thematik aber ist sie bereits sehr präzise und umfassend.\n\n## Ist OSS immer kostenlos?\n\nNein. Dieses Missverständnis rankt sich bis heute um die OSS-Thematik. Dabei wurde der Name „Open Source” bewusst gewählt, weil der ursprüngliche – „Free Software” - sich bereits als zu missverständlich erwiesen hatte.\n\nSo ist es durchaus denkbar, dass du ein Open-Source-Produkt zu einem Premium-Preis verkaufst. Solange du den Quellcode dabei offenlegst, ist das wichtigste Kriterium erfüllt.\n\nZugegebenermaßen wird Open-Source-Software in der Regel tatsächlich kostenfrei angeboten. Die meisten professionellen Anbieter basieren ihr Erlösmodell inzwischen nicht mehr auf dem Verkauf von Lizenzen, sondern auf Dienstleistungen rund um das Produkt.\n\nOpen-Source-Software versteht sich als ein Instrument für Transparenz und Innovation. Als solches folgt es auch weiterhin den Leitlinien der Free Software – auch wenn es inzwischen nicht mehr unter diesem Banner läuft.\n\nSehen wir uns die Entwicklung von Closed Software zur Free Software und von dort zur Open-Source-Philosophie ein wenig genauer an.\n\n## Von Closed Software zu Free Software\n\nFree Software ist ein Begriff aus den frühen 1980ern. Er entstand, da immer mehr Entwickler(innen) es als unethisch betrachteten, dass ihre Arbeit von großen Unternehmen oder sogar Bildungseinrichtungen wie Universitäten kommerziell verwertet wurde.\n\nAls IBM seine Betriebssysteme mit der Welt teilte, stand dahinter weder Idealismus noch Profitdenken. Es war eine Entscheidung, die nahezu nebenbei getätigt wurde und an die wohl nur wenige der Beteiligten allzu viele Gedanken verschwendeten. Doch schon bald war eine rege Industrie um den Verkauf von Softwarelizenzen zu teilweise extrem hohen Preisen entstanden. Diese kostenpflichtigen Lösungen, deren Quellcode als Betriebsgeheimnis gehütet und mit Patenten geschützt wurde, bezeichnet man als „Closed Software” oder auch als „proprietäre” (mit einem Besitzanspruch verbundene) Software.\n\nDank des Einsatzes führender proprietärer Software erlangten finanzkräftige Betriebe oftmals einen deutlichen Wettbewerbsvorsprung. Kleine Konkurrenten mit guten Ideen, aber einem geringen Budget, gerieten demgegenüber ins Hintertreffen.\n\nFreie Software sollte allen zur Verfügung stehen. Durch das Freilegen des Source Codes wurde es möglich, die Funktionalität in eigene Software-Lösungen einzubauen und somit die Effizienz in der Software-Entwicklung zu steigern.\n\n## Von Free Software zu Open-Source-Software\n\nDe Begrifflichkeit von „Free Software” war von Anfang ein Problem. „Free” sollte sich auf die freie Verwendung beziehen, nicht auf eine kostenlose Nutzung. Um diesen Gedanken klarer hervorzuheben, entschied man sich schließlich für eine Umbenennung.\n\n„Open Source” drückt genau aus, worum es wirklich geht – nämlich um den Quellcode, der die Grundlage der Funktionalität bildet.\n\nHeute koexistieren beide Konzepte und ihre Schwerpunkte unterscheiden sich marginal:  Die Free-Software-Community beispielsweise versteht sich als philosophisches und politisches Fundament für die gesamte Branche, auf der letzten Endes auch konkreter gefasste Konzepte wie OSS (Open-Source-Software) aufbauen.\n\n## Open-Source-Software: Beispiele\n\nEs gibt inzwischen unzählige Beispiele für die Verwendung von Open Source in der Entwicklung neuer Software.\n\nDas erste Beispiel, mit dem die meisten Privatnutzer(innen) konfrontiert wurden, war zweifelsohne der Firefox-Internetbrowser. Vor dem Markteintritt war der Markt zunächst von einem Browser dominiert worden, der kostenlos, aber nicht Open Source war (Altavista), dann von einem, der fest mit dem proprietären Microsoft Windows Betriebssystem verbunden war (Internet Explorer). Firefox bot eine hervorragende und für seine vielen Add-ons gepriesene Open-Source-Alternative.\n\nSeitdem ist Open Source zum dominanten Distributions- beziehungsweise Lizenzierungsmodell aufgestiegen. Das Online-Wirtschaftsmagazin Deutsche Startups hat für verschiedene Branchen eine hervorragende Übersicht zusammengestellt:\n\n**Entwicklungswerkzeuge:** Python, Ruby und OGC sind Beispiele für Open-Source-Tools, auf die Entwickler zurückgreifen können.\n\n**Datenbanken:** MySQL, die führende Datenbanklösung weltweit, ist als Open Source angelegt. Gleiches gilt auch für konkurrierende Produkte wie PostgreSQL oder MongoDB. Anverwandte Lösungen wie [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/) sind ebenfalls Open-Source-Software, genauso wie der Dateimanager FreeCommander.\nGrafikdesign und Multimedia: GIMP oder Blender sind hervorragende Tools für alle, denen lizenzpflichtige, proprietäre Produkte zu teuer sind. Der VLC-Mediaplayer stellt die Funktionalität der meisten Nicht-Open-Source-Player in den Schatten.\n\n**Webtechnologie:** Einige grundlegende Technologien wie PHP erfüllen die Kriterien von Open Source.\n\n**Anderes:** LibreOffice und OpenOffice sind komplett als Open-Source-Anwendungen angelegt. Das E-Mail-Verwaltungsprogramm Thunderbird läuft ebenfalls unter einer Open-Source-Lizenz.\n\n## Was erhoffen sich Unternehmen von Open-Source-Software?\n\nVielleicht denkst du auch darüber nach, die IT deines Unternehmens so weit wie möglich auf eine Open-Source-Basis zu stellen. Damit stehst du, wie bereits erwähnt, nicht alleine da. Genau genommen sind Firmen, die ausschließlich auf proprietäre Lösungen setzen, inzwischen zur Minderheit geworden.\n\nFür die meisten Unternehmen spielen dabei die folgenden Überlegungen eine zentrale Rolle:\n\nOpen-Source-Software kann dazu beitragen, deine IT-Kosten zu senken.\nOpen-Source-Software ist flexibel und kann somit einfacher an persönliche Bedürfnisse angepasst werden.\n\nOpen-Source-Software genießt den Ruf, weniger Speicherkapazität zu verbrauchen und somit die Leistungsfähigkeit des Systems zu verbessern.\n\nOpen-Source-Software gilt als innovativer und anpassungsfähiger an sich wandelnde Marktbedingungen.\n\nWie nehmen sich diese vermeintlichen Vorteile in der Praxis aus? Werfen wir einen genaueren Blick auf OSS als Faktor in deinem Unternehmen.\n\nEinen Punkt können wir dabei nicht genug betonen:\n\n## OSS ist kein Business-Modell\n\nWie erwähnt erhoffen sich Unternehmen viel von OSS und sind enttäuscht darüber, wenn sich diese Erwartungen nicht erfüllen. Vor allem die finanziellen Auswirkungen stellen sich oftmals ganz und gar nicht so dar, wie erwartet.\n\nAuf die genauen Gründe dafür gehen wir noch genauer ein. Du solltest dir aber immer vor Augen führen, dass Open Source an sich niemals ein Geschäftsmodell darstellt, nicht einmal für die Unternehmen, die Software unter einer Open-Source-Lizenz vertreiben!\n\nOpen-Source-Software ist ein Konzept, das aus der Informations- und Datenfreiheitsbewegung stammt. Es erleichtert bestimmte Methoden und Vorgehensweisen, macht andere aber möglicherweise komplexer und aufwendiger.\n\nDu kannst Open Source nutzen, um deinen Geschäftserfolg zu steigern. Die Konzepte dafür aber musst du immer noch selbst entwickeln.\n\n## Warum manche Unternehmen trotzdem auf proprietäre Lösungen setzen\n\nDer Siegeszug von Open Source ist unbestreitbar. Letzten Endes lässt er sich auch damit begründen, dass kostenlose Software nahezu immer eine unwiderstehliche Anziehungskraft ausübt; sogar dann, wenn es vollkommen klar ist, dass der „Preis Null” teilweise teuer erkauft werden muss.\n\nUnd dennoch lebt Closed Software auch weiterhin fort. Wie kommt es dazu?\n\nZum einen bleibt es ungemein zufriedenstellend, wenn ein Softwarepaket so umfassend ist, dass es nicht nur sofort benutzt werden kann, sondern gleich alle erforderlichen Komponenten mitliefert. In vielen Bereichen sind proprietäre Produkte schlicht professioneller und umfassender. LibreOffice und Open Office sind hervorragend. An Office aber reichen sie noch immer nicht heran.\n\nWas noch schwerer wiegt: Bei OSS kommt es leichter zu Kompatibilitätsproblemen. Das ist bei Dokumenten wie Word noch zu verschmerzen. Bei komplexeren Fällen aber kann es den Entwicklungsprozess langsamer, fehleranfälliger oder sogar unmöglich machen.\n\nUnd obwohl manche Closed-Software-Anbieter langsamer auf Kundenanfragen reagieren als ihre Open-Source-Gegenspieler, so zeichnen sich andere durch prompte Reaktionen und schnelle Updates aus. Trotzdem ist es immer beruhigend, wenn dir bei Schwierigkeiten ein direkter Ansprechpartner zur Verfügung steht (weswegen dieser Aspekt inzwischen auch bei vielen OSS-Produkten berücksichtigt wird).\n\n## Die wahren Vorteile von Open-Source-Software\n\nEinige der von Unternehmer(innen) erwarteten Vorteile von Open Source sind durchaus berechtigt: So erhöht OSS in der Tat die Transparenz der verwendeten Software. Da du den Quellcode einsehen kannst, kannst du ihn nun potentiell nach deinem Geschmack anpassen, erweitern oder kürzen. Du kannst ihn in Software-Pakete einbauen, die du selbst entwickelst und damit den Aufwand deutlich reduzieren.\n\nAuch zeichnen sich viele Open-Source-Programme durch eine hohe Innovationskraft aus. Die dahinter stehenden Communities sind dynamisch, offen und helfen Neulingen in der Regel gerne.\n\nDarüber hinaus sind noch die folgenden Vorteile zu nennen:\n\nDurch die ständige praktische Prüfung durch andere Anwender(innen) erhalten die Entwickler(innen) der Software einen stetigen Feedback-Strom, der als Ausgangspunkt für Updates oder neue Versionen dienen kann.\nLangfristige Anwendbarkeit: Kommerzielle, proprietäre Software wird oftmals so schnell wie eine schlecht laufende Fernsehserie wieder vom Markt genommen, wenn sich der Verkaufserfolg nicht einstellt. Open-Source-Projekte sind nicht an solche Erwägungen gebunden und können auch über die ursprünglichen Entwickler hinweg Bestand haben.\n\nIst OSS tatsächlich kostengünstiger? Wir meinen: Es kommt auf das konkrete Beispiel an, aber in der Regel schon.\n\nOSS verursacht zusätzliche Kosten durch die Notwendigkeit von Schulungeneiner genaueren Zusammenstellung der Komponenten sowie einer feinen Abstimmung zwischen den Bausteinen. Gerade bei sehr teuren Einzelplatzlizenzen aber bleibt OSS die günstigere Alternative.\n\n## Die drei Lizenzmodelle von Open-Source-Software\n\nAn dieser Stelle macht aus unserer Sicht ein kleiner Einschub Sinn. Denn es könnte inzwischen der Eindruck entstanden sein, dass OSS als offenes, oftmals kostenlos angebotenes Produkt im Widerspruch zu Lizenzmodellen steht.\n\nDem ist aber nicht so. In Wahrheit ist auch Open-Source-Software nahezu immer mit einer bestimmten Lizenz verbunden. Diese Lizenzen regeln die Weiterverwendung der Software und sind sogar von essenzieller Bedeutung dafür, dass die Grundgedanken der Open-Source-Bewegung auch tatsächlich gewahrt bleiben.\n\nDie folgenden drei Lizenzen sind üblich:\n\n**Copyleft-Lizenz:** Hierbei handelt es sich um die strengste Lizenz. Sie schützt die ursprünglichen Freiheiten der Software und zwingt alle Nutzer(innen) der Software, jedwede Folgeprodukte unter den selben Lizenzbedingungen zu vertreiben oder anzubieten.\n\n**Beschränkte Copyleft-Lizenzen:** Bei manchen Produkten kann die Lizenz der Bearbeitungen teilweise abweichen. Dies räumt den Anwender(inne)n und Entwickler(inne)n mehr Freiheiten ein.\n\n**Permissive Lizenzen:** Kommen ohne Anweisungen aus. Was für OSS bedeutet, dass es den Bearbeiter(innen) frei steht, welche Lizenzbedingungen für die Ergebnisse ihrer Arbeit gelten sollen.\n\nBei allen Lizenzen kannst du für deine Produkte und deine Arbeit Geld verlangen. Darauf gehen wir  gleich noch ein.\n\n## Open Source & Agile-Methodik\n\nEin wichtiger Grund, warum Open Source in der Softwareentwicklung nahezu sofort auf ein so breites und positives Echo gestoßen ist, liegt in seiner Nähe zur agilen Methodik.\n\nBei [Agile Delivery](https://about.gitlab.com/de-de/solutions/agile-delivery/) steht ein Prozess im Fokus, bei dem durch das fortlaufende Einholen von Daten und einer Formalisierung des Austauschs im Team schnell und regelmäßig funktionierende Prototypen entwickelt werden.Diese dienen dann wiederum als Basis für weitere Optimierungen.\n\nIn beiden Ansätzen stehen Transparenz, Offenheit, schnelles Agieren, Teamarbeit, Kundenorientierung und ein schneller Weg zum fertigen Produkt im Mittelpunkt. Im Gegensatz zu proprietären Lösungen sind Open-Source-Produkte niemals wirklich fertig, sondern immer nur ein Zwischenstand.\n\nDu wirst feststellen, dass es dir deutlich leichter fällt, OSS in deinem Betrieb einzuführen, wenn du bereits Erfahrungen mit agilen Methoden gemacht hast.\n\n## Fallbeispiel 1: Linux\n\nDie möglicherweise bekannteste Open-Source-Software überhaupt ist Linux.\n\nLinux ist zu 100 % Open Source und der Quellcode ist somit frei einsehbar. In einer faszinierenden Entwicklung hat sich hieraus eine Vielzahl sogenannter „Distributionen” herausgebildet. Darunter versteht man eine bestimmte Konfiguration von Linux mit einer eigenen Anwendungsoberfläche und einer Palette zugehöriger Tools.\n\nLinux weist gegenüber Windows eine Vielzahl genau derjenigen Vorteile auf, die wir oben genannt haben: Es ist deutlich effizienter/schneller, flexibler und günstiger. Gerade seine einzigartige Anpassungsfähigkeit hat ihm zur Führerschaft im Serverbereich verholfen.\n\nGleichzeitig aber ist es auch komplizierter, sowohl was die Installation und den praktischen Einsatz angeht, und auf ein gut vorbereitetes IT-Team angewiesen.\n\nDas Besondere an Linux ist, dass die verschiedenen Distributionen unter unterschiedlichen Lizenzen vertrieben werden. So gibt es komplett kostenlose und sehr minimalistisch gehaltene Versionen; Varianten, die auf innovative Entwickler zugeschnitten sind; und zu guter Letzt Komplettpakete, die genauso komfortabel und komplett sind wie kommerzielle Closed Software (und entsprechend auch deutlich teurer).\n\nLinux ist ein Paradebeispiel dafür, wie vielseitig Open Source in der Praxis sein kann.\n\n## Fallbeispiel 2: GitLab\n\nAuch GitLab wurde von Anfang an und aus Überzeugung als Open-Source-Projekt angelegt.\n\nWas bedeutet OSS für uns konkret?\n\n*Der Quellcode von GitLab wurde unter einer MIT Open-Source-License veröffentlicht und kann frei eingesehen werden.\nWir freuen uns immer über Vorschläge zu Verbesserungen oder Erweiterungen. Im [GitLab-Forum](https://forum.gitlab.com/c/community/gitlab-for-open-source/49) findest du darüber hinaus andere Entwickler(innen), mit denen du dich spezifisch zu Open-Source-Themen austauschen kannst.\nMit dem GitLab-Development-Kit bieten wir eine Möglichkeit an, selbst aktiv den Quellcode an persönliche Präferenzen und Bedürfnisse anzupassen.\nIn unseren Repositories liegen unzählige Open-Source-Projekte.\nMit dem GitLab-for-Open-Source-Program unterstützen wir das Anlegen neuer OSS-Projekte, von denen die gesamte Community profitiert.*\n\nBei GitLab ist Open Source keine trockene Theorie. Beeindruckend ist zum Beispiel wie sich der Content-Management-Anbieter Drupal zu seinem 20-jährigen Jubiläum neu erfand und seine Dienstleistungen mit GitLab für neue Zielgruppen öffnete. Mehr dazu findest du in unserem Artikel über GitLab-Open-Source-Case-Studies.\n\nGerne stellen wir dir eine kostenlose [GitLab-Test-Lizenz](https://gitlab.com/-/trials/new) zur Verfügung.\n\n## OSS: Herausforderungen bei der Umsetzung\n\nAus der Sicht von Computer Weekly liegt der Hauptgrund dafür, dass viele Open-Source-Projekte in der Umsetzung scheitern, darin, dass nicht ausreichend Expertise im Unternehmen vorhanden ist.\n\nAus der Sicht des Magazins „müssen Unternehmen bereits vorab Zeit und Ressourcen investieren, um die erforderlichen Fähigkeiten und Kenntnisse aufzubauen oder externe Unterstützung in Anspruch zu nehmen – ob nun über einen Partner oder das Recruiting neuer Fachkräfte.”\n\nComputer Weekly betont auch, dass einer der potenziellen Vorteile von OSS – die Dynamik der Community und die Vielzahl von Lösungen, die nahezu täglich erscheinen – für manche Betriebe zu einem Nachteil werden kann. Beispielsweise, wenn die Optionen nicht mehr überschaubar sind und vor allem die Zusammenstellung der richtigen Komponenten sich als zu komplex und aufwändig gestaltet.\n\nDie Expertin Marieke Merkle empfiehlt deswegen ein Risk Mapping:\n\n„Bei einem solchen werden die Risiken identifiziert, welche mit dem konkreten im Unternehmen bereits erfolgenden oder geplanten Einsatz von Open-Source-Software verbunden sind. Auf dieser Grundlage kann ein Compliance-Prozess zunächst für denjenigen Einsatzbereich aufgebaut werden, bei welchem die größten Risiken bestehen. Im Anschluss kann die Compliance-Struktur sodann auf weitere Einsatzbereiche von Open-Source-Software ausgedehnt werden.”\n\n## Wie sieht die Zukunft von OSS aus?\n\nVorhersagen im IT-Bereich sind generell schwierig. In diesem Fall aber deuten sich doch einige klare Trends an:\n\nOSS wird weiter alle Bereiche der Industrie erreichen. Chief Visionary Officer der Firma Telmekom, Sergio Vemic, sagt dazu: „Ich glaube, dass Open Source in Zukunft immer wichtiger wird. Immer mehr Menschen werden sich damit beschäftigen, werden sie weiterentwickeln und pushen. Auch Firmen, die heute proprietäre Software anbieten, werden sich überlegen, diese künftig vielleicht als Open Source zu veröffentlichen.”\n\nOSS wird einen erheblichen Schub erfahren durch die weltweite Bevorzugung von Open-Source-Produkten im öffentlichen Sektor. Die Europäische Union nimmt hier bereits eine Vorreiterrolle ein.\n\nIn einigen Schlüsselindustrien wird OSS sich zu einer ernstzunehmenden Alternative zu Closed Software entwickeln. Dazu zählen zum Beispiel Edge Computing, [DevOps](https://about.gitlab.com/de-de/solutions/devops-platform/), Container-Orchestrierung sowie natürlich KI.\n\nGleichzeitig sehen einige Experten, dass bei vielen Investoren eine zunehmende Skepsis besteht, ob diese Projekte tatsächlich eine nennenswerte Rendite abwerfen können. Wir haben es bereits erwähnt: Open Source ist kein Business-Modell – aber es kann gelegentlich durchaus einem lohnenswerten Geschäft im Weg stehen! Es bleibt also weiterhin spannend.\n\n## Was sind die Potentiale von OSS und KI?\n\nKünstliche Intelligenz und Open-Source-Software sind die vielleicht stärksten aktuellen Trends im Bereich der Softwareentwicklung. So kann es kaum verwundern, dass sich eine gemeinsame Betrachtung lohnt.\n\nDas Institut für Innovation und Technik in Berlin stellt hierzu die alles entscheidende Frage: „Was bedeutet Open Source für Künstliche Intelligenz (KI)?” Die Analyse geht auf einige faszinierende Fälle ein, in denen Künstliche Intelligenz in der Open-Source-Software-Entwicklung bestimmte Projekte ermöglicht  hat, die in einem proprietär-kommerziellen Umfeld schlicht nicht zustande gekommen wären. Dazu gehört unter anderem ein Übersetzungs-Tool für verschiedene afrikanische Sprachen.\n\nSchon heute gibt es auch für Entwickler eine Vielzahl von OSS-Lösungen mit einem signifikanten KI-Anteil. Dazu gehören FauxPilot (Entwicklungstool), DALL-E (Text-to-Word-Anwendung) oder PaddleNLP (NLP-Bibliothek). Weitere KI- & OSS-Beispiele finden sich in einem Artikel der Computerwoche.\n\nMan kann aber auch fragen: Was bedeutet Künstliche Intelligenz für Open Source? Avi Press, CEO von Scarf, einem Unternehmen an der Schnittstelle zwischen KI, OSS und Kund(inn)en, meint dazu:\n\n„Ein zunehmender Anteil des (Open-Source- und sonstigen) Codes, auf den wir uns verlassen, wird von KI und nicht von Menschen geschrieben werden ... und wir wissen noch nicht, wie wir mit all den Auswirkungen einer Welt umgehen sollen, in der Menschen nicht die einzigen Hauptakteure sind.”\n\nEines steht fest: KI und OSS werden beide wachsen und sie werden gemeinsam wachsen. Die Ergebnisse aber werden zumindest teilweise das, was wir uns vorstellen können, um ein Vielfaches übersteigen.\n\n## Werden wir jemals ganz ohne Closed Software auskommen?\n\nDiese Vermutung bietet sich angesichts der oben genannten Entwicklungen und Tendenzen geradezu an.\n\nSicher ist, dass OSS entweder als eigenständiges Produkt oder Komponente einer größeren Software-Architektur an Bedeutung gewinnen wird. Genau so sicher ist aber, dass es auch in Zukunft Bereiche geben wird, in denen Unternehmen auf Closed Software setzen werden:\n\nTechnologien, mit denen sich in einem proprietären Umfeld höhere Gewinne erzielen lassen.\nTechnologien, die selbst entwickelt und nun intern genutzt werden und die einen signifikanten Vorsprung gegenüber der Konkurrenz gewährleisten.\nTechnologien, bei denen ein extrem hohes Maß an [Sicherheit / Security Compliance](https://about.gitlab.com/de-de/solutions/application-security-testing/) gefordert ist. Es scheint unwahrscheinlich, dass Banken in absehbarer Zeit auf einen breiten oder gar exklusiven Einsatz von OSS setzen werden.\n\nEs gibt allerdings bereits Bemühungen, Schwachpunkte von OSS systematisch auszumerzen. Wenn diese greifen, steht einer noch weitflächigeren Verwendung von Open Source auch in sicherheitskritischen Industrien nichts mehr im Weg.",[23,24],"education","open source","yml",{},true,"/de-de/blog/what-is-open-source-software",{"ogTitle":15,"ogImage":19,"ogDescription":16,"ogSiteName":30,"noIndex":12,"ogType":31,"ogUrl":32,"title":15,"canonicalUrls":32,"description":16},"https://about.gitlab.com","article","https://about.gitlab.com/blog/what-is-open-source-software","de-de/blog/what-is-open-source-software",[23,9],"CQP-0_YG6aRhbIgZB4qKCes3DJiOWHqMYph3Iu5RDDw",{"data":37},{"logo":38,"freeTrial":43,"sales":48,"login":53,"items":58,"search":367,"minimal":402,"duo":420,"pricingDeployment":430},{"config":39},{"href":40,"dataGaName":41,"dataGaLocation":42},"/de-de/","gitlab logo","header",{"text":44,"config":45},"Kostenlose Testversion anfordern",{"href":46,"dataGaName":47,"dataGaLocation":42},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":49,"config":50},"Vertrieb kontaktieren",{"href":51,"dataGaName":52,"dataGaLocation":42},"/de-de/sales/","sales",{"text":54,"config":55},"Anmelden",{"href":56,"dataGaName":57,"dataGaLocation":42},"https://gitlab.com/users/sign_in/","sign in",[59,86,182,187,288,348],{"text":60,"config":61,"cards":63},"Plattform",{"dataNavLevelOne":62},"platform",[64,70,78],{"title":60,"description":65,"link":66},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":67,"config":68},"Erkunde unsere Plattform",{"href":69,"dataGaName":62,"dataGaLocation":42},"/de-de/platform/",{"title":71,"description":72,"link":73},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":74,"config":75},"Lerne GitLab Duo kennen",{"href":76,"dataGaName":77,"dataGaLocation":42},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":79,"description":80,"link":81},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":82,"config":83},"Mehr erfahren",{"href":84,"dataGaName":85,"dataGaLocation":42},"/de-de/why-gitlab/","why gitlab",{"text":87,"left":27,"config":88,"link":90,"lists":94,"footer":164},"Produkt",{"dataNavLevelOne":89},"solutions",{"text":91,"config":92},"Alle Lösungen anzeigen",{"href":93,"dataGaName":89,"dataGaLocation":42},"/de-de/solutions/",[95,120,142],{"title":96,"description":97,"link":98,"items":103},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":99},{"icon":100,"href":101,"dataGaName":102,"dataGaLocation":42},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[104,108,111,116],{"text":105,"config":106},"CI/CD",{"href":107,"dataGaLocation":42,"dataGaName":105},"/de-de/solutions/continuous-integration/",{"text":71,"config":109},{"href":76,"dataGaLocation":42,"dataGaName":110},"gitlab duo agent platform - product menu",{"text":112,"config":113},"Quellcodeverwaltung",{"href":114,"dataGaLocation":42,"dataGaName":115},"/de-de/solutions/source-code-management/","Source Code Management",{"text":117,"config":118},"Automatisierte Softwarebereitstellung",{"href":101,"dataGaLocation":42,"dataGaName":119},"Automated software delivery",{"title":121,"description":122,"link":123,"items":128},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":124},{"href":125,"dataGaName":126,"dataGaLocation":42,"icon":127},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[129,133,138],{"text":130,"config":131},"Application Security Testing",{"href":125,"dataGaName":132,"dataGaLocation":42},"Application security testing",{"text":134,"config":135},"Schutz der Software-Lieferkette",{"href":136,"dataGaLocation":42,"dataGaName":137},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":139,"config":140},"Software Compliance",{"href":141,"dataGaName":139,"dataGaLocation":42},"/de-de/solutions/software-compliance/",{"title":143,"link":144,"items":149},"Bewertung",{"config":145},{"icon":146,"href":147,"dataGaName":148,"dataGaLocation":42},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[150,154,159],{"text":151,"config":152},"Sichtbarkeit und Bewertung",{"href":147,"dataGaLocation":42,"dataGaName":153},"Visibility and Measurement",{"text":155,"config":156},"Wertstrommanagement",{"href":157,"dataGaLocation":42,"dataGaName":158},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":160,"config":161},"Analysen und Einblicke",{"href":162,"dataGaLocation":42,"dataGaName":163},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":165,"items":166},"GitLab für",[167,172,177],{"text":168,"config":169},"Enterprise",{"href":170,"dataGaLocation":42,"dataGaName":171},"/de-de/enterprise/","enterprise",{"text":173,"config":174},"Kleinunternehmen",{"href":175,"dataGaLocation":42,"dataGaName":176},"/de-de/small-business/","small business",{"text":178,"config":179},"den öffentlichen Sektor",{"href":180,"dataGaLocation":42,"dataGaName":181},"/de-de/solutions/public-sector/","public sector",{"text":183,"config":184},"Preise",{"href":185,"dataGaName":186,"dataGaLocation":42,"dataNavLevelOne":186},"/de-de/pricing/","pricing",{"text":188,"config":189,"link":191,"lists":195,"feature":275},"Ressourcen",{"dataNavLevelOne":190},"resources",{"text":192,"config":193},"Alle Ressourcen anzeigen",{"href":194,"dataGaName":190,"dataGaLocation":42},"/de-de/resources/",[196,229,247],{"title":197,"items":198},"Erste Schritte",[199,204,209,214,219,224],{"text":200,"config":201},"Installieren",{"href":202,"dataGaName":203,"dataGaLocation":42},"/de-de/install/","install",{"text":205,"config":206},"Kurzanleitungen",{"href":207,"dataGaName":208,"dataGaLocation":42},"/de-de/get-started/","quick setup checklists",{"text":210,"config":211},"Lernen",{"href":212,"dataGaLocation":42,"dataGaName":213},"https://university.gitlab.com/","learn",{"text":215,"config":216},"Produktdokumentation",{"href":217,"dataGaName":218,"dataGaLocation":42},"https://docs.gitlab.com/","product documentation",{"text":220,"config":221},"Best-Practice-Videos",{"href":222,"dataGaName":223,"dataGaLocation":42},"/de-de/getting-started-videos/","best practice videos",{"text":225,"config":226},"Integrationen",{"href":227,"dataGaName":228,"dataGaLocation":42},"/de-de/integrations/","integrations",{"title":230,"items":231},"Entdecken",[232,237,242],{"text":233,"config":234},"Kundenerfolge",{"href":235,"dataGaName":236,"dataGaLocation":42},"/de-de/customers/","customer success stories",{"text":238,"config":239},"Blog",{"href":240,"dataGaName":241,"dataGaLocation":42},"/de-de/blog/","blog",{"text":243,"config":244},"Remote",{"href":245,"dataGaName":246,"dataGaLocation":42},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":248,"items":249},"Vernetzen",[250,255,260,265,270],{"text":251,"config":252},"GitLab-Services",{"href":253,"dataGaName":254,"dataGaLocation":42},"/de-de/services/","services",{"text":256,"config":257},"Community",{"href":258,"dataGaName":259,"dataGaLocation":42},"/community/","community",{"text":261,"config":262},"Forum",{"href":263,"dataGaName":264,"dataGaLocation":42},"https://forum.gitlab.com/","forum",{"text":266,"config":267},"Veranstaltungen",{"href":268,"dataGaName":269,"dataGaLocation":42},"/events/","events",{"text":271,"config":272},"Partner",{"href":273,"dataGaName":274,"dataGaLocation":42},"/de-de/partners/","partners",{"backgroundColor":276,"textColor":277,"text":278,"image":279,"link":283},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":280,"config":281},"the source promo card",{"src":282},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":284,"config":285},"Lies die News",{"href":286,"dataGaName":287,"dataGaLocation":42},"/de-de/the-source/","the source",{"text":289,"config":290,"lists":292},"Unternehmen",{"dataNavLevelOne":291},"company",[293],{"items":294},[295,300,306,308,313,318,323,328,333,338,343],{"text":296,"config":297},"Über",{"href":298,"dataGaName":299,"dataGaLocation":42},"/de-de/company/","about",{"text":301,"config":302,"footerGa":305},"Karriere",{"href":303,"dataGaName":304,"dataGaLocation":42},"/jobs/","jobs",{"dataGaName":304},{"text":266,"config":307},{"href":268,"dataGaName":269,"dataGaLocation":42},{"text":309,"config":310},"Geschäftsführung",{"href":311,"dataGaName":312,"dataGaLocation":42},"/company/team/e-group/","leadership",{"text":314,"config":315},"Team",{"href":316,"dataGaName":317,"dataGaLocation":42},"/company/team/","team",{"text":319,"config":320},"Handbuch",{"href":321,"dataGaName":322,"dataGaLocation":42},"https://handbook.gitlab.com/","handbook",{"text":324,"config":325},"Investor Relations",{"href":326,"dataGaName":327,"dataGaLocation":42},"https://ir.gitlab.com/","investor relations",{"text":329,"config":330},"Trust Center",{"href":331,"dataGaName":332,"dataGaLocation":42},"/de-de/security/","trust center",{"text":334,"config":335},"AI Transparency Center",{"href":336,"dataGaName":337,"dataGaLocation":42},"/de-de/ai-transparency-center/","ai transparency center",{"text":339,"config":340},"Newsletter",{"href":341,"dataGaName":342,"dataGaLocation":42},"/company/contact/#contact-forms","newsletter",{"text":344,"config":345},"Presse",{"href":346,"dataGaName":347,"dataGaLocation":42},"/press/","press",{"text":349,"config":350,"lists":351},"Kontakt",{"dataNavLevelOne":291},[352],{"items":353},[354,357,362],{"text":49,"config":355},{"href":51,"dataGaName":356,"dataGaLocation":42},"talk to sales",{"text":358,"config":359},"Support-Portal",{"href":360,"dataGaName":361,"dataGaLocation":42},"https://support.gitlab.com","support portal",{"text":363,"config":364},"Kundenportal",{"href":365,"dataGaName":366,"dataGaLocation":42},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":368,"login":369,"suggestions":376},"Schließen",{"text":370,"link":371},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":372,"config":373},"gitlab.com",{"href":56,"dataGaName":374,"dataGaLocation":375},"search login","search",{"text":377,"default":378},"Vorschläge",[379,381,386,388,393,398],{"text":71,"config":380},{"href":76,"dataGaName":71,"dataGaLocation":375},{"text":382,"config":383},"Code Suggestions (KI)",{"href":384,"dataGaName":385,"dataGaLocation":375},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":105,"config":387},{"href":107,"dataGaName":105,"dataGaLocation":375},{"text":389,"config":390},"GitLab auf AWS",{"href":391,"dataGaName":392,"dataGaLocation":375},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":394,"config":395},"GitLab auf Google Cloud",{"href":396,"dataGaName":397,"dataGaLocation":375},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":399,"config":400},"Warum GitLab?",{"href":84,"dataGaName":401,"dataGaLocation":375},"Why GitLab?",{"freeTrial":403,"mobileIcon":408,"desktopIcon":413,"secondaryButton":416},{"text":404,"config":405},"Kostenlos testen",{"href":406,"dataGaName":47,"dataGaLocation":407},"https://gitlab.com/-/trials/new/","nav",{"altText":409,"config":410},"GitLab-Symbol",{"src":411,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":409,"config":414},{"src":415,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":197,"config":417},{"href":418,"dataGaName":419,"dataGaLocation":407},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":421,"mobileIcon":426,"desktopIcon":428},{"text":422,"config":423},"Erfahre mehr über GitLab Duo",{"href":424,"dataGaName":425,"dataGaLocation":407},"/de-de/gitlab-duo/","gitlab duo",{"altText":409,"config":427},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":429},{"src":415,"dataGaName":412,"dataGaLocation":407},{"freeTrial":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"Zurück zur Preisübersicht",{"href":185,"dataGaName":434,"dataGaLocation":407,"icon":435},"back to pricing","GoBack",{"altText":409,"config":437},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":439},{"src":415,"dataGaName":412,"dataGaLocation":407},{"title":441,"button":442,"config":447},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":443,"config":444},"GitLab Transcend jetzt ansehen",{"href":445,"dataGaName":446,"dataGaLocation":42},"/de-de/events/transcend/virtual/","transcend event",{"layout":448,"icon":449},"release","AiStar",{"data":451},{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":646},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":454,"config":455},"Quelltext der Seite anzeigen",{"href":456,"dataGaName":457,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":460,"config":461},"Diese Seite bearbeiten",{"href":462,"dataGaName":463,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":465,"config":466},"Beteilige dich",{"href":467,"dataGaName":468,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":470,"facebook":471,"youtube":472,"linkedin":473},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[475,498,552,579,613],{"title":60,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOps-Plattform",{"href":69,"dataGaName":480,"dataGaLocation":458},"devsecops platform",[482],{"title":183,"links":483},[484,488,493],{"text":485,"config":486},"Tarife anzeigen",{"href":185,"dataGaName":487,"dataGaLocation":458},"view plans",{"text":489,"config":490},"Vorteile von Premium",{"href":491,"dataGaName":492,"dataGaLocation":458},"/de-de/pricing/premium/","why premium",{"text":494,"config":495},"Vorteile von Ultimate",{"href":496,"dataGaName":497,"dataGaLocation":458},"/de-de/pricing/ultimate/","why ultimate",{"title":499,"links":500},"Lösungen",[501,506,509,511,516,521,525,528,531,536,538,540,543,547],{"text":502,"config":503},"Digitale Transformation",{"href":504,"dataGaName":505,"dataGaLocation":458},"/de-de/topics/digital-transformation/","digital transformation",{"text":507,"config":508},"Sicherheit und Compliance",{"href":125,"dataGaName":132,"dataGaLocation":458},{"text":117,"config":510},{"href":101,"dataGaName":102,"dataGaLocation":458},{"text":512,"config":513},"Agile Entwicklung",{"href":514,"dataGaName":515,"dataGaLocation":458},"/de-de/solutions/agile-delivery/","agile delivery",{"text":517,"config":518},"Cloud-Transformation",{"href":519,"dataGaName":520,"dataGaLocation":458},"/de-de/topics/cloud-native/","cloud transformation",{"text":522,"config":523},"SCM",{"href":114,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":105,"config":526},{"href":107,"dataGaName":527,"dataGaLocation":458},"continuous integration & delivery",{"text":155,"config":529},{"href":157,"dataGaName":530,"dataGaLocation":458},"value stream management",{"text":532,"config":533},"GitOps",{"href":534,"dataGaName":535,"dataGaLocation":458},"/de-de/solutions/gitops/","gitops",{"text":168,"config":537},{"href":170,"dataGaName":171,"dataGaLocation":458},{"text":173,"config":539},{"href":175,"dataGaName":176,"dataGaLocation":458},{"text":541,"config":542},"Öffentlicher Sektor",{"href":180,"dataGaName":181,"dataGaLocation":458},{"text":544,"config":545},"Bildungswesen",{"href":546,"dataGaName":23,"dataGaLocation":458},"/de-de/solutions/education/",{"text":548,"config":549},"Finanzdienstleistungen",{"href":550,"dataGaName":551,"dataGaLocation":458},"/de-de/solutions/finance/","financial services",{"title":188,"links":553},[554,556,558,560,563,565,567,569,571,573,575,577],{"text":200,"config":555},{"href":202,"dataGaName":203,"dataGaLocation":458},{"text":205,"config":557},{"href":207,"dataGaName":208,"dataGaLocation":458},{"text":210,"config":559},{"href":212,"dataGaName":213,"dataGaLocation":458},{"text":215,"config":561},{"href":217,"dataGaName":562,"dataGaLocation":458},"docs",{"text":238,"config":564},{"href":240,"dataGaName":241,"dataGaLocation":458},{"text":233,"config":566},{"href":235,"dataGaName":236,"dataGaLocation":458},{"text":243,"config":568},{"href":245,"dataGaName":246,"dataGaLocation":458},{"text":251,"config":570},{"href":253,"dataGaName":254,"dataGaLocation":458},{"text":256,"config":572},{"href":258,"dataGaName":259,"dataGaLocation":458},{"text":261,"config":574},{"href":263,"dataGaName":264,"dataGaLocation":458},{"text":266,"config":576},{"href":268,"dataGaName":269,"dataGaLocation":458},{"text":271,"config":578},{"href":273,"dataGaName":274,"dataGaLocation":458},{"title":289,"links":580},[581,583,585,587,589,591,593,597,602,604,606,608],{"text":296,"config":582},{"href":298,"dataGaName":291,"dataGaLocation":458},{"text":301,"config":584},{"href":303,"dataGaName":304,"dataGaLocation":458},{"text":309,"config":586},{"href":311,"dataGaName":312,"dataGaLocation":458},{"text":314,"config":588},{"href":316,"dataGaName":317,"dataGaLocation":458},{"text":319,"config":590},{"href":321,"dataGaName":322,"dataGaLocation":458},{"text":324,"config":592},{"href":326,"dataGaName":327,"dataGaLocation":458},{"text":594,"config":595},"Sustainability",{"href":596,"dataGaName":594,"dataGaLocation":458},"/sustainability/",{"text":598,"config":599},"Vielfalt, Inklusion und Zugehörigkeit",{"href":600,"dataGaName":601,"dataGaLocation":458},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":329,"config":603},{"href":331,"dataGaName":332,"dataGaLocation":458},{"text":339,"config":605},{"href":341,"dataGaName":342,"dataGaLocation":458},{"text":344,"config":607},{"href":346,"dataGaName":347,"dataGaLocation":458},{"text":609,"config":610},"Transparenzerklärung zu moderner Sklaverei",{"href":611,"dataGaName":612,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":614,"links":615},"Nimm Kontakt auf",[616,619,624,626,631,636,641],{"text":617,"config":618},"Sprich mit einem Experten/einer Expertin",{"href":51,"dataGaName":52,"dataGaLocation":458},{"text":620,"config":621},"Support",{"href":622,"dataGaName":623,"dataGaLocation":458},"/support/","get help",{"text":363,"config":625},{"href":365,"dataGaName":366,"dataGaLocation":458},{"text":627,"config":628},"Status",{"href":629,"dataGaName":630,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":632,"config":633},"Nutzungsbedingungen",{"href":634,"dataGaName":635,"dataGaLocation":458},"/terms/","terms of use",{"text":637,"config":638},"Datenschutzerklärung",{"href":639,"dataGaName":640,"dataGaLocation":458},"/de-de/privacy/","privacy statement",{"text":642,"config":643},"Cookie-Einstellungen",{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":458},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":458},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":458,"id":645,"isOneTrustButton":27},[655],{"id":656,"title":657,"body":8,"config":658,"content":660,"description":8,"extension":25,"meta":664,"navigation":27,"path":665,"seo":666,"stem":667,"__hash__":668},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":659},"BlogAuthor",{"name":18,"config":661},{"headshot":662,"ctfId":663},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[670,683,696],{"content":671,"config":681},{"title":672,"description":673,"authors":674,"heroImage":676,"date":677,"body":678,"category":9,"tags":679,"updatedDate":677},"Kubernetes: Container-Orchestrierung verstehen und einsetzen","Kubernetes (K8s) für containerisierte Anwendungen: Dieser Artikel erklärt Architektur, Vorteile, Grenzen und den Einsatz mit GitLab.",[675],"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",[680,24],"kubernetes",{"slug":682,"featured":12,"template":13},"kubernetes-the-container-orchestration-solution",{"content":684,"config":694},{"title":685,"description":686,"authors":687,"date":689,"body":690,"heroImage":691,"category":9,"tags":692},"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.",[688],"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",[24,693,259],"git",{"featured":12,"template":13,"slug":695},"whats-new-in-git-2-53-0",{"content":697,"config":707},{"title":698,"description":699,"authors":700,"heroImage":691,"date":704,"body":705,"category":9,"tags":706},"Was ist neu in Git 2.52.0?","Alles zum aktuellen Release, darunter der neue git-last-modified(1)-Befehl, Verbesserungen an History-Rewriting-Tools und eine neue Maintenance-Strategie.",[701,702,703],"Christian Couder","Toon Claes","Patrick Steinhardt","2025-11-17","Das Git-Projekt hat kürzlich [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) veröffentlicht. Nach einem relativ kurzen 8-Wochen-[Release-Zyklus für 2.51](https://about.gitlab.com/de-de/blog/what-s-new-in-git-2-51-0/), aufgrund des Sommers auf der Nordhalbkugel, ist dieses Release wieder beim üblichen 12-Wochen-Zyklus.\n\nSchauen wir uns einige Highlights an, darunter Beiträge vom GitLab Git-Team und der weiteren Git-Community.\n\n## Neuer git-last-modified(1)-Befehl\n\nViele Git-Forges wie GitLab zeigen Dateien in einer Tree-Ansicht wie dieser an:\n\n\n| Name        | Last commit                                             | Last update  |\n| ------------- | --------------------------------------------------------- | -------------- |\n| README.md   | README: *.txt -> *.adoc fixes                           | 4 months ago |\n| RelNotes    | Start 2.51 cycle, the first batch                       | 4 weeks ago  |\n| SECURITY.md | SECURITY: describe how to report vulnerabilities        | 4 years      |\n| abspath.c   | abspath: move related functions to abspath              | 2 years      |\n| abspath.h   | abspath: move related functions to abspath              | 2 years      |\n| aclocal.m4  | configure: use AC_LANG_PROGRAM consistently             | 15 years ago |\n| add-patch.c | pager: stop using `the_repository`                      | 7 months ago |\n| advice.c    | advice: allow disabling default branch name advice      | 4 months ago |\n| advice.h    | advice: allow disabling default branch name advice      | 4 months ago |\n| alias.h     | rebase -m: fix serialization of strategy options        | 2 years      |\n| alloc.h     | git-compat-util: move alloc macros to git-compat-util.h | 2 years ago  |\n| apply.c     | apply: only write intents to add for new files          | 8 days ago   |\n| archive.c   | Merge branch 'ps/parse-options-integers'                | 3 months ago |\n| archive.h   | archive.h: remove unnecessary include                   | 1 year       |\n| attr.h      | fuzz: port fuzz-parse-attr-line from OSS-Fuzz           | 9 months ago |\n| banned.h    | banned.h: mark `strtok()` and `strtok_r()` as banned    | 2 years      |\n\n\n\u003Cbr>\u003C/br>\n\nNeben den Dateien selbst zeigen wir auch an, welcher Commit jede jeweilige Datei zuletzt geändert hat. Diese Information lässt sich einfach aus Git extrahieren, indem du folgenden Befehl ausführst:\n\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\n\nObwohl schön und einfach, hat das einen erheblichen Haken: Git hat keine Möglichkeit, diese Information für jede dieser Dateien in einem einzigen Befehl zu extrahieren. Um also den letzten Commit für alle Dateien im Tree zu erhalten, müssten wir diesen Befehl für jede Datei separat ausführen. Das führt zu einer Befehlspipeline ähnlich der folgenden:\n\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\n\nNatürlich ist das nicht sehr effizient:\n\n\n* Wir müssen für jede Datei einen neuen Git-Befehl starten.\n\n\n* Git muss die History für jede Datei separat durchlaufen.\n\n\n\nAls Konsequenz ist diese gesamte Operation ziemlich kostspielig und erzeugt erhebliche Last für GitLab.\n\n\n\nUm diese Probleme zu beheben, wurde ein neuer Git-Subcommand `git-last-modified(1)` eingeführt. Dieser Befehl gibt den Commit für jede Datei eines gegebenen Commits zurück:\n\n```shell\n\n$ git last-modified HEAD\n\n\ne56f6dcd7b4c90192018e848d0810f091d092913        add-patch.c\n373ad8917beb99dc643b6e7f5c117a294384a57e        advice.h\ne9330ae4b820147c98e723399e9438c8bee60a80        advice.c\n5e2feb5ca692c5c4d39b11e1ffa056911dd7dfd3        alloc.h\n954d33a9757fcfab723a824116902f1eb16e05f7        RelNotes\n4ce0caa7cc27d50ee1bedf1dff03f13be4c54c1f        apply.c\n5d215a7b3eb0a9a69c0cb9aa43dcae956a0aa03e        archive.c\nc50fbb2dd225e7e82abba4380423ae105089f4d7        README.md\n72686d4e5e9a7236b9716368d86fae5bf1ae6156        attr.h\nc2c4138c07ca4d5ffc41ace0bfda0f189d3e262e        archive.h\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.c\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.h\n60ff56f50372c1498718938ef504e744fe011ffb        banned.h\n4960e5c7bdd399e791353bc6c551f09298746f61        alias.h\n2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0        SECURITY.md\n1e58dba142c673c59fbb9d10aeecf62217d4fc9c        aclocal.m4\n\n```\n\n\n\nDer Vorteil davon ist offensichtlich, dass wir jetzt nur noch einen einzigen Git-Prozess ausführen müssen, um all diese Informationen abzuleiten. Aber noch wichtiger ist, dass wir die History nur einmal für alle Dateien zusammen durchlaufen müssen, anstatt sie mehrmals durchlaufen zu müssen. Dies wird wie folgt erreicht:\n\n\n1. Beginne damit, die History vom angegebenen Commit aus zu durchlaufen.\n\n\n2. Für jeden Commit:\n\n\n\n   1. Wenn er keinen der Pfade ändert, an denen wir interessiert sind, fahren wir mit dem nächsten Commit fort.\n   2. Wenn er es tut, geben wir die Commit-ID zusammen mit dem Pfad aus. Außerdem entfernen wir den Pfad aus der Menge der interessanten Pfade.\n\n\n\n3. Wenn die Liste der interessanten Pfade leer wird, stoppen wir.\n\n\n\nGitaly wurde bereits angepasst, um den neuen Befehl zu verwenden, aber die Logik ist noch hinter einem Feature-Flag geschützt. Vorläufige Tests haben gezeigt, dass `git-last-modified(1)` in den meisten Situationen mindestens doppelt so schnell ist wie die Verwendung von `git log --max-count=1`.\n\n\n\n*Diese Änderungen wurden [ursprünglich geschrieben](https://github.com/ttaylorr/git/tree/tb/blame-tree) von mehreren Entwicklern von GitHub und wurden [upstream](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) in Git von [Toon Claes](https://gitlab.com/toon) integriert.*\n\n\n\n## Signatur-bezogene Verbesserungen für git-fast-export(1) und git-fast-import(1)\n\n\n\nDie Befehle `git-fast-export(1)` und `git-fast-import(1)` sind dafür konzipiert, hauptsächlich von Interoperabilitäts- oder History-Rewriting-Tools verwendet zu werden. Das Ziel von Interoperabilitäts-Tools ist es, Git problemlos mit anderer Software interagieren zu lassen, normalerweise einem anderen Versionskontrollsystem, das Daten in einem anderen Format als Git speichert. Zum Beispiel ist [hg-fast-export.sh](https://github.com/frej/fast-export) ein „Mercurial-zu-Git-Konverter, der git-fast-import verwendet.\"\n\n\n\nAlternativ lassen History-Rewriting-Tools Benutzer – normalerweise Admins – Änderungen an der History ihrer Repositories vornehmen, die Versionskontrollsysteme nicht zulassen. Zum Beispiel sagt [reposurgeon](http://www.catb.org/esr/reposurgeon/) in seiner [Einführung](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction), dass sein Zweck ist, „riskante Operationen zu ermöglichen, die Versionskontrollsysteme dich nicht durchführen lassen wollen, wie zum Beispiel (a) Bearbeitung vergangener Kommentare und Metadaten, (b) Entfernung von Commits, (c) Zusammenführung und Aufteilung von Commits, (d) Entfernung von Dateien und Subtrees aus der Repo-History, (e) Zusammenführung oder Verknüpfung von zwei oder mehr Repos und (f) Aufteilung eines Repos in zwei durch Durchtrennung einer Parent-Child-Verbindung, wobei die Branch-Struktur beider Child-Repos erhalten bleibt.\"\n\n\n\nInnerhalb von GitLab verwenden wir [git-filter-repo](https://github.com/newren/git-filter-repo), um Admins einige riskante Operationen an ihren Git-Repositories durchführen zu lassen. Leider haben bis Git 2.50 (veröffentlicht im letzten Juni) sowohl `git-fast-export(1)` als auch `git-fast-import(1)` kryptografische Commit-Signaturen überhaupt nicht behandelt. Obwohl `git-fast-export(1)` also eine Option `--signed-tags=\u003Cmode>` hatte, die es Benutzern ermöglicht zu ändern, wie kryptografische Tag-Signaturen behandelt werden, wurden Commit-Signaturen einfach ignoriert.\n\n\n\nKryptografische Signaturen sind sehr fragil, weil sie auf den exakten Commit- oder Tag-Daten basieren, die signiert wurden. Wenn sich die signierten Daten oder irgendetwas von ihrer vorhergehenden History ändert, wird die kryptografische Signatur ungültig. Dies ist eine fragile, aber notwendige Anforderung, um diese Signaturen nützlich zu machen.\n\n\n\nAber im Kontext des Neuschreibens der History ist das ein Problem:\n\n\n\n* Wir möchten vielleicht kryptografische Signaturen sowohl für Commits als auch für Tags behalten, die nach dem Neuschreiben noch gültig sind (z.B. weil sich die History, die zu ihnen führt, nicht geändert hat).\n\n\n* Wir möchten vielleicht neue kryptografische Signaturen für Commits und Tags erstellen, bei denen die vorherige Signatur ungültig geworden ist.\n\n\n\nWeder `git-fast-import(1)` noch `git-fast-export(1)` erlauben diese Anwendungsfälle jedoch, was einschränkt, was Tools wie [git-filter-repo](https://github.com/newren/git-filter-repo) oder [reposurgeon](http://www.catb.org/esr/reposurgeon/) erreichen können.\n\n\n\nWir haben einige erhebliche Fortschritte gemacht:\n\n\n\n* In Git 2.50 haben wir eine Option `--signed-commits=\u003Cmode>` zu `git-fast-export(1)` hinzugefügt, um Commit-Signaturen zu exportieren, und Unterstützung in `git-fast-import(1)`, um sie zu importieren.\n\n\n* In Git 2.51 haben wir das Format verbessert, das zum Exportieren und Importieren von Commit-Signaturen verwendet wird, und wir haben es für `git-fast-import(1)` möglich gemacht, sowohl eine Signatur zu importieren, die auf der SHA-1-Objekt-ID des Commits gemacht wurde, als auch eine, die auf seiner SHA-256-Objekt-ID gemacht wurde.\n\n\n* In Git 2.52 haben wir die Optionen `--signed-commits=\u003Cmode>` und `--signed-tags=\u003Cmode>` zu `git-fast-import(1)` hinzugefügt, sodass der Benutzer Kontrolle darüber hat, wie signierte Daten zum Zeitpunkt des Imports behandelt werden.\n\n\n\nEs gibt noch mehr zu tun. Wir müssen die Fähigkeit hinzufügen:\n\n\n\n* Nur die Commit-Signaturen beizubehalten, die noch gültig sind, zu `git-fast-import(1)`.\n\n\n* Daten neu zu signieren, bei denen die Signatur ungültig wurde.\n\n\n\nWir arbeiten bereits an diesen nächsten Schritten, und erwarten, dass dies in Git 2.53 landet. Sobald das erledigt ist, werden Tools wie `git-filter-repo(1)` endlich beginnen, kryptografische Signaturen eleganter zu handhaben. Wir werden dich in unserem nächsten Git-Release-Blogpost auf dem Laufenden halten.\n\n\n\n*Dieses Projekt wurde von [Christian Couder](https://gitlab.com/chriscool) geleitet.*\n\n\n\n## Neue und verbesserte git-maintenance(1)-Strategien\n\n\n\nGit-Repositories benötigen regelmäßige Wartung, um sicherzustellen, dass sie gut funktionieren. Diese Wartung führt eine Reihe verschiedener Aufgaben aus: Referenzen werden optimiert, Objekte werden komprimiert und veraltete Daten werden bereinigt.\n\n\n\nBis Git 2.28 wurden diese Wartungsaufgaben von `git-gc(1)` durchgeführt. Das Problem mit diesem Befehl war, dass er nicht mit Blick auf Anpassbarkeit entwickelt wurde: Während bestimmte Parameter konfiguriert werden können, ist es nicht möglich zu kontrollieren, welche Teile eines Repositorys optimiert werden sollen. Das bedeutet, dass es möglicherweise nicht für alle Anwendungsfälle gut geeignet ist. Noch wichtiger ist, dass es sehr schwer wurde, darüber zu iterieren, wie genau Git Repository-Wartung durchführt.\n\n\n\nUm dieses Problem zu beheben und uns wieder iterieren zu lassen, hat [Derrick Stolee](https://github.com/derrickstolee) `git-maintenance(1)` eingeführt. Im Gegensatz zu `git-gc(1)` ist es mit Blick auf Anpassbarkeit entwickelt und ermöglicht es dem Benutzer zu konfigurieren, welche Aufgaben speziell in einem bestimmten Repository ausgeführt werden sollen. Dieses neue Tool wurde in Git 2.29 zum Standard für Gits automatisierte Wartung gemacht, aber standardmäßig verwendet es immer noch `git-gc(1)`, um die Wartung durchzuführen.\n\n\n\nWährend diese Standard-Wartungsstrategie in kleinen oder sogar mittelgroßen Repositories gut funktioniert, ist sie im Kontext großer Monorepos problematisch. Der größte limitierende Faktor ist, wie `git-gc(1)` Objekte neu packt: Immer wenn es mehr als 50 Packfiles gibt, wird das Tool alle zusammen in ein einziges Packfile zusammenführen. Diese Operation ist ziemlich CPU-intensiv und verursacht viele I/O-Operationen, sodass diese Operation für große Monorepos leicht viele Minuten oder sogar Stunden dauern kann.\n\n\n\nGit weiß bereits, wie diese Repacks durch „geometrisches Repacking\" minimiert werden können. Die Idee ist einfach: Die Packfiles, die im Repository existieren, müssen einer geometrischen Progression folgen, bei der jedes Packfile mindestens doppelt so viele Objekte enthalten muss wie das nächstkleinere. Dies ermöglicht es Git, die Anzahl der erforderlichen Repacks zu amortisieren und gleichzeitig sicherzustellen, dass es insgesamt nur eine relativ kleine Anzahl von Packfiles gibt. Dieser Modus wurde von [Taylor Blau](https://github.com/ttaylorr) in Git 2.32 eingeführt, aber er wurde nicht als Teil der automatisierten Wartung eingebunden.\n\n\n\nAlle Teile existieren, um die Repository-Wartung für große Monorepos viel skalierbarer zu machen: Wir haben das flexible `git-maintenance(1)`-Tool, das erweitert werden kann, um eine neue Wartungsstrategie zu haben, und wir haben einen besseren Weg, Objekte neu zu packen. Alles, was getan werden muss, ist, diese beiden zu kombinieren.\n\n\n\nUnd genau das haben wir mit Git 2.52 getan! Wir haben eine neue „geometrische\" Wartungsstrategie eingeführt, die du in deinen Git-Repositories konfigurieren kannst. Diese Strategie ist als vollständiger Ersatz für die alte Strategie basierend auf `git-gc(1)` gedacht. Hier ist der Config-Code, den du benötigst:\n\n\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\n\n\n\nAb jetzt verwendet Git geometrisches Repacking verwenden, um deine Objekte zu optimieren. Das sollte zu weniger Churn führen und gleichzeitig sicherstellen, dass deine Objekte in einem besser optimierten Zustand sind, besonders in großen Monorepos.\n\n\n\nIn Git 2.53 wollen wir dies zur Standard-Strategie machen. Also bleib dran!\n\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n\n## Neuer Subcommand für git-repo(1) zur Anzeige von Repository-Metriken\n\n\n\nDie Performance von Git-Operationen in einem Repository hängt oft von bestimmten Eigenschaften seiner zugrunde liegenden Struktur ab. Bei GitLab hosten wir einige extrem große Repositories, und Einblicke in die allgemeine Struktur eines Repositorys sind entscheidend, um die Performance zu verstehen. Während es möglich ist, verschiedene Git-Befehle und andere Tools zusammenzusetzen, um bestimmte Repository-Metriken zu ermitteln, fehlt Git eine Möglichkeit, Informationen über die Form/Struktur eines Repositorys über einen einzigen Befehl zu liefern. Dies hat zur Entwicklung anderer externer Tools geführt, wie [git-sizer(1)](https://github.com/github/git-sizer), um diese Lücke zu füllen.\n\n\n\nMit dem Release von Git 2.52 wurde ein neuer „structure\"-Subcommand zu git-repo(1) hinzugefügt mit dem Ziel, Informationen über die Struktur eines Repositorys zu liefern. Derzeit zeigt er Informationen über die Anzahl der Referenzen und Objekte im Repository in der folgenden Form an:\n\n```shell\n\n$ git repo structure\n\n\n| Repository structure | Value  |\n| -------------------- | ------ |\n| * References         |        |\n|   * Count            |   1772 |\n|     * Branches       |      3 |\n|     * Tags           |   1025 |\n|     * Remotes        |    744 |\n|     * Others         |      0 |\n|                      |        |\n| * Reachable objects  |        |\n|   * Count            | 418958 |\n|     * Commits        |  87468 |\n|     * Trees          | 168866 |\n|     * Blobs          | 161632 |\n|     * Tags           |    992 |\n\n```\n\n\n\nIn zukünftigen Releases hoffen wir, dies zu erweitern und andere interessante Datenpunkte bereitzustellen, wie die größten Objekte im Repository.\n\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n\n## Verbesserungen im Zusammenhang mit dem Google Summer of Code 2025\n\n\n\nWir hatten drei erfolgreiche Projekte mit dem Google Summer of Code.\n\n\n\n### Refactoring zur Reduzierung von Gits globalem Status\n\n\n\nGit enthält mehrere globale Variablen, die in der gesamten Codebasis verwendet werden. Dies erhöht die Komplexität des Codes und verringert die Wartbarkeit. Als Teil dieses Projekts hat [Ayush Chandekar](https://ayu-ch.github.io/) daran gearbeitet, die Verwendung der globalen Variable `the_repository` durch eine Reihe von Patches zu reduzieren.\n\n\n\n*Das Projekt wurde betreut von [Christian Couder](https://gitlab.com/chriscool) und [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n\n\n### Maschinenlesbares Repository-Informations-Abfrage-Tool\n\n\n\nGit fehlt ein zentraler Weg, um Repository-Informationen abzurufen, was Benutzer zwingt, sie aus verschiedenen Befehlen zusammenzusetzen. Während `git-rev-parse(1)` zum De-facto-Tool für den Zugriff auf viele dieser Informationen geworden ist, liegt dies außerhalb seines Hauptzwecks.\n\n\n\nAls Teil dieses Projekts hat [Lucas Oshiro](https://lucasoshiro.github.io/en/) einen neuen Befehl eingeführt, `git-repo(1)`, der alle Repository-Level-Informationen beherbergen wird. Benutzer können jetzt `git repo info` verwenden, um Repository-Informationen zu erhalten:\n\n```shell\n\n$ git repo info layout.bare layout.shallow object.format references.format\n\nlayout.bare=false\nlayout.shallow=false\nobject.format=sha1\nreferences.format=reftable\n\n```\n\n\n\n*Das Projekt wurde betreut von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) und [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n\n### Konsolidierung ref-bezogener Funktionalität in git-refs\n\n\n\nGit bietet mehrere Befehle zur Verwaltung von Referenzen, nämlich `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)` und `git-pack-refs(1)`. Das macht sie schwerer zu entdecken und erzeugt sich überschneidende Funktionalität. Um dies anzugehen, haben wir den Befehl `git-refs(1)` eingeführt, um diese Operationen unter einer einzigen Schnittstelle zu konsolidieren. Als Teil dieses Projekts hat [Meet Soni](https://inosmeet.github.io/) den Befehl durch Hinzufügen der folgenden Subcommands erweitert:\n\n\n\n* `git refs optimize` zur Optimierung des Reference-Backends\n\n\n* `git refs list` zum Auflisten aller Referenzen\n\n\n* `git refs exists` zur Überprüfung der Existenz einer Referenz\n\n\n\n*Das Projekt wurde betreut von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) und [shejialuo](https://luolibrary.com/).*\n\n\n\n## Was kommt als Nächstes?\n\n\n\nBereit, diese Verbesserungen zu erleben? Aktualisiere auf Git 2.52.0 und fang an, `git last-modified` zu verwenden.\n\n\n\nBei GitLab werden wir natürlich sicherstellen, dass all diese Verbesserungen schließlich in einer GitLab-Instanz in deiner Nähe landen!\n\n\n\nErfahre mehr in den [offiziellen Git 2.52.0 Release Notes](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) und erkunde unser [vollständiges Archiv der Git-Entwicklungs-Berichterstattung](https://about.gitlab.com/blog/tags/git/).",[24,693,259],{"featured":12,"template":13,"slug":708},"whats-new-in-git-2-52-0",{"promotions":710},[711,725,738],{"id":712,"categories":713,"header":715,"text":716,"button":717,"image":722},"ai-modernization",[714],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":718,"config":719},"Get your AI maturity score",{"href":720,"dataGaName":721,"dataGaLocation":241},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":723},{"src":724},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":726,"categories":727,"header":730,"text":716,"button":731,"image":735},"devops-modernization",[728,729],"product","devsecops","Are you just managing tools or shipping innovation?",{"text":732,"config":733},"Get your DevOps maturity score",{"href":734,"dataGaName":721,"dataGaLocation":241},"/assessments/devops-modernization-assessment/",{"config":736},{"src":737},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":739,"categories":740,"header":742,"text":716,"button":743,"image":747},"security-modernization",[741],"security","Are you trading speed for security?",{"text":744,"config":745},"Get your security maturity score",{"href":746,"dataGaName":721,"dataGaLocation":241},"/assessments/security-modernization-assessment/",{"config":748},{"src":749},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":751,"blurb":752,"button":753,"secondaryButton":758},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":754,"config":755},"Kostenlosen Test starten",{"href":756,"dataGaName":47,"dataGaLocation":757},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":49,"config":759},{"href":51,"dataGaName":52,"dataGaLocation":757},1772652056982]