[{"data":1,"prerenderedAt":1095},["ShallowReactive",2],{"/en-us/blog/tags/open-source/":3,"navigation-de-de":20,"banner-de-de":441,"footer-de-de":454,"open source-tag-page-de-de":664},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/open-source","tags",false,"",{"tag":9,"tagSlug":10},"open source","open-source",{"template":12},"BlogTag","content:en-us:blog:tags:open-source.yml","yaml","Open Source","content","en-us/blog/tags/open-source.yml","en-us/blog/tags/open-source","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/de-de/main-navigation","de-de",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/de-de/","gitlab logo","header",{"text":30,"config":31},"Kostenlose Testversion anfordern",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Vertrieb kontaktieren",{"href":37,"dataGaName":38,"dataGaLocation":28},"/de-de/sales/","sales",{"text":40,"config":41},"Anmelden",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"Plattform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":53,"config":54},"Erkunde unsere Plattform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/de-de/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":60,"config":61},"Lerne GitLab Duo kennen",{"href":62,"dataGaName":63,"dataGaLocation":28},"/de-de/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":68,"config":69},"Mehr erfahren",{"href":70,"dataGaName":71,"dataGaLocation":28},"/de-de/why-gitlab/","why gitlab",{"title":73,"items":74},"Erste Schritte mit",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/de-de/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Entwicklererfahrung",{"href":83,"dataGaName":84,"dataGaLocation":28},"/de-de/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":28,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":28,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":28,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":28,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":28,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":28},"/de-de/resources/",[202,235,258],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":28},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,248,253],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/de-de/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":259,"items":260},"Vernetzen",[261,266,271,276,281],{"text":262,"config":263},"GitLab-Services",{"href":264,"dataGaName":265,"dataGaLocation":28},"/de-de/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Veranstaltungen",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partner",{"href":284,"dataGaName":285,"dataGaLocation":28},"/de-de/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":291,"config":292},"the source promo card",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lies die News",{"href":297,"dataGaName":298,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":300,"config":301,"lists":303},"Unternehmen",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"Über",{"href":309,"dataGaName":310,"dataGaLocation":28},"/de-de/company/","about",{"text":312,"config":313,"footerGa":316},"Karriere",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Geschäftsführung",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Handbuch",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor Relations",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":28},"/de-de/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Kontakt",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Support",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Kundenportal",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Schließen",{"text":381,"link":382},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Vorschläge",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Code Suggestions (KI)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab auf AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab auf Google Cloud",{"href":408,"dataGaName":409,"dataGaLocation":386},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Warum GitLab?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Kostenlos testen",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"GitLab-Symbol",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":445,"config":446},"Beta testen",{"href":447,"dataGaName":448,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":660,"_type":14,"title":661,"_source":16,"_file":662,"_stem":663,"_extension":19},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":652},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,558,588,622],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":557,"dataGaLocation":463},"/de-de/solutions/finance/","financial services",{"title":194,"links":559},[560,562,564,566,569,571,574,576,578,580,582,584,586],{"text":206,"config":561},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":563},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":565},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":567},{"href":223,"dataGaName":568,"dataGaLocation":463},"docs",{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":463},{"text":239,"config":572},{"href":573,"dataGaName":242,"dataGaLocation":463},"/customers/",{"text":249,"config":575},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":577},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":579},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":581},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":583},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":585},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":587},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":307,"config":591},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":593},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":595},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":597},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":599},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":601},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":463},"/sustainability/",{"text":607,"config":608},"Vielfalt, Inklusion und Zugehörigkeit",{"href":609,"dataGaName":610,"dataGaLocation":463},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":612},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":614},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":616},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":618,"config":619},"Transparenzerklärung zu moderner Sklaverei",{"href":620,"dataGaName":621,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Nimm Kontakt auf",[625,628,630,632,637,642,647],{"text":626,"config":627},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":629},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":631},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":638,"config":639},"Nutzungsbedingungen",{"href":640,"dataGaName":641,"dataGaLocation":463},"/terms/","terms of use",{"text":643,"config":644},"Datenschutzerklärung",{"href":645,"dataGaName":646,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":648,"config":649},"Cookie-Einstellungen",{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":463},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":463},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":665,"featuredPost":1074,"totalPagesCount":1093,"initialPosts":1094},[666,691,712,736,758,781,801,826,851,872,894,916,935,954,972,991,1011,1031,1051],{"_path":667,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":676,"config":684,"_id":687,"_type":14,"title":688,"_source":16,"_file":689,"_stem":690,"_extension":19},"/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":669,"description":670,"ogTitle":669,"ogDescription":670,"noIndex":6,"ogImage":671,"ogUrl":672,"ogSiteName":673,"ogType":674,"canonicalUrls":672,"schema":675},"Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds","Erfahre, wie das Open-Source-Versionskontrollsystem entstanden ist und was Linus davon hält, neue Programmiersprachen zu Git hinzuzufügen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":669,"description":670,"authors":677,"heroImage":671,"date":679,"body":680,"category":10,"tags":681,"updatedDate":683},[678],"Patrick Steinhardt","2025-04-07","Das Versionskontrollsystem Git wurde am 7. April 2005 vom \"Vater\" des Linux-Kernels, Linus Torvalds, veröffentlicht. Heute feiern wir den 20. Jahrestag dieses wichtigen Projekts, das mittlerweile von fast allen Entwickler(inne)n verwendet wird. Zu diesem Anlass habe ich mit Linus über die Geschichte von Git und darüber gesprochen, warum er die Rolle des Chefentwicklers von Git abgegeben hat und was seiner Meinung nach die wichtigsten Meilensteine sind.\n\n**2005 warst du bereits Betreuer des aufstrebenden Linux-Kernels. Warum hast du dich entschieden, ein neues Versionskontrollsystem zu entwickeln?**\n\nAnfangs habe ich Versionskontrolle wirklich gehasst.\n\nIch habe herkömmliche Versionskontrollsysteme (CVS/RCS/SCCS) sowohl als Endbenutzer (z. B. beim Nachverfolgen von Open-Source-Projekten wie [GCC](https://gcc.gnu.org/)) als auch als Entwickler (bei Transmeta haben wir für alles CVS genutzt) kennengelernt und hatte wirklich eine tiefe Abneigung dagegen.\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nDamals wechselten die meisten Projekte, die CVS verwendeten, vermutlich zu [SVN](https://subversion.apache.org/), aber für mich war das ehrlich gesagt nur Schönrederei. SVN war ja nichts als CVS in einer anderen Form und mit einem geringfügig besseren UI, aber die grundlegenden Dinge waren nicht besser und es wurden sogar einige neue Probleme hinzugefügt.\n\nEs gibt zu viele Probleme mit CVS und den anderen Lösungen, um sie hier alle aufzulisten. Glücklicherweise wurden sie alle zum Großteil obsolet und junge Entwickler(innen) müssen sich wahrscheinlich nie mit einem dieser Systeme beschäftigen. Ich weigerte mich also kategorisch, für den Kernel damit zu arbeiten, auch wenn wir für die Nachverfolgung des Codes einiger Untersysteme (vor allem beim Netzwerk) in den 90ern tatsächlich CVS verwendeten.\n\nDamals lebte ich in der Bay Area. Larry McVoy, den ich von früheren Projekten kannte (vor allem von [Imbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)), hatte BitMover gegründet, bei dem ein neues Versionskontrollmodell namens BitKeeper, oder kurz BK, verwendet wurde.\n\nBK war zwar nicht Open Source, aber Larry hatte eine Vorliebe für Open-Source-Projekte und hatte das Gefühl, dass die fehlende Versionskontrolle die Entwicklung des Kernels wirklich ausbremste. Er hatte nicht unrecht, aber die traditionelle Quellcodeverwaltung funktionierte für mich einfach nicht. Larry verbrachte einige Zeit damit, mir und David Miller (einem Netzwerkbetreuer und bestehendem CVS-Benutzer) zu zeigen, was BitKeeper alles konnte.\n\nBK war nicht perfekt und basierte wie so viele andere Systeme zur Quellcodeverwaltung auf dem Source Code Control System (SCCS) und setzte daher wie alle anderen auf dasselbe unzureichende Modell mit „dateibasiertem Verlauf“. Dieses verursachte riesige, fundamentale Probleme, wenn Dateien umbenannt und gelöscht wurden.\n\nAndererseits war BK nicht nur reine Schönrederei. Es basierte zwar grundlegend auf SCCS, aber auf höherer Ebene behob es einige wirklich fundamentale Probleme und ermöglichte eine echte verteilte Entwicklung. Zudem hatte es einen echten globalen – keinen reinen dateibasierten – Verlauf, sodass es tatsächlich Code von verschiedenen Entwicklungszweigen zusammenführen konnte.\n\nMit CVS war das Erstellen von Branches und deren Zusammenführung etwas, das man mit anderen planen und besprechen musste – also ein großes Ereignis. Mit BK war jedes Repository ein Branch. Heute halten wir das für selbstverständlich, und natürlich ist Git noch viel weiter gegangen: Es gibt viele Branches *pro* Repository. Doch auch das viel eingeschränktere Modell von BK war zu diesem Zeitpunkt ein echter Wendepunkt.\n\nAber wie gesagt, BK war nicht perfekt. Es nutzte einen dateibasierten Verlauf, was ein fundamentales Problem ist, denn dadurch können Dateien einfach nicht zuverlässig umbenannt und zusammengeführt werden, was unvermeidlich zu Chaos und Probleme führt (alle, die CVS kennen: Denkt an Attic …). Außerdem gab es Einschränkungen bei der Skalierbarkeit. Diese wurden aber nur langsam etwas problematischer.\n\nDas größte Problem bei BK war die Lizenzierung. Auch wenn im Laufe der Jahre (wir verwendeten BK von 2002 bis 2005) viele Kernel-Betreuer(innen) zu diesem System wechselten, gab es immer wieder Schwierigkeiten damit. Diese Schwierigkeiten spitzten sich Ende 2004 zu, als der Einsatz von BK für den Kernel einige Monate später praktisch nicht mehr möglich war.\n\nIch war nun in der Situation, dass ich drei Jahre lang endlich eine Versionskontrolle verwendet hatte, die tatsächlich funktionierte und viele Probleme gelöst hat. Ich wollte also keinesfalls wieder zum Zustand vor der Versionskontrolle zurückkehren, doch in den Jahren, in denen wir BK eingesetzt hatten, war von der Open-Source-Community nicht wirklich eine bessere Lösung gekommen.\n\nSicher, die Leute wussten, dass CVS und SVN nicht wirklich gut funktionierten, und es gab Projekte, in denen alternative Ansätze verfolgt wurden, doch diese waren teilweise sogar noch schlechter (sie waren im Grunde einfach nur schick verpacktes Patch-Tracking). Einige dagegen hatten zwar gute Ideen, machten aber schreckliche Entwicklungsfehler (siehe [Monotone](https://www.monotone.ca/)).\n\nIch sah mich also eine Weile um und erkannte dann, dass es nur einen Ausweg gab: Ich musste meine eigene Lösung programmieren.\n\nTechnisch gesehen dauerte es nur wenige Tage, die erste Version von Git zu erstellen – das kann man alles im Git-Commit-Verlauf nachlesen. Dort sieht man wunderbar, wie es von quasi Null zu einer gerade so nutzbaren Lösung wurde, für die ich dann eine Woche später Patches veröffentlichte (und die dann einige Tage danach aktiv für den Kernel verwendet wurde).\n\nDabei wird aber die Tatsache außer Acht gelassen, dass ich bis zu diesem Zeitpunkt schon eine Weile über das Problem *nachgedacht* hatte. Programmieren ist einfach. Ein gutes Konzept ist das, was zählt. Hinter diesen wenigen Tagen steckt also einiges an Vorarbeit, die sehr wichtig ist – und das sieht man im Verlauf nicht.\n\nDiese erste Version war sehr, sehr einfach und konnte vieles von dem nicht, was später noch kommen sollte. Man kann aber auch in diesen ersten Tagen schon viel vom Kernkonzept sehen.\n\n**Kannst du uns einen kurzen Rückblick über die ersten Tage und Wochen des Git-Projekts geben?**\n\nIch hatte im Grunde beschlossen, die Kernel-Entwicklung einzustellen, bis ich eine Alternative hatte, die für mich funktionierte. Das Resultat sollte eine verteilte Entwicklung und Höchstleistung ermöglichen sowie ein System sein, mit dem man absolut verlässlich jegliche Beeinträchtigung verhindern kann.\n\nIch möchte betonen, dass ich mich nicht wirklich für Quellcodeverwaltungssysteme interessierte. Ich war am Endergebnis interessiert, nicht am Prozess. Git war mir also nie so wichtig wie der Kernel: Ich arbeite an Linux, weil ich Kernels spannend finde. Ich habe an Git gearbeitet, weil ich es musste.\n\nDamit wären wir dann auch schon bei deiner nächsten Frage.\n\n**Du hast die Rolle des Chefentwicklers von Git nach einigen Monaten an Junio Hamano übergeben, der dies noch immer ist. Warum hast du deine Position abgegeben, und warum an Junio?**\n\nDie Übergabe der Rolle war keine schwierige Entscheidung. Es war vielmehr so: „Sobald ich jemanden finde, dem ich das Projekt anvertrauen kann, gehe ich wieder zurück und arbeite nur noch am Kernel.“\n\nDas soll nicht heißen, dass ich einfach alles hingeworfen und auf das Beste gehofft habe. Ich war rund vier Monate lang Chefentwickler von Git, weil ich spürte, dass ich jemanden finden musste, der gekommen war, um zu bleiben, und der diesen ominösen „guten Riecher“ hatte.\n\nJunio war als einer der Ersten dabei – quasi ab der ersten Woche. Aber ich bin nicht einfach zu ihm hin gerannt und habe gesagt: „Du bist dran.“ Es braucht eine Weile, bis man sieht, wer wirklich dabei bleibt und wer sinnvollen Code schreibt und sinnvolle Entscheidungen trifft.\n\nUnd ich denke, Junio war ein echtes Vorbild. Ich bekomme viel zu viel Lob für die paar Monate, die ich in Git gesteckt habe – besonders angesichts des 20-jährigen Jubiläums. Ich bin zwar dafür verantwortlich, dass das Kernkonzept richtig umgesetzt und das Projekt zum Laufen gebracht wurde, aber Junio hat das Projekt wirklich geleitet (damit will ich nicht die hunderten anderen Beteiligten vergessen).\n\n**Die erste Version des Versionskontrollsystems Mercurial wurde 12 Tage nach der ersten Version von Git am 19. April 2005 veröffentlicht. Viele Leute behaupten, dass die User Experience von Mercurial der von Git überlegen war, aber heute ist Git deutlich beliebter. Warum glaubst du, hat Git sich gegen Mercurial durchgesetzt?**\n\nOh, ein großer Teil davon sind offensichtlich nur Netzwerkeffekte, und Quellcodeverwaltungssysteme haben sehr starke Netzwerkeffekte. Deshalb hat CVS trotz all seiner Einschränkungen so lange überlebt.\n\nDer Kernel verwendete Git und es wurde irgendwann in der Community von Ruby on Rails sehr beliebt – und dann setzte es sich überall durch.\n\nAber ich bin wirklich überzeugt, dass das Konzept von Git besser ist. Das Kernmodell ist sowohl sehr einfach als auch sehr leistungsfähig, und ich denke, das machte es einfacher, es in andere Umgebungen zu übertragen. JGit war ein frühes Beispiel dafür, aber es gibt natürlich Implementierungen wie das virtuelle Dateisystem MSgit usw.\n\nWährend Git anfangs berühmt-berüchtigterweise schwierig zu nutzen war, glaube ich, dass vieles davon darauf zurückzuführen ist, dass die Leute Dinge zuvor „richtig“ machen mussten. Die Leute kamen nämlich von anderen Umgebungen und fanden Git nicht intuitiv, da Git ein paar harte Entscheidungen getroffen hatte, die Nutzer(innen) von herkömmlichen Quellcodeverwaltungssystemen niemals gemacht hätten.\n\n**Das Git-Projekt ist nie stehengeblieben, seit du die Rolle des Chefentwicklers an Junio übergeben hast, und die Community arbeitet kontinuierlich an neuen Funktionen. Was waren deiner Meinung nach die wichtigsten Meilensteine, nachdem du das Projekt verlassen hast?**\n\nDas ist schwer zu beantworten, da ich Git ja so entwickelt hatte, dass es für mich funktionierte. Die Dinge, die *ich* verwende, haben also quasi vom ersten Tag an funktioniert. Ein offensichtliches Beispiel: Für viele Leute war es offensichtlich ein riesiger Schritt, Git auf Windows zum Laufen zu bringen, aber *mich* betraf das überhaupt nicht. ;-)\n\nGit hat ja auch eine ganze Infrastruktur, mit der es einfacher zu nutzen ist. Die größten Meilensteine entstanden meiner Meinung nach aber, als die Menschen die Git-Infrastruktur heranzogen und Dinge darauf aufbauend entwickelten. Diese fließen natürlich oft auch wieder in Git-Funktionen ein, aber gleichzeitig ist der Meilenstein etwas Externes.\n\nEin offensichtliches Beispiel: Alle großen Git-Hosting-Websites waren große Meilensteine. Dadurch, dass Git verteilt war, waren diese viel einfacher zu entwickeln, aber der *Meilenstein* war dann, dass das Hosting es den Benutzer(innen) so einfach machte, Git für verschiedenste Projekte zu nutzen.\n\n**Wenn du wieder in der Lage wärst, hauptberuflich an Git zu arbeiten, gäbe es etwas, das du gerne implementieren würdest?**\n\nAuf keinen Fall. Git hat von Anfang an alles getan, was ich brauchte – ich nutze es tatsächlich nur ziemlich eingeschränkt, und mir ist nur ein Projekt wichtig.\n\nUnd ich sage „Auf keinen Fall“, weil ich mich auf eine meiner früheren Antworten beziehe: Ich war noch nie wirklich an Quellcodeverwaltungssystemen interessiert. Ich denke, ein wichtiger Grund dafür, dass Git sich von anderen Quellcodeverwaltungssystemen so sehr unterscheidet – größtenteils im positiven Sinne – ist, dass ich Git eher wie ein verteiltes Journaling-Dateisystem angegangen bin und nicht wie eine herkömmliche Quellcodeverwaltung.\n\n**Gibt es eine Funktion oder eine konzeptionelle Entscheidung in Git, die du im Nachhinein bereust?**\n\nKonzeptionelle Entscheidungen? Nein. Ich bin immer noch überzeugt, dass das übergeordnete Konzept sehr gut ist. Man kann verschiedene Git-Konzepte diskutieren, ohne auf die kleinteilige Komplexität der eigentlichen Implementierung eingehen zu müssen.\n\nUnd ich denke, das ist wichtig in einem Projekt. Man benötigt ein bestimmtes übergeordnetes Prinzip, dem die konzeptionelle Ausrichtung eines Projekts folgt.\n\nManchmal treiben die Leute das zu weit und denken, dass das übergeordnete Konzept bedeutet, dass die Implementierung dann sklavisch einem Kernprinzip folgen muss. Das ist aber auch falsch – die *Implementierung* hat viele hässliche Grenzfälle, da die Realität nun einmal hart ist und Menschen seltsame Dinge wollen. Es ist schon eine Art übergeordnetes Konzept nötig, auf das man sich beziehen kann und über das man auf übergeordneter Ebene argumentieren kann, bevor man sich die Hände an der harten Realität schmutzig macht.\n\nIch denke, Git hat da ein gutes Gleichgewicht gefunden. Ein sehr geradliniges Objektspeicher-Konzept („strukturierte Merkle-Bäume“, wenn du aus dem CS-Bereich kommst, oder stell sie dir einfach als „inhaltsadressierbaren Speicher“ vor, wenn du aus dem Dateisystem-Bereich kommst). Dieses Kernkonzept ist da, ist aber gleichzeitig in der Realität nur ein winziger Teil des eigentlichen Codes. Der größte Teil des *Codes* betrifft all die Dinge, die man mit dem Kernkonzept machen kann. Diese grundlegende konzeptionelle Klarheit gibt dem Projekt trotzdem eine Art übergeordnete Struktur.\n\nEs ist die gleiche Art von übergeordneter Struktur, die Unix selbst hatte, von „alles ist eine Datei“ bis hin zur Prozessabwicklung. Es gibt zwar ein paar übergeordnete „Konzepte“, aber bei 99 % des Codes geht es ganz einfach darum, das, was man auf diesem Design aufgebaut ist, so zu gestalten, dass es uns in der realen Welt nutzt.\n\nIch habe zwei Mantras hinsichtlich der Technologie: „Wenn ich weiter geblickt habe, so deshalb, weil ich auf den Schultern von Riesen stehe“ (Newton) und „Genie ist 1 % Inspiration und 99 % Prozent Transpiration“ (Edison).\n\nAber da wir schon über die 99 % Transpiration sprechen: Obwohl ich mit dem Gesamtdesign sehr zufrieden bin, gibt es sicherlich verschiedene Details, die ich anders gemacht hätte, wenn ich Git heute entwickeln würde.\n\nEhrlich gesagt, sind sie aber nicht so wichtig. Viel wichtiger sind all die *guten* Details, die in den letzten zwei Jahrzehnten entwickelt wurden.\n\n**Im Linux-Kernel wurde Rust als Programmiersprache für einige der Subsysteme eingeführt. Glaubst du, dass es sinnvoll ist, solche neueren Programmiersprachen auch in Git zu verwenden?**\n\nIch vermute, dass es bei Git weniger Gründe gibt, Sprachen zu mischen, was immer etwas schwierig ist.\n\nIm Kernel ist das Endergebnis eine einzige Kernel-Binärdatei – auch wenn der Großteil davon dynamisch als Module geladen werden kann, sind sie immer noch effektiv in einer einzige Binärdatei verbunden.\n\nDas macht die Verwendung mehrerer Sprachen komplexer. Andererseits gibt es für den Kernel auch mehr Gründe, sich mit der Speichersicherheit und folglich mit neueren Sprachen zu befassen.\n\nWenn jemand Teile von Git in Rust oder einer anderen Programmiersprache schreiben möchte, ist es vermutlich viel sinnvoller, einfach eine separate Implementierung zu erstellen, anstatt zu versuchen, in einer Binärdatei mehrere Sprachen zu mischen.\n\nDie Kernideen von Git sind im Grunde so einfach, dass es vermutlich nicht allzu schwierig ist, einfach parallele Implementierungen des Kernel zu haben. Dann kann man bestimmte Problembereiche gezielt angehen, in denen unterschiedliche Sprachen sinnvoll sind.\n\nDas haben wir natürlich schon in Git gesehen: Genau das ist JGit. Hier wurde eine andere Programmiersprache verwendet, die sinnvoller für die webbasierte Umgebung war.\n\nIch weiß, dass es bereits Rust-Implementierungen einiger der Kernfunktionen von Git gibt. Hier ist die Situation vermutlich ähnlich: Sie werden in bestimmten Situationen sinnvoller sein als einfach alles in Rust umzuwandeln.\n\nAllen, die sich für die Implementierung mit Rust interessieren, empfehle ich, nach Bereichen Ausschau zu halten, in denen die Vorteile von Rust offensichtlicher sind. Ich glaube nicht, dass die Verwendung von C für den Standard-Quellcode von Git wirklich so problematisch ist.\n\n**Alle paar Jahre tauchen neue Versionskontrollsysteme auf. Glaubst du, dass Git auch in Zukunft vorne dabei bleiben wird?**\n\nIch habe bereits die Netzwerkeffekte bei Quellcodeverwaltungssystemen erwähnt. Meiner Meinung nach muss ein neues System daher nicht einfach nur ein bisschen, sondern viel, viel besser sein, um Git zu ersetzen. Oder aber so kompatibel, dass es dann eigentlich nur eine neue Implementierung von Git ist.\n\nIch denke, dass sich die Situation in der Quellcodeverwaltung geändert hat: Git hat nicht die riesigen, fundamentalen Lücken, die Quellcodeverwaltungssysteme vor Git hatten. Es ist also ziemlich schwer, „enorm besser“ zu sein.\n\nAlso, ja, ich gehe davon aus, dass Git auf absehbare Zeit vorne dabei bleibt und die Leute eher an Verbesserungen *an* Git arbeiten als an Ersatzlösungen.\n\n*Hinweis: Dieses Interview wurde aus Platzgründen und zur besseren Übersichtlichkeit bearbeitet.* \n\n## Erfahre mehr über Git\n\n- [Was gibt es Neues in Git 2.49.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-49-0/)  \n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n- [Der Anfängerleitfaden zum „reftable“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git-Projekt](https://git-scm.com/)",[9,682],"git","2025-04-28",{"slug":685,"featured":91,"template":686},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","BlogPost","content:de-de:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":692,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":696,"config":706,"_id":708,"_type":14,"title":709,"_source":16,"_file":710,"_stem":711,"_extension":19},"/de-de/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":694,"description":695,"ogTitle":694,"ogDescription":695},"Exact Code Search: Code blitzschnell in Repositories finden","So findet diese neue GitLab-Funktion exakte Treffer, nutzt Regex-Muster und zeigt kontextbezogene Ergebnisse in Terabyte-großen Codebasen an.",{"title":697,"description":695,"authors":698,"heroImage":700,"date":701,"body":702,"category":703,"tags":704},"Exact Code Search: So findet man Code blitzschnell über mehrere Repositories hinweg",[699],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-06-25","**Kurz gesagt:** Was wäre, wenn du jede Codezeile in 48 TB an Repositories\nin Millisekunden finden könntest? GitLabs neue [Exact Code\nSearch](https://docs.gitlab.com/ee/user/search/exact_code_search.html) macht\ngenau das möglich – mit präzisen Treffern, leistungsstarker\nRegex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die\nArbeit mit großen Codebasen revolutionieren.\n\n\n## Warum traditionelle Code-Suche herausfordernd ist\n\n\nJeder, der mit Code arbeitet, kennt die Frustration bei der Suche über Repositories hinweg. Egal ob du als Entwickler(in) einen Fehler debuggst, als DevOps-Ingenieur(in) Konfigurationen untersuchst, als Sicherheitsanalyst(in) nach Schwachstellen suchst, als technische(r) Redakteur(in) Dokumentationen aktualisierst oder als Manager(in) Implementierungen überprüfst – du weißt genau, was du brauchst, aber herkömmliche Suchwerkzeuge lassen dich oft im Stich.\n\n\nDiese konventionellen Tools liefern Dutzende von False Positives, bieten nicht den nötigen Kontext zum Verständnis der Ergebnisse und werden mit wachsenden Codebasen immer langsamer. Das Ergebnis? Wertvolle Zeit wird mit der Suche nach der Nadel im Heuhaufen verschwendet, anstatt Software zu entwickeln, zu sichern oder zu verbessern.\n\n\nGitLabs Code-Suchfunktion basierte bisher auf Elasticsearch oder OpenSearch. Diese eignen sich zwar hervorragend für die Suche in Issues, Merge Requests, Kommentaren und anderen Daten mit natürlicher Sprache, wurden aber nicht speziell für Code entwickelt. Nach der [Evaluierung zahlreicher Optionen](https://gitlab.com/groups/gitlab-org/-/epics/7404) haben wir eine bessere Lösung entwickelt.\n\n\n## Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen\n\n\nMit GitLabs **[Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html)**, derzeit in der Beta-Phase und angetrieben von [Zoekt](https://github.com/sourcegraph/zoekt) (ausgesprochen \"sukt\", niederländisch für \"sucht\"). Zoekt ist eine Open-Source-Code-Suchmaschine, die ursprünglich von Google entwickelt und jetzt von Sourcegraph gepflegt wird – speziell konzipiert für schnelle, präzise Code-Suche im großen Maßstab. Wir haben sie mit GitLab-spezifischen Integrationen, Verbesserungen für Unternehmensmaßstäbe und nahtloser Integration des Berechtigungssystems erweitert.\n\n\nDiese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:\n\n\n**1. Exact Match-Modus: Null False Positives**\n\n\nIm **Exact Match-Modus** liefert die Suchmaschine nur Ergebnisse, die exakt deiner Suchanfrage entsprechen, und eliminiert False Positives. Diese Präzision ist unbezahlbar beim:\n\n\n* Suchen nach spezifischen Fehlermeldungen\n\n* Finden bestimmter Funktionssignaturen\n\n* Aufspüren von Instanzen spezifischer Variablennamen\n\n\n**2. Regular Expression-Modus: Leistungsstarkes Pattern Matching**\n\n\nFür komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:\n\n\n* Finde Funktionen, die bestimmten Namensmustern folgen\n\n* Lokalisiere Variablen mit bestimmten Einschränkungen\n\n* Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching\n\n\n**3. Mehrzeilige Treffer: Code im Kontext sehen**\n\n\n![Exact Code Search](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\n\nStatt nur eine einzelne Zeile mit deinem Suchbegriff zu sehen, erhältst du den umgebenden Kontext, der für das Verständnis des Codes entscheidend ist. Das eliminiert die Notwendigkeit, für grundlegendes Verständnis in Dateien zu klicken, und beschleunigt deinen Workflow erheblich.\n\n\n## Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis\n\n\nSchauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:\n\n\n### Debugging: Von der Fehlermeldung zur Ursache in Sekunden\n\n\nVor Exact Code Search:\n\nEine Fehlermeldung kopieren, suchen, durch Dutzende von Teiltreffern in Kommentaren und Dokumentation waten, durch mehrere Dateien klicken und schließlich den tatsächlichen Code finden.\n\n\nMit Exact Code Search:\n\n\n1. Die exakte Fehlermeldung kopieren\n\n2. Sie in Exact Code Search im Exact Match-Modus einfügen\n\n3. Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext\n\n\n**Auswirkung:** Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.\n\n\n### Code-Exploration: Unbekannte Codebasen schnell meistern\n\n\nVor Exact Code Search:\n\nDurch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.\n\n\nMit Exact Code Search:\n\n\n* Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen\n\n* Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen\n\n* Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden\n\n\n**Auswirkung:** Baue eine mentale Karte der Code-Struktur in Minuten statt Stunden auf und beschleunige Onboarding und teamübergreifende Zusammenarbeit dramatisch.\n\n\n### Refactoring mit Zuversicht\n\n\nVor Exact Code Search:\n\nVersuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.\n\n\nMit Exact Code Search:\n\n\n* Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden\n\n* Kontext überprüfen, um Verwendungsmuster zu verstehen\n\n* Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen\n\n\n**Auswirkung:** Eliminiere die \"übersehene Instanz\"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.\n\n\n### Sicherheitsaudits: Verwundbare Muster finden\n\n\nSicherheitsteams können:\n\n\n* Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen\n\n* Über alle Repositories in einem Namespace suchen\n\n* Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft\n\n\n**Auswirkung:** Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.\n\n\n### Repository-übergreifende Einblicke\n\n\nSuche über deinen gesamten Namespace oder deine Instanz, um:\n\n\n* Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren\n\n* Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken\n\n\n**Auswirkung:** Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.\n\n\n## Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert\n\n\nBevor wir in unsere Skalierungserfolge eintauchen, lass uns erkunden, was Zoekt grundlegend von traditionellen Suchmaschinen unterscheidet – und warum es exakte Treffer so unglaublich schnell finden kann.\n\n\n### Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer\n\n\nZoekts Geschwindigkeit kommt von der Verwendung **positionaler Trigramme** – einer Technik, die jede Sequenz von drei Zeichen zusammen mit ihren exakten Positionen in Dateien indexiert. Dieser Ansatz löst einen der größten Schmerzpunkte, die Entwickler(innen) mit Elasticsearch-basierter Code-Suche hatten: False Positives.\n\n\nSo funktioniert es:\n\n\n**Traditionelle Volltextsuchmaschinen** wie Elasticsearch tokenisieren Code in Wörter und verlieren Positionsinformationen. Wenn du nach `getUserId()` suchst, könnten sie Ergebnisse liefern, die **user**, **get** und **Id** über eine Datei verteilt enthalten – was zu diesen frustrierenden False Positives für GitLab-Nutzer(innen) führt.\n\n\n**Zoekts positionale Trigramme** behalten exakte Zeichensequenzen und ihre Positionen bei. Wenn du nach `getUserId()` suchst, sucht Zoekt nach den exakten Trigrammen wie **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(**, **d()**, alle in der korrekten Reihenfolge und Position. Das stellt sicher, dass nur exakte Treffer zurückgegeben werden.\n\n\nDas Ergebnis? Suchanfragen, die zuvor Hunderte irrelevanter Ergebnisse lieferten, liefern jetzt nur noch die präzisen Treffer, nach denen du suchst. Das war [eine unserer meistgewünschten Funktionen](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) aus gutem Grund – Entwickler(innen) verloren erhebliche Zeit beim Durchsuchen von False Positives.\n\n\n### Regular Expression-Performance im großen Maßstab\n\n\nZoekt glänzt bei exakten Treffern und ist für Regular Expression-Suchen optimiert. Die Engine nutzt ausgefeilte Algorithmen, um Regex-Muster wenn möglich in effiziente Trigramm-Abfragen umzuwandeln und behält die Geschwindigkeit selbst bei komplexen Mustern über Terabytes von Code bei.\n\n\n## Entwickelt für Unternehmensmaßstäbe\n\n\nExact Code Search ist leistungsstark und für massive Skalierung mit beeindruckender Performance gebaut. Das ist nicht nur eine neue UI-Funktion – sie wird von einer komplett neu konzipierten Backend-Architektur angetrieben.\n\n\n### Terabytes von Code mit Leichtigkeit bewältigen\n\n\nAllein auf GitLab.com indexiert und durchsucht unsere Exact Code Search-Infrastruktur über **48 TB** an Code-Daten bei gleichzeitig blitzschnellen Antwortzeiten. Diese Größenordnung repräsentiert Millionen von Repositories über Tausende von Namespaces, alle innerhalb von Millisekunden durchsuchbar. Um das in Perspektive zu setzen: Diese Größenordnung repräsentiert mehr Code als die gesamten Linux-Kernel-, Android- und Chromium-Projekte zusammen. Dennoch kann Exact Code Search eine spezifische Zeile in dieser massiven Codebasis in Millisekunden finden.\n\n\n### Selbstregistrierende Node-Architektur\n\n\nUnsere innovative Implementierung bietet:\n\n\n* **Automatische Node-Registrierung:** Zoekt-Nodes registrieren sich selbst bei GitLab\n\n* **Dynamische Shard-Zuweisung:** Das System weist Namespaces automatisch Nodes zu\n\n* **Gesundheitsüberwachung:** Nodes, die sich nicht melden, werden automatisch als offline markiert\n\n\nDiese selbstkonfigurierende Architektur vereinfacht die Skalierung dramatisch. Wenn mehr Kapazität benötigt wird, können Administratoren einfach weitere Nodes hinzufügen, ohne komplexe Neukonfiguration.\n\n\n### Verteiltes System mit intelligentem Load Balancing\n\n\nHinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:\n\n\n* **Spezialisierte Such-Nodes:** Zweckgebundene Server, die Indexierung und Suche übernehmen\n\n* **Intelligentes Sharding:** Code wird basierend auf Namespaces über Nodes verteilt\n\n* **Automatisches Load Balancing:** Das System verteilt Arbeit intelligent basierend auf Kapazität\n\n* **Hohe Verfügbarkeit:** Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen\n\n\n*Hinweis: Hohe Verfügbarkeit ist in die Architektur integriert, aber noch nicht vollständig aktiviert. Siehe [Issue 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) für Updates.*\n\n\n### Nahtlose Sicherheitsintegration\n\n\nExact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:\n\n\n* Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert\n\n* Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt\n\n* Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt\n\n\n### Optimierte Performance\n\n\n* **Effiziente Indexierung:** Große Repositories werden in Dutzenden von Sekunden indexiert\n\n* **Schnelle Query-Ausführung:** Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde\n\n* **Streaming-Ergebnisse:** Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden\n\n* **Frühzeitiger Abbruch:** Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche\n\n\n## Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben\n\n\nWährend Zoekt die Kern-Suchtechnologie bereitstellte, war es ursprünglich als minimale Bibliothek zur Verwaltung von `.zoekt`-Indexdateien konzipiert – nicht als verteilte Datenbank oder Unternehmens-Service. Hier sind die wichtigsten technischen Herausforderungen, die wir überwunden haben, um es in GitLabs Maßstab zum Laufen zu bringen:\n\n\n### Herausforderung 1: Aufbau einer Orchestrierungsschicht\n\n\n**Das Problem:** Zoekt war für die Arbeit mit lokalen Indexdateien konzipiert, nicht für die Verteilung über mehrere Nodes, die viele gleichzeitige Nutzer bedienen.\n\n\n**Unsere Lösung:** Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:\n\n\n* Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen\n\n* Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)\n\n* Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt\n\n* Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt\n\n\n### Herausforderung 2: Skalierung von Speicher und Indexierung\n\n\n**Das Problem:** Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?\n\n\n**Unsere Lösung:** Wir implementierten:\n\n\n* Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt\n\n* Unabhängige Replikation: Jeder Node indexiert unabhängig von [Gitaly](https://gitlab.com/gitlab-org/gitaly) (unserem Git-Speicherdienst), wodurch komplexe Synchronisation eliminiert wird\n\n* Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht\n\n* Einheitliche Binary-Architektur: Ein einzelnes `gitlab-zoekt`-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann\n\n\n### Herausforderung 3: Berechtigungsintegration\n\n\n**Das Problem:** Zoekt hatte kein Konzept von GitLabs komplexem Berechtigungssystem – Nutzer sollten nur Ergebnisse aus Projekten sehen, auf die sie Zugriff haben.\n\n\n**Unsere Lösung:** Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:\n\n\n* Suchanfragen enthalten Nutzerberechtigungskontext\n\n* Ergebnisse werden gefiltert, um nur die anzuzeigen, auf die der Nutzer zugreifen kann, falls sich Berechtigungen ändern, bevor die Indexierung abgeschlossen ist\n\n\n### Herausforderung 4: Betriebliche Einfachheit\n\n\n**Das Problem:** Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.\n\n\n**Unsere Lösung:**\n\n\n* Auto-Scaling: Das Hinzufügen von Kapazität ist so einfach wie das Bereitstellen weiterer Nodes – sie registrieren sich automatisch und beginnen mit der Arbeit\n\n* Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt\n\n* Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen\n\n\n## Schrittweiser Rollout: Risikominimierung im großen Maßstab\n\n\nDer Rollout eines komplett neuen Such-Backends für Millionen von Nutzern erforderte sorgfältige Planung. So haben wir die Auswirkungen auf Kunden minimiert und gleichzeitig Zuverlässigkeit sichergestellt:\n\n\n### Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)\n\n\nWir begannen damit, Exact Code Search nur für die `gitlab-org`-Gruppe zu aktivieren – unsere eigenen internen Repositories. Das ermöglichte uns:\n\n\n* Das System mit echten Produktions-Workloads zu testen\n\n* Performance-Engpässe zu identifizieren und zu beheben\n\n* Den Bereitstellungsprozess zu optimieren\n\n* Aus den Workflows und dem Feedback echter Nutzer zu lernen\n\n\n### Phase 2: Performance-Validierung und -Optimierung\n\n\nVor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:\n\n\n* Umfassendes Monitoring und Alerting implementiert\n\n* Speicherverwaltung mit echtem Produktionsdatenwachstum validiert\n\n\n### Phase 3: Schrittweise Kundenerweiterung\n\n\nWir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:\n\n\n* Feedback zu Performance und Benutzererfahrung gesammelt\n\n* Die Such-UI basierend auf echten Nutzer-Workflows verfeinert\n\n* Indexierungs-Performance optimiert (große Repositories wie `gitlab-org/gitlab` indexieren jetzt in ~10 Sekunden)\n\n* Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert\n\n* Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert\n\n\n### Phase 4: Breiter Rollout\n\n\nHeute haben über 99 % der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:\n\n\n* Zwischen Regex- und exaktem Suchmodus umschalten\n\n* Die Vorteile ohne Konfigurationsänderungen erleben\n\n* Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)\n\n\nDer schrittweise Rollout bedeutete, dass Nutzer keine Service-Unterbrechungen, Performance-Verschlechterungen oder Feature-Lücken während des Übergangs erlebten. Wir haben bereits positives Feedback von Nutzern erhalten, die bemerken, dass ihre Ergebnisse relevanter und schneller werden.\n\n\n> **Für technische Details:** Interessiert an der detaillierten Architektur und Implementierung? Schau dir unser umfassendes [Design-Dokument](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) für ausführliche technische Details an, wie wir dieses verteilte Suchsystem gebaut haben.\n\n\n## Erste Schritte mit Exact Code Search\n\n\nDer Einstieg in Exact Code Search ist einfach, da es bereits standardmäßig für Premium- und Ultimate-Gruppen auf GitLab.com aktiviert ist (über 99 % der berechtigten Gruppen haben derzeit Zugriff).\n\n\n### Schnellstart-Anleitung\n\n\n1. Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe\n\n2. Gib deinen Suchbegriff im Code-Tab ein\n\n3. Wechsle zwischen Exact Match- und Regular Expression-Modus\n\n4. Nutze Filter, um deine Suche zu verfeinern\n\n\n### Grundlegende Such-Syntax\n\n\nEgal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:\n\n\n| Abfrage-Beispiel | Was es bewirkt                                              |\n\n| ---------------- | ----------------------------------------------------------- |\n\n| `file:js`        | Sucht nur in Dateien, die \"js\" im Namen enthalten           |\n\n| `foo -bar`       | Findet \"foo\", schließt aber Ergebnisse mit \"bar\" aus        |\n\n| `lang:ruby`      | Sucht nur in Ruby-Dateien                                   |\n\n| `sym:process`    | Findet \"process\" in Symbolen (Methoden, Klassen, Variablen) |\n\n\n> **Profi-Tipp:** Für die effizientesten Suchen beginne spezifisch und erweitere dann bei Bedarf. Die Verwendung von `file:`- und `lang:`-Filtern erhöht die Relevanz dramatisch.\n\n\n### Erweiterte Suchtechniken\n\n\nStapele mehrere Filter für Präzision:\n\n\n```\n\nis_expected file:rb -file:spec\n\n```\n\n\nDas findet \"is_expected\" in Ruby-Dateien, die nicht \"spec\" im Namen haben.\n\n\nNutze reguläre Ausdrücke für leistungsstarke Muster:\n\n\n```\n\ntoken.*=.*[\\\"']\n\n```\n\n\n[Sieh dir diese Suche im GitLab Zoekt Repository an.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\n\nDie Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.\n\n\nFür detailliertere Syntax-Informationen, schau in die [Exact Code Search-Dokumentation](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n\n## Verfügbarkeit und Bereitstellung\n\n\n### Aktuelle Verfügbarkeit\n\n\nExact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:\n\n\n* Verfügbar für über 99 % der lizenzierten Gruppen\n\n* Die Suche in der UI nutzt automatisch Zoekt, wenn verfügbar, Exact Code Search in der Such-API ist hinter einem Feature-Flag\n\n\n### Bereitstellungsoptionen für Self-Managed\n\n\nFür Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:\n\n\n* Kubernetes/Helm: Unsere am besten unterstützte Methode, mit unserem [`gitlab-zoekt` Helm Chart](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt)\n\n* Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden\n\n\nDie Systemanforderungen hängen von deiner Codebasis-Größe ab, aber die Architektur ist darauf ausgelegt, horizontal und/oder vertikal zu skalieren, wenn deine Anforderungen wachsen.\n\n\n## Was als Nächstes kommt\n\n\nWährend Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:\n\n\n* **Skalierungsoptimierungen** zur Unterstützung von Instanzen mit Hunderttausenden von Repositories\n\n* **Verbesserte Self-Managed-Bereitstellungsoptionen**, einschließlich vereinfachter Omnibus-Unterstützung\n\n* **Vollständige Hochverfügbarkeits-Unterstützung** mit automatischem Failover und Load Balancing\n\n\nBleib dran für Updates, während wir von Beta zu General Availability übergehen.\n\n\n## Transformiere deine Arbeitsweise mit Code\n\n\nGitLabs Exact Code Search repräsentiert ein grundlegendes Umdenken bei der Code-Entdeckung. Durch die Bereitstellung exakter Treffer, leistungsstarker Regex-Unterstützung und kontextbezogener Ergebnisse löst sie die frustrierendsten Aspekte der Code-Suche:\n\n\n* Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen\n\n* Keine wichtigen Treffer mehr verpassen\n\n* Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis\n\n* Keine Performance-Probleme mehr bei wachsenden Codebasen\n\n\nDie Auswirkungen gehen über die individuelle Produktivität hinaus:\n\n\n* **Teams arbeiten besser zusammen** mit einfacher Code-Referenzierung\n\n* **Wissensaustausch beschleunigt sich**, wenn Muster auffindbar sind\n\n* **Onboarding wird schneller** mit schnellem Codebasis-Verständnis\n\n* **Sicherheit verbessert sich** mit effektivem Muster-Auditing\n\n* **Abbau technischer Schulden** wird machbarer\n\n\nExact Code Search ist nicht nur eine Funktion, es ist eine bessere Art, Code zu verstehen und damit zu arbeiten. Hör auf zu suchen und fang an zu finden.\n\n\n**Wir würden gerne von dir hören!** Teile deine Erfahrungen, Fragen oder Feedback zu Exact Code Search in unserem [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Dein Input hilft uns, Verbesserungen und neue Funktionen zu priorisieren.\n\n\n> ### Bereit für smartere Code-Suche? Erfahre mehr in unserer [Dokumentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) oder probiere es jetzt aus, indem du eine Suche in deinen Premium- oder Ultimate-lizenzierten Namespaces oder Projekten durchführst. Noch kein GitLab-Nutzer? Teste [kostenlos GitLab Ultimate mit Duo](https://about.gitlab.com/free-trial/)!\n","product",[703,705,9],"tutorial",{"featured":6,"template":686,"slug":707},"exact-code-search-find-code-faster-across-repositories","content:de-de:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","de-de/blog/exact-code-search-find-code-faster-across-repositories.yml","de-de/blog/exact-code-search-find-code-faster-across-repositories",{"_path":713,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":721,"config":730,"_id":732,"_type":14,"title":733,"_source":16,"_file":734,"_stem":735,"_extension":19},"/de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"ogTitle":715,"schema":716,"ogImage":717,"ogDescription":718,"ogSiteName":719,"noIndex":6,"ogType":674,"ogUrl":720,"title":715,"canonicalUrls":720,"description":718},"Git Pull vs. Git Fetch: Unterschiede & Anwendung erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git fetch vs. git pull: Das ist der Unterschied!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-09-24\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","Git Pull kombiniert fetch + merge in einem Befehl. Erfahre die Unterschiede zu Git Fetch, wann du welchen Command nutzt und vermeide typische Fehler.","https://about.gitlab.com/de-de","https://about.gitlab.com/de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"heroImage":717,"body":722,"authors":723,"updatedDate":725,"date":726,"title":727,"tags":728,"description":729,"category":10},"Der Git-Befehl ist als [verteiltes\nVersionskontrollsystem](https://about.gitlab.com/de-de/topics/version-control/benefits-distributed-version-control-system/)\nsehr beliebt und wird verwendet, wenn eine Synchronisation mit einem\nRemote-Repository erforderlich ist. \n\n\nEntwickler(innen) müssen die geeigneten Befehle basierend auf den Anforderungen des Projekts auswählen. In diesem Artikel erklären wir die Grundlagen und Unterschiede zwischen git fetch und git pull und geben eine detaillierte Erläuterung ihrer jeweiligen Anwendungsfälle.\n\n\n**In diesem Artikel lernst du:**\n\n\n* Wann du `git pull` vs. `git fetch` verwendest\n\n* Wie du Konflikte vermeidest (und löst, wenn sie auftreten)  \n\n* Welche Fallstricke es gibt und wie du sie umgehst\n\n\n## Inhaltsverzeichnis - git fetch vs. git pull: Das ist der Unterschied!\n\n\n* [Worum geht es bei git pull?](#worum-geht-es-bei-git-pull)\n\n* [Was ist git fetch?](#was-ist-git-fetch)\n\n* [git pull - Daten aktualisieren](#git-pull---daten-aktualisieren)\n\n* [git pull - Mehr als nur ein Befehl](#git-pull---mehr-als-nur-ein-befehl)\n\n* [git pull vs git fetch - Wann benutze ich welchen Befehl?](#git-pull-vs-git-fetch---wann-benutze-ich-welchen-befehl)\n\n* [git pull - Die Basis für kollaboratives Arbeiten](#git-pull---die-basis-für-kollaboratives-arbeiten)\n\n* [git fetch und git pull FAQs](#git-fetch-und-git-pull-faqs)\n\n  * [Wie oft sollte ich den Pull-Befehl ausführen?](#wie-oft-sollte-ich-den-pull-befehl-ausführen)\n  * [Was ist mit Autofetch oder Autopull?](#was-ist-mit-autofetch-oder-autopull)\n  * [Was passiert bei Problemen mit git pull?](#was-passiert-bei-problemen-mit-git-pull)\n  * [Ist git pull riskant?](#ist-git-pull-riskant)\n\n## Worum geht es bei git pull?\n\n\nGit pull nimmt eine essenzielle Rolle in der Versionskontrolle ein. Git ist ein Tool, das Entwicklerteams im Rahmen von DevSecOps dabei unterstützt, sowohl zeitgleich als auch zeitversetzt an einem Softwareprojekt zu arbeiten. Git sorgt unter anderem dafür, dass alle stets mit der aktuellen und korrekten Version arbeiten und jede Änderung für alle sichtbar ist. Dieser aktuelle Stand des Projekts wird in dem sogenannten zentralen Remote Repository festgehalten. \n\n\nEin Git-Repository ist deine Projektverwaltung. Es enthält nicht nur deine aktuellen Dateien, sondern die komplette Historie aller Änderungen. Stell es dir wie ein intelligentes Backup-System vor: Jeder 'Commit' ist ein Schnappschuss deines Projekts zu einem bestimmten Zeitpunkt. Das Repository speichert all diese Schnappschüsse effizient und ermöglicht dir, jederzeit zu früheren Versionen zurückzukehren.\n\n\nMitarbeiter(innen) können somit offline arbeiten und Änderungen in ihrem lokalen Repository und lokalen Arbeitsverzeichnis speichern. Sobald sie die Änderungen auf das Remote Repository übertragen, werden diese auch für alle anderen erkennbar.\n\n\nSo sorgt git für eine ständige Aktualisierung, sodass alle jederzeit mit den neuesten Daten arbeiten. Git pull ist der Schlüssel dazu, diese Versionskontrolle in die Praxis umzusetzen. \n\n\n## Was ist git fetch?\n\n\nDer Befehl git fetch ruft die neueste Commit-Historie aus dem Remote-Repository ab, beeinflusst aber nicht das lokale Arbeitsverzeichnis. Selbst nach dem Abrufen der Remote-Änderungen werden diese nicht im lokalen Branch übernommen. Er wird hauptsächlich verwendet, wenn Sie den neuesten Stand aus dem Remote-Repository abrufen und die Änderungen überprüfen möchten, bevor sie im lokalen Repository übernommen werden. Um die abgerufenen Änderungen auf den lokalen Branch anzuwenden, müssen Sie manuell git merge oder [git rebase](https://docs.gitlab.com/topics/git/git_rebase/) ausführen.\n\n\n## git pull - Daten aktualisieren\n\n\nWillst du dich als Entwickler(in) zu Beginn deiner Arbeit auf den neuesten Stand bringen? Dann wirst du wissen wollen, welche Änderungen seit deinem letzten Login vorgenommen wurden. \n\n\nDazu muss erwähnt werden, dass nicht alle Änderungen übernommen werden. Jedes Teammitglied nutzt den git-push-Befehl, um seine Änderungen ins Remote Repository hochzuladen. Diese landen meist in Feature-Branches. Teamleiter(innen) prüfen diese Änderungen und führen sie über Merge Requests in den Hauptbranch (main/master) zusammen. Mit git pull holst du dir dann die aktuellste Version dieses Hauptbranches auf deinen Rechner. \n\n\nDie einfachste Möglichkeit, die als „true” gekennzeichnete Version zu erhalten, besteht darin, diese Änderungen auf deinen Arbeitsplatz zu ziehen und dann auf dieser Basis weiterzuarbeiten. \n\nGenau diese Aufgabe übernimmt git pull. Es aktualisiert dein lokales Repository sowie deine projektbezogenen Dateien und sorgt somit dafür, dass du genau dort ansetzt, wo sich das Projekt gerade befindet. Das Fachmagazin Chip  bringt es auf den Punkt:\n\n„Den Pull-Befehl benötigen Sie im täglichen git-Workflow, um das lokale Repository mit den neuesten Änderungen zu aktualisieren.”\n\n\n## git pull - Mehr als nur ein Befehl\n\n\ngit pull ist mehr als nur ein Befehl. Und diese Aussage kannst du wörtlich nehmen. \n\nDenn obwohl du nur einen einzigen Command anwendest, passieren bei pull stets zwei Aktionen auf einmal. Es handelt sich hierbei um einen zusammengesetzten Befehl, der git fetch und git merge miteinander kombiniert und nacheinander ausführt:\n\n\ngit fetch zieht als erstes die aktuellen Daten aus dem Remote Repository in dein lokales Repository. Damit kannst du sehen, woran deine Kolleg(inn)en gearbeitet haben und welche Änderungen vorgenommen wurden. Noch aber werden diese Änderungen auf deinem Rechner nicht umgesetzt. \n\n\ngit merge übernimmt anschließend die Aktualisierung deines gesamten Projekts und bringt es auf den Stand des Remote Repository. Alles, was sich in deinem Arbeitsverzeichnis befindet, wird ebenfalls angepasst.\n\n\nFür viele git-Nutzer ist git pull eine tägliche Routine. Doch obwohl der Unterschied zwischen git fetch und git pull sehr fein ist, legen manche großen Wert darauf, die beiden Einzel-Commands fetch und merge stets getrennt zu nutzen. Warum eigentlich? Oder, um die Frage anders zu formulieren: \n\n\n## git pull vs git fetch - Wann benutze ich welchen Befehl?\n\n\nIn aller Regel wirst du als Entwickler(in) mit dem neuesten Stand des Projekts arbeiten wollen. Dazu müssen sowohl dein Repository als auch deine lokalen Daten in Einklang mit den als „true” gekennzeichneten Daten gebracht werden. Der Unterschied zwischen git fetch und git pull besteht darin, wie diese Aktualisierung erfolgt. \n\n\ngit pull ist die schnellste Methode, dieses Ziel umzusetzen. Hier ein praktisches Beispiel:\n\n\n```bash\n\n# Aktuelle Änderungen vom main-Branch holen und direkt anwenden\n\ngit pull origin main\n\n\n# Was im Hintergrund passiert:\n\ngit fetch origin main  # Änderungen herunterladen\n\ngit merge origin/main  # Änderungen in deinen Branch einarbeiten\n\n```\n\n\nMit diesem einen Befehl vermeidest du sowohl überflüssige Arbeitsschritte als auch Fehler, die daraus resultieren können, dass du mit einer nicht mehr aktuellen Version der Software arbeitest. Du arbeitest damit immer mit der neuesten Version und reduzierst das Risiko von Konflikten mit den Änderungen deiner Teamkollegen.\n\n\nZwar ist eine Fehlerkontrolle auch mit git pull noch möglich, doch jegliche Korrekturen inhaltlicher Natur können von dir nicht mehr hinterfragt werden.\n\nIndem du zuerst git fetch durchführst und erst später den merge (die “Verschmelzung”), kannst du noch weiterhin die Daten deines lokalen Working Directories nutzen und editieren. Erst nachdem du den git-merge-Befehl erteilst, vollziehst du die Umsetzung des neuen Stands. \n\n\n## git pull - Die Basis für kollaboratives Arbeiten\n\n\nDoch unabhängig davon, ob du git pull nutzt oder eine getrennte Ausführung von fetch und merge bevorzugst, bleibt die Bedeutung der damit verbundenen Aktionen unbestritten.\n\n\nGit pull ist die Basis für die zentrale Funktionalität von git: Ein fehlerfreies Arbeiten vieler Teammitglieder an einem geteilten Projekt, bei dem jede(r), unabhängig von Wohnsitz, Zeitzone und Rolle in dem Projekt stets an derselben Version des Produkts arbeitet. \n\n\nAlleine schon deswegen verdient der Command seine Einschätzung als einer der wichtigsten Befehle in git überhaupt. \n\n\n## git fetch und git pull FAQs\n\n\n### Wie oft sollte ich den Pull-Befehl ausführen?\n\n\nDies ist eine wichtige praktische Frage für viele Entwickler(innen). Allerdings gibt es keine Antwort, die Allgemeingültigkeit besitzt. Wenn du solo an einem Projekt arbeitest - beispielsweise alleine an einer lokalen Branch des Projekts - besteht keine Notwendigkeit, ständig einen pull durchzuführen. Du erfüllst schlicht deine Aufgabe und überträgst diese mit einem git-pull-Befehl ins Remote Repository. \n\n\nAnders sieht es aus, wenn du in einem kleinen Team am selben Teil (derselben lokalen Branch) des Produkts arbeitest. Hier kann es in der Praxis am einfachsten und effektivsten sein, wenn jede(r) die anderen kurz benachrichtigt, wenn eine Änderung durchgeführt wurde. Wenn alle Teammitglieder für sich einen pull durchführen, sind alle wieder auf dem neuesten Stand.\n\n\nIn größeren Teams ist diese Art der direkten Kommunikation nicht mehr effizient. Hier hängt eine Menge davon ab, wie schnell in der Regel Projekte umgesetzt oder Änderungen freigegeben werden. Je nachdem kann es sinnvoll sein, nur einmal oder mehrfach am Tag zu “pullen”. Eine andere logische Idee besteht darin, vor Beginn und nach Ende der eigenen Arbeit die Aktualisierung zu starten. \n\n\n### Was ist mit Autofetch oder Autopull?\n\n\nWenn eine der Kernfunktionen von git darin besteht, stets die aktuelle Version der Anwendung auf jedem Arbeitsplatz bereit zu stellen, wäre es dann nicht sinnvoll, wenn das System diese Updates regelmäßig selbst durchführt? Oder sogar immer dann, wenn eine neue Version als „true” gekennzeichnet wird? \n\n\nWir meinen, dass Autopull eher problematisch ist. Während du an deiner aktuellen Aufgabe arbeitest, kann es zu Konflikten mit den neuen Daten kommen. Es kann auch deinen Arbeitsfluss unterbrechen. Bei einem Autofetch wäre immerhin garantiert, dass nur das Repository angepasst wird und du noch immer Einsicht in die Änderungen hast, ehe sie auch lokal umgesetzt werden. Hier ist fraglich, ob es nicht trotzdem sinnvoll ist, den fetch nur durchzuführen, wenn du nicht an etwas anderem arbeitest und dich der Einsicht, beziehungsweise der Kontrolle widmen kannst. \n\nEs gibt durchaus Entwickler(innen), die ein automatisiertes pull oder fetch für sinnvoll halten und es gewinnbringend nutzen. Die meisten aber fühlen sich sicherer damit, die Befehle aktiv und bewusst zu verwenden.\n\n\n### Was passiert bei Problemen mit git pull?\n\n\nWie angedeutet, kann es zu Konflikten zwischen den Daten in dem Working Directory auf dem zentralen Server und deinem lokalen Directory kommen. In diesem Fall kann der pull-Befehl nicht ordnungsgemäß durchgeführt werden. Zum Glück ist das kein schwerwiegendes Problem. \n\n\nWas in diesem Fall passiert, ist schlicht, dass der pull-Command in einen fetch-Befehl umgewandelt wird. Das bedeutet, git gewährt dir Einblick in die Änderungen, die vorgenommen wurden und zeigt die Konflikte auf. Du kannst nun anschließend selbst die Fehler beseitigen (beziehungsweise Konflikte auflösen) und dann den merge umsetzen. \n\n\n### Ist git pull riskant?\n\n\nEs wird immer wieder von erfahrenen Entwickler(inne)n darauf hingewiesen, dass git pull nicht optimal ist. Aus ihrer Sicht gibt es eine Vielzahl universeller Schwierigkeiten mit diesem Command.\n\n\nEinige dieser Aspekte haben wir bereits aufgegriffen. Andere sind sehr spezifisch und beziehen sich darauf, wie pull die Repositories verändert. Eine gute Übersicht bietet diese Diskussion auf Stackoverflow (auf Englisch), die auf die Probleme detailliert eingeht. \n\n\nFür Anfänger(innen) ist es gewiss eine bessere Lernerfahrung, den Begriff in seine beiden Einzelkomponenten aufzuteilen, um genau zu erkennen, was genau sich durch die beiden Befehle, aus denen git pull eigentlich besteht, ändert. Profis andererseits mögen für ihre Bedürfnisse bessere Alternativen haben.\n\n\nAllgemein aber verwenden tausende Programmierer(innen) den pull-Command jeden Tag zu voller Zufriedenheit. Es gibt somit keinen Grund, ihn generell zu verteufeln oder von seiner Nutzung abzuraten.\n\n\n## Mehr erfahren\n\n\n* [Was ist neu in Git 2.46](https://about.gitlab.com/de-de/blog/what-s-new-in-git-2-50-0/)\n\n* [Git lernen](https://docs.gitlab.com/ee/topics/git/)\n\n* [Mehr über GitLab Gitaly erfahren](https://docs.gitlab.com/ee/administration/gitaly/)\n",[724],"GitLab","2025-07-28","2024-09-24","git pull vs. git fetch: Die Unterschiede erklärt",[682,9],"Ein Befehl, zwei Aktionen: Was git pull wirklich macht und wann git fetch die bessere Wahl ist.",{"slug":731,"featured":6,"template":686},"git-pull-vs-git-fetch-whats-the-difference","content:de-de:blog:git-pull-vs-git-fetch-whats-the-difference.yml","Git Pull Vs Git Fetch Whats The Difference","de-de/blog/git-pull-vs-git-fetch-whats-the-difference.yml","de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"_path":737,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":738,"content":744,"config":752,"_id":754,"_type":14,"title":755,"_source":16,"_file":756,"_stem":757,"_extension":19},"/de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":739,"description":740,"ogTitle":739,"ogDescription":740,"noIndex":6,"ogImage":741,"ogUrl":742,"ogSiteName":673,"ogType":674,"canonicalUrls":742,"schema":743},"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung","Die Vorteile der Verwendung von OCI-Images als Teil von GitOps-Workflows und die vielen Funktionen, die GitLab bietet, um die Bereitstellung in Kubernetes zu vereinfachen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":739,"description":740,"authors":745,"heroImage":741,"date":747,"body":748,"category":10,"tags":749,"updatedDate":751},[746],"Daniel Helfand","2025-02-19","Ist [GitOps](https://about.gitlab.com/de-de/topics/gitops/) immer noch GitOps, wenn du kein Git-Repository als Artefakt für die Bereitstellung verwendest? Git bleibt zwar weiterhin von zentraler Bedeutung für GitOps-Workflows, doch die Speicherung von Infrastrukturdefinitionen als OCI-Artefakte (Open Container Initiative) in Container-Registries hat als Quelle für GitOps-Bereitstellungen an Beliebtheit gewonnen. In diesem Artikel werden wir uns eingehender mit den Ideen hinter diesem Trend befassen und erläutern, wie GitLab-Funktionen diese Verbesserung der GitOps-Workflows unterstützen.\n\n## Was ist GitOps?\n\nDas [OpenGitOps](https://opengitops.dev/)-Projekt hat [vier Prinzipien](https://opengitops.dev/#principles) für den Einsatz von GitOps definiert (Informationen zu OpenGitOps sind nur in englischer Sprache verfügbar):\n- Der gewünschte Zustand eines [Systems, das mit GitOps verwaltet wird](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system), muss [deklarativ ausgedrückt](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description) werden.\n- Der gewünschte Zustand wird so gespeichert, dass Unveränderlichkeit und Versionsverwaltung erzwungen werden und ein vollständiger Versionsverlauf erhalten bleibt.\n- Software-Agents rufen automatisch den gewünschten Zustand aus der Quelle ab.\n- Software-Agents überwachen [kontinuierlich](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) den tatsächlichen Systemzustand und [versuchen, den gewünschten Zustand anzuwenden](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nEin Beispiel für GitOps ist das Speichern der Kubernetes-Manifeste für einen Microservice in einem GitLab-Projekt. Diese Kubernetes-Ressourcen werden dann kontinuierlich von einem [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) abgeglichen, der auf dem Kubernetes-Cluster ausgeführt wird, auf dem der Microservice bereitgestellt ist. So können Entwickler(innen) die Infrastruktur mit denselben Workflows verwalten wie bei ihrer Arbeit mit regulärem Code, z. B. durch das Erstellen von Merge Requests, um Änderungen vorzunehmen und zu überprüfen, und durch die Versionsverwaltung von Änderungen. GitOps hat auch betriebliche Vorteile, wie z. B. die [Verhinderung von Konfigurationsdrift](https://about.gitlab.com/de-de/topics/gitops/#cicd) und es hilft Entwickler(inne)n bei der Prüfung, welche Änderungen bei der Bereitstellung zu bestimmten Ergebnissen geführt haben.\n\n## Vorteile und Einschränkungen von Git in GitOps-Workflows\n\nGit ist zwar ein wesentlicher Bestandteil von GitOps-Workflows, aber Git-Repositories wurden nicht für die Bereitstellung durch GitOps-Controller entwickelt. Entwickler(innen) können dank Git bei Infrastrukturänderungen zusammenarbeiten und diese Änderungen später überprüfen. Controller müssen jedoch nicht das gesamte Git-Repository herunterladen, um eine erfolgreiche Bereitstellung zu gewährleisten. GitOps-Controller benötigen lediglich die Infrastruktur, die für eine bestimmte Umgebung definiert ist. \n\nDarüber hinaus ist ein wichtiger Bestandteil des Bereitstellungsprozesses das [Signieren und Verifizieren von Bereitstellungen](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing), um sicherzustellen, dass Bereitstellungsänderungen an einer Umgebung aus einer vertrauenswürdigen Quelle stammen. Git-Commits können zwar von GitOps-Controllern signiert und verifiziert werden, aber Commits können auch andere Details erfassen, die nicht mit der Bereitstellung selbst zusammenhängen (z. B. Dokumentationsänderungen, Aktualisierungen anderer Umgebungen und Umstrukturierungen des Git-Repositorys), oder nicht genug vom Bereitstellungsbild, da eine Bereitstellung aus mehreren Commits bestehen kann. Auch hier scheint es sich um einen Fall zu handeln, für den diese Git-Funktion nicht entwickelt wurde.  \n\nEin weiterer herausfordernder Aspekt von Git in GitOps-Workflows ist, dass es manchmal zu mehr Automatisierung als erwartet führen kann. Kurz nach der Zusammenführung wird eine Änderung am beobachteten Branch vorgenommen und dann bereitgestellt. Außerhalb von Git gibt es keine Kontrollen im Prozess. Wie kannst du sicherstellen, dass an einem Freitagnachmittag nichts bereitgestellt wird? Was ist, wenn die für die Bereitstellung verantwortlichen Teams nicht berechtigt sind, in bestimmten GitLab-Projekten Änderungen zusammenzuführen? Durch die Verwendung von OCI-Images wird eine Pipeline in den Prozess eingefügt, die alle Funktionen zur Bereitstellungsteuerung umfasst, wie z. B. [Approvals oder Bereitstellungsstopps (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## OCI-Images\n\nDie [Open Container Initiative](https://opencontainers.org/) hat dazu beigetragen, Standards für Containerformate zu definieren. Während die meisten Entwickler(innen) mit dem Einbinden von Dockerfiles in Container-Images vertraut sind, sind viele möglicherweise nicht so erfahren im Speichern von Kubernetes-Manifesten in einer Container-Registry. Da die [Container-Registry von GitLab (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/packages/container_registry/) OCI-konform ist, können Benutzer(innen) Kubernetes-Manifeste für eine bestimmte Umgebung in eine Container-Registry übertragen. GitOps-Controller, wie z. B. [Flux CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), können die in diesem OCI-Artefakt gespeicherten Manifeste verwenden, anstatt ein ganzes Git-Repository klonen zu müssen. \n\nIn GitOps-Workflows kann ein Git-Repository oft die Infrastrukturdefinitionen für alle Umgebungen enthalten, in denen ein Microservice bereitgestellt wird. Indem die Kubernetes-Manifeste nur für eine bestimmte Umgebung paketiert werden, muss Flux CD nur genau die Dateien herunterladen, die für die Bereitstellung in einer bestimmten Umgebung erforderlich sind. \n\n### Sicherheitsvorteile der Verwendung von OCI-Artefakten\n\nWie bereits erwähnt, bietet das Signieren und Verifizieren der Artefakte, die in einer Umgebung bereitgestellt werden sollen, eine zusätzliche Sicherheitsebene für Softwareprojekte. Nachdem Kubernetes-Manifeste an eine Container-Registry gepusht wurden, kann ein Tool wie [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) verwendet werden, um das OCI-Image mit einem privaten Schlüssel zu signieren, der sicher in einem GitLab-Projekt als [CI/CD-Variable (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/variables/) gespeichert werden kann. Flux CD kann dann einen öffentlichen Schlüssel verwenden, der auf einem Kubernetes-Cluster gespeichert ist, um zu überprüfen, ob eine Bereitstellung von einer vertrauenswürdigen Quelle stammt. \n\n## Verwenden von GitLab zum Pushen und Signieren von OCI-Images \n\nGitLab bietet viele Funktionen, die den Prozess des Paketierens, Signierens und der Bereitstellung von OCI-Images vereinfachen. Eine gängige Methode zur Strukturierung von GitLab-Projekten mit GitOps-Workflows besteht darin, separate GitLab-Projekte für den Code der Microservices und ein einziges Infrastruktur-Repository für alle Microservices zu verwenden. Wenn eine Anwendung aus `n`-Microservices besteht, wären für eine Anwendung `n+1`-GitLab-Projekte erforderlich.\n\nDas Artefakt, das aus einem Programmierprojekt hervorgeht, ist in der Regel ein Container-Image, das zum Paketieren der Anwendung verwendet wird. Das Infrastruktur- oder Bereitstellungsprojekt enthält die Kubernetes-Manifeste, in denen alle Ressourcen definiert sind, die für die Skalierung und die Bereitstellung des Datenverkehrs für jeden Microservice erforderlich sind. Das Artefakt, das aus diesem Projekt hervorgeht, ist in der Regel ein OCI-Image, das zur Bereitstellung der Anwendung und anderer Manifeste für Kubernetes verwendet wird. \n\nIn diesem Setup wird die Trennung von Umgebungen durch die Definition von Kubernetes-Manifesten in separaten Ordnern gehandhabt. Diese Ordner stellen Umgebungen (z. B. Entwicklung, Staging und Produktion) dar, in denen die Anwendung gehostet wird. Wenn Änderungen am Codeprojekt vorgenommen und ein neues Container-Image gepusht wird, müssen zur Bereitstellung dieser Änderungen über die Integration von GitLab mit Flux CD lediglich die Manifeste im Ordner „Environment“ bearbeitet werden, um die neue Image-Referenz aufzunehmen, und ein „Merge Request“ geöffnet werden. Sobald dieser Merge Request überprüft, genehmigt und zusammengeführt wurde, wird der CI/CD-Job des Bereitstellungsprojekts ein neues OCI-Image pushen, das Flux CD aufnimmt und in der neuen Umgebung bereitstellt.\n\n![OCI-Images – Flowchart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nDas Signieren eines OCI-Image ist so einfach wie das Einfügen von Cosign in den CI/CD-Job deines Projekts. Du kannst einfach einen neuen öffentlichen und privaten Schlüssel mit Cosign generieren, indem du die folgenden Befehle lokal ausführst. Stelle einfach sicher, dass du dich mit der [glab-CLI](https://gitlab.com/gitlab-org/cli/#installation) bei deiner GitLab-Instanz anmeldest und die [`PROJECT_ID`] für den Befehl „cosign“ durch die [ID deines Bereitstellungsprojekts](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id) ersetzt.   \n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nSobald der Befehl „cosign“ erfolgreich ausgeführt wurde, findest du die zu deinem Projekt hinzugefügten Cosign-Schlüssel im Abschnitt „CI/CD-Variablen“ unter den Schlüsselnamen `COSIGN_PUBLIC_KEY` und `COSIGN_PRIVATE_KEY`.\n\n### Beispiel für einen CI/CD-Job\n\nEin GitLab-CI/CD-Job zum Pushen eines OCI-Images sieht in etwa so aus:\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\nDer [GitLab-CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) bietet eine von GitLab gepflegte [CI/CD-Komponente für die Arbeit mit OCI-Artefakten und Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). Mit dieser Komponente können Entwicklungsteams Kubernetes-Manifeste als OCI-Images an die Container-Registry von GitLab oder eine externe Container-Registry senden, das OCI-Image mit Cosign signieren und das neu gepushte Image sofort über Flux CD abgleichen. \n\nIm obigen Beispiel ist die Flux CD `component` in einer `.gitlab-ci.yml`-Datei eines GitLab-Projekts enthalten. Mithilfe der `inputs` der Komponente können Benutzer(innen) definieren, in welche Registry das Image gepusht werden soll (d. h. `registry_image_url` und `image tag`), den Dateipfad zu den Kubernetes-Manifesten, die gepusht werden sollen (d. h. `manifest_path`), den privaten Cosign-Schlüssel, der zum Signieren von Images verwendet wird (d. h. `signing_private_key`), sowie den Kubernetes-Namensraum und den Namen des Flux-CD-[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/), der für die Synchronisierung von Aktualisierungen in einer Umgebung benötigt wird (d. h. `flux_oci_namespace_name` und `flux_oci_repo_name`).\n\nMit der `kubernetes_agent_reference` können GitLab-CI/CD-Jobs das für den Zugriff auf einen Kubernetes-Cluster erforderliche `kubeconfig` erben, ohne dass in jedem GitLab-Projekt eine `kubeconfig`-CI/CD-Variable gespeichert werden muss. Durch die Einrichtung des [GitLab Agent for Kubernetes (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/) können die CI/CD-Jobs aller GitLab-Projekte in einer [GitLab-Gruppe (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/) konfiguriert werden, um Berechtigungen für die Bereitstellung im Kubernetes-Cluster zu erben. \n\nDer Agent für den Kubernetes-Kontext wird normalerweise überall dort konfiguriert, wo du den GitLab Agent for Kubernetes in deiner GitLab-Gruppe konfigurierst. Das solltest du in der Regel in dem Projekt zu tun, in dem Flux CD verwaltet wird. Weitere Informationen zur Konfiguration des Agents für den CI/CD-Zugriff findest du in unserer [CI/CD-Workflow-Dokumentation (nur in englischer Sprache verfügbar)]( https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nDie Variablen `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME` und `$FRONTEND_DEV_NAMESPACE` sind Werte, die als CI/CD-Variablen gespeichert werden, um den Zugriff auf diese vertraulichen Daten in CI/CD-Protokollen zu erleichtern und sie zu maskieren. `$CI_REGISTRY_IMAGE` ist eine Variable, die standardmäßig in GitLab-Jobs verfügbar ist und die Container-Registry des GitLab-Projekts angibt. \n\n### Bereitstellen von OCI-Images\n\nWenn du [Flux CD mit deinen GitLab-Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html) verwendest, kannst du die Bereitstellung und Signaturprüfung für die Umgebungen deiner Microservices automatisieren. Sobald Flux CD für die Synchronisierung von einem GitLab-Projekt konfiguriert ist, kannst du die folgenden [benutzerdefinierten Ressourcendefinitionen](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) von Kubernetes zu deinem Projekt hinzufügen, um dein gepushtes OCI-Image zu synchronisieren. \n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n``` \n\nMit der Ressource [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) können Kubernetes-Manifeste weiter angepasst werden und sie gibt auch an, in welchem Namensraum Ressourcen bereitgestellt werden sollen. Die Ressource `OCIRepository` für Flux CD ermöglicht es Benutzer(inne)n, die OCI-Image-Repositoryreferenz und das Tag anzugeben, von dem regelmäßig synchronisiert werden soll. Außerdem wirst du die Eigenschaften `verify.provider` und `verify.secretRef` bemerken. Anhand dieser Felder kannst du überprüfen, ob das für den Cluster bereitgestellte OCI-Image mit dem entsprechenden privaten Cosign-Schlüssel signiert wurde, der im früheren CI/CD-Job verwendet wurde. \n\nDer öffentliche Schlüssel muss in einem [Kubernetes-Geheimnis](https://kubernetes.io/docs/concepts/configuration/secret/) gespeichert werden, das sich im selben Namensraum wie die Ressource `OCIRepository` befinden muss. Damit Flux CD dieses Geheimnis verwaltet und es nicht im Klartext gespeichert wird, kannst du [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) verwenden, um den Wert zu verschlüsseln und ihn cluster-seitig von einem Controller entschlüsseln zu lassen. \n\nEine einfachere Methode, für die SealedSecrets nicht erforderlich ist, ist die [Bereitstellung des Geheimnisses über einen GitLab-CI/CD-Job (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) mit der [`kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). Bei der Variante ohne SealedSecret entfernst du einfach das oben enthaltene SealedSecret und führst den Job zur Bereitstellung des öffentlichen Geheimnis-Schlüssels aus, bevor du den Job zum Pushen des neuen OCI-Images ausführst. Dadurch wird sichergestellt, dass das Geheimnis sicher in GitLab gespeichert ist und dass es im Cluster vom OCIRepository abgerufen werden kann. Dieser Ansatz ist etwas einfacher, aber nicht für die Verwaltung von Geheimnissen in der Produktion geeignet. \n\n## Die Vorteile von OCI, GitLab und GitOps\n\nMit OCI-Artefakten (Oracle Cloud Infrastructure) können GitOps-Teams Bereitstellungen noch weiter optimieren. Sie bieten zusätzliche Sicherheitsvorteile und ermöglichen minimale Bereitstellungen. Benutzer(innen) profitieren weiterhin von allen Vorteilen, die Git bietet, insbesondere von einer zuverlässigen Datenquelle für die Infrastruktur und der Zusammenarbeit an Projekten. OCI-Images erweitern den Bereitstellungsansatz von GitOps um einen Paketierungsansatz.\n\nBei GitLab lernen wir kontinuierlich von unseren Kund(inn)en und der Cloud-nativen Community, um Erfahrungen zu sammeln, die zur Vereinfachung von GitOps-Workflows beitragen. Einige der in diesem Blogbeitrag erwähnten Funktionen kannst du nutzen, indem du dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) anmeldest. Wir freuen uns auch über Erfahrungsberichte von Benutzer(inne)n dieser Tools. Feedback kannst du im [Community-Forum](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965) abgeben.\n",[109,9,750,537,682,705],"kubernetes","2025-05-12",{"slug":753,"featured":6,"template":686},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:de-de:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":759,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":760,"content":764,"config":775,"_id":777,"_type":14,"title":778,"_source":16,"_file":779,"_stem":780,"_extension":19},"/de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":761,"description":762,"ogTitle":761,"ogDescription":762,"config":763},"Mit GitLab Open-Source-Communities erfolgreich skalieren","GitLab steigerte die Mitwirkenden-Erfolgsquote von 17 % auf 100 %. Entdecke die Tools und Automatisierungen, die Open-Source-Onboarding revolutionieren.",{"noIndex":6},{"heroImage":765,"body":766,"authors":767,"updatedDate":770,"date":771,"title":772,"tags":773,"description":774,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png","GitLabs Contributor Success Team stand vor einer Herausforderung.\n\nWährend unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von [GitLabs Mission](https://handbook.gitlab.com/handbook/company/mission/),\n\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\n\n\nWir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat\n\nund übertrafen damit erstmals unser Teamziel von 170.\n\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\n\n\nSo haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.\n\n\n## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\n\nWir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.\n\n\nDie Teilnehmenden sagten uns:\n\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n\n* Der Einstieg fühlte sich überwältigend an\n\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\n\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\n\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\n\n\n2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100 %. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der\n\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\n\n„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'\"\n\n\n## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\n\nUnsere Lösung begann mit Engagement.\n\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\n\nMitwirkenden mit einem Community-Maintainer verbindet.\n\n\nWir erstellten ein [Issue-Template](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md) mit einer klaren Checkliste von Aufgaben.\n\n\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\n\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\n\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\n\n\nMit [Scoped Labels](https://docs.gitlab.com/user/project/labels/#scoped-labels) zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.\n\n\n![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\n\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\n\n\nVon hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.\n\n\n## Wir standardisierten Antworten mit Kommentar-Templates\n\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\n\ndie wir mit dem Repository über die GraphQL-API und ein\n\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\n\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n\n```yaml\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\n\nUnsere erste Iteration war etwas langsam.\n\nNach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen.\n\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\n\n\n[Niklas](https://gitlab.com/Taucher2003), ein Mitglied unseres [Core Teams](https://about.gitlab.com/community/core-team/), entwickelte eine Lösung. Er fügte [Webhook-Events für Zugangsanfragen ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094)und [benutzerdefinierte Payload-Templates für Webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738) hinzu.\n\n\nDiese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.\n\n\nWir richteten ein [Pipeline-Trigger-Token](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:\n\n\n```json\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n```\n\n\n![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Wir automatisierten Nachfassaktionen\n\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\n\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\n\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\n\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\n\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## Wir organisierten die Issue-Verfolgung mit GLQL\n\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\n\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\n\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nEs war so erfolgreich, dass wir diese Strategie auch bei den Programmen [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\n\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\n\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n\n## Wir machten die README auffindbar\n\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\n\nist das Zuhause für Mitwirkende auf GitLab.com.\n\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\n\nbefand sich in unserem Meta-Projekt.\n\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\n\nOnboarding-Issues unter einem anderen Projekt waren.\n\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\n\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\n\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Die Ergebnisse sprechen für sich selbst\n\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\n\nund transformierten die GitLab-Mitwirkenden-Journey.\n\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\n\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\n\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\n\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\n\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\n\num unsere Antwortzeiten zu verfolgen.\n\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\n\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\n\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\n\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\n\nErfolge und Belohnungen bietet.\n\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n\n## Was wir gelernt haben teilen\n\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\n\nWir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.\n\n\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\n\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\n\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n\n## Das Gespräch beginnen\n\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\n\nSende eine E-Mail an `contributors@gitlab.com` oder [öffne ein Issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues),\n\num eine Diskussion zu beginnen.\n\nWir sind hier, um beim Aufbau von Communities zu helfen.\n",[768,769],"Lee Tickett","Daniel Murphy","2025-07-23","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[9,270,703],"In nur einem Jahr steigerten wir die Erfolgsquote neuer Open-Source-Mitwirkender von 17 % auf 100 %. Hier sind die GitLab-Tools und -Prozesse, die den Unterschied machten.",{"featured":6,"template":686,"slug":776},"how-we-use-gitlab-to-grow-open-source-communities","content:de-de:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"_path":782,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":783,"content":789,"config":795,"_id":797,"_type":14,"title":798,"_source":16,"_file":799,"_stem":800,"_extension":19},"/de-de/blog/journey-through-gits-20-year-history",{"title":784,"description":785,"ogTitle":784,"ogDescription":785,"noIndex":6,"ogImage":786,"ogUrl":787,"ogSiteName":673,"ogType":674,"canonicalUrls":787,"schema":788},"20 Jahre GitLab: Begib dich mit uns auf eine Reise","Begib dich mit uns auf die Spuren des ersten Commits, die einzigartigen Aspekte der frühen Releases und die Verwirrung, die ein Update des Standardverhaltens von git-push(1) ausgelöst hat.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"20 Jahre GitLab: Begib dich mit uns auf eine Reise\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }",{"title":784,"description":785,"authors":790,"heroImage":786,"date":791,"body":792,"category":10,"tags":793,"updatedDate":794},[678],"2025-04-14","Das Git-Projekt ist gerade 20 Jahre alt geworden. In diesen Jahren ist viel passiert – während das konzeptionelle Design von [GitLab](https://about.gitlab.com/de-de/) seit seiner Entstehung nicht wesentlich verändert wurde, hat sich doch die Art und Weise, wie Benutzer(innen) mit dem Tool interagieren, deutlich geändert. Wir bei GitLab sind stolz darauf, auf dieser wichtigen Software aufzubauen und Teil ihrer Erfolgsgeschichte zu sein.\n\nBegleite uns auf einer Reise durch die Geschichte von Git und entdecke, wie sich das System im Laufe der Jahre entwickelt hat.\n\n## Der erste Commit\n\nDer erste Commit wurde am 7. April 2005 von [Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/), dem Schöpfer des Linux-Kernels, vorgenommen: `e83c5163316 (Initial revision\nof \"git\", the information manager from hell, 2005-04-07)`.\n\nWie wir sehen können, enthält dieser Commit nicht viele Dateien:\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nNeben der Build-Infrastruktur bietet der erste Commit sieben Top-Level-Befehle:\n\n- `init-db` zum Initialisieren eines neuen Git-Repositorys\n- `update-cache` zum Hinzufügen von Dateien zum Index\n- `write-tree`, um den Inhalt des Index heranzuziehen und daraus einen neuen Baum zu erstellen\n- `read-tree` zum Lesen eines Baum-Objekts\n- `commit-tree` zum Erstellen eines Commits aus einem Baum\n- `cat-file` zum Lesen eines spezifischen Objekts in eine temporäre Datei\n\nBeachte, dass der Befehl `git` zu der Zeit noch gar nicht existierte.\n\nStattdessen mussten diese Befehle direkt ausgeführt werden.\n\nErstellen wir zum Beispiel ein neues Repository:\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nDas sieht ziemlich unbekannt aus: Es gibt kein `.git`-Verzeichnis, aber dafür gibt es das Verzeichnis `.dircache`. Und wo war der private Speicherbereich?\n\nDas frühe Design von Git unterschied zwischen einem „geteilten“ und einem „privaten“ Objektspeicherbereich. In diesem Objektspeicherbereich befanden sich alle Git-Objekte. Zum Beispiel deine Commits und Blobs.\n\nStandardmäßig erstellte `init-db` einen privaten Objektspeicherbereich, der nur für das verwaltete Verzeichnis verwendet wurde, in dem es erstellt wurde. Ein „geteilter“ Objektspeicherbereich hingegen teilte Objektinhalte über mehrere verwaltete Verzeichnisse, so dass dasselbe Objekt nicht zweimal gespeichert werden musste.\n\n### Einen Commit erstellen\n\nWir haben nun ein Repository, doch wie wurde damals ein Commit erstellt? Das war nicht ganz so einfach wie heute mit `git add . && git commit`. Stattdessen musste man wie folgt vorgehen:\n\n1. Man musste den Index aktualisieren, indem man `update-cache` für jede Datei aufrief, die man hinzufügen wollte.\n2. Dann schrieb man einen neuen Baum, indem man `write-tree` aufrief, wodurch alles herangezogen wurde, was zum Index hinzugefügt worden war.\n3. Man richtete Umgebungsvariablen ein, um Git mitzuteilen, wer man ist.\n4. Dann schrieb man ein Commit-Objekt, indem man `commit-tree` aufrief.\n\nErstellen wir einen Commit im Repository:\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nDas ist nicht gerade ergonomisch, aber es funktioniert! Werfen wir einen Blick auf den generierten Commit:\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nBeachte, dass `cat-file` den Inhalt nicht direkt gedruckt hat, sondern ihn zuerst in eine temporäre Datei geschrieben hat. Der Inhalt der Datei sieht jedoch genauso aus, wie ein moderner Commit aussehen würde.\n\n### Änderungen vornehmen\n\nWie können wir nun den Status der Dateien ermitteln? Vielleicht hast du es erraten: mit `show-diff`:\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nLustigerweise konnte `show-diff` bereits diffs zwischen dem alten und neuen Zustand der geänderten Datei generieren! Git hat das jedoch erreicht, indem es einfach das Unix-Tool diff(1) ausgeführt hat.\n\nZusammenfassend lässt sich sagen, dass dies zwar alles noch recht spartanisch war, aber das Nötige bot, um den Verlauf nachzuverfolgen. Es gab aber noch viele Einschränkungen:\n\n- Es gab noch keine einfache Möglichkeit, zwischen Commits zu wechseln.\n- Es gab keine Möglichkeit, Protokolle anzuzeigen.\n- Es gab keine Branches, Tags und nicht einmal Referenzen. Von den Benutzer(inne)n wurde erwartet, dass sie die Objekt-IDs manuell verfolgen.- Es gab keine Möglichkeit, zwei Repositories miteinander zu synchronisieren. Stattdessen wurde von den Benutzer(inne)n erwartet, dass sie „rsync(1)“ verwenden, um die `.dircache`-Verzeichnisse zu synchronisieren.\n- Es gab keine Möglichkeit, Merges durchzuführen.\n\n## Git 0.99\n\nDie erste Testversion von Git war Version 0.99. Diese Release kam nur zwei Monate nach dem ersten Commit auf, enthielt aber bereits 1.076 Commits. Es waren fast 50 verschiedene Entwickler(innen) beteiligt. Der häufigste Commiter war zu diesem Zeitpunkt Linus selbst, dicht gefolgt von Junio Hamano, dem aktuellen Betreuer.\n\nViele Dinge hatten sich seit dem ersten Commit geändert:\n\n- Git begann, verschiedene Entwicklungs-Branches mithilfe von Referenzen zu verfolgen, wodurch in den meisten Fällen Objekt-IDs nicht mehr manuell nachverfolgt werden mussten.\n- Es gab ein neues Remote-Protokoll, das es zwei Repositories ermöglichte, Objekte miteinander auszutauschen.\n- Das Verzeichnis `.dircache` wurde in `.git` umbenannt.\n- Es wurde möglich, einzelne Dateien zusammenzuführen.\n\nDie wichtigste offensichtliche Änderung war jedoch die Einführung des Top-Level-Befehls `git` und seiner Unterbefehle. Interessanterweise wurden mit dieser Version auch die Befehle „Plumbing“ und „Porcelain“ eingeführt:\n\n- „Plumbing“-Tools sind Low-Level-Befehle, die auf das zugrunde liegende Git-Repository zugreifen.\n- „Porcelain“-Tools sind Shell-Skripte, die die Plumbing-Befehle einpacken, um eine schönere, hochwertige Benutzeroberfläche zu bieten.Diese Aufteilung existiert auch heute noch, wie in [`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain) dokumentiert ist. Da die meisten Porcelain-Tools jedoch von Shell-Skripten zu C umgeschrieben wurden, verschwimmt die Trennung zwischen den beiden Kategorien mittlerweile deutlich.\n\n## Linus übergibt die Leitung\n\nLinus hat Git nie gegründet, weil sein Herz für Versionskontrollsysteme schlägt, sondern weil er für die Entwicklung des Linux-Kernels eine brauchbare Alternative zu BitKeeper suchte. Daher hatte er nie vor, Git für immer zu leiten. Die Absicht war, es so lange zu leiten, bis er eine(n) vertrauenswürdige(n) Nachfolger(in) gefunden hatte.\n\nDieser Jemand war Junio Hamano. Junio stieg etwa eine Woche nach dem ersten Commit von Linus bei Git ein und hatte nach der Veröffentlichung von Git 0.99 bereits einige hundert Commits im Verlauf. Am 26. Juli 2005 machte [Linus daher Junio zum neuen Betreuer des Git-Projekts](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Linus trug zwar weiter zu Git bei, doch seine Beteiligung wurde nach und nach immer weniger – nicht verwunderlich, da er als Leiter des Linux-Projektes ziemlich beschäftigt ist.\n\nJunio leitet das Git-Projekt auch heute noch.\n\n> Lies unser großes [Interview mit Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) und erfahre noch mehr über die Geschichte von Git.\n\n## Git 1.0\n\nDie erste größere Version von Git wurde am 21. Dezember 2005 von Junio veröffentlicht. Interessanterweise gab es 34 Releases zwischen Version 0.99 und Version 1.0: 0.99.1 bis 0.99.7, 0.99.7a bis 0.99.7d, 0.99.8 bis 0.99.8g und 0.99.9 bis 0.99.9n.\n\nEiner der wichtigsten Meilensteine seit Version 0.99 war wahrscheinlich der Befehl `git-merge(1)`, der hinzugefügt wurde und mit dem man zwei Bäume zusammenführen kann. Dies ist eine enorme Veränderung zu vorher, wo man im Grunde die Zusammenführungen Datei für Datei skripten musste.\n\n### Remotes\n\nEine weitere wesentliche Änderung war die Einführung der Kurzschreibweise für Remote-Repositories. Während Git bereits wusste, wie man mit Remote-Repositories kommuniziert, mussten Benutzer(innen) jedes Mal die URL angeben, von der sie abrufen wollten, um Änderungen daran vorzunehmen. Dies war ziemlich unpraktisch für die Benutzer(innen), da sie im Normalfall immer wieder mit demselben Remote interagieren wollten.\n\nDu weißt vielleicht, wie Remotes jetzt funktionieren, aber der Vorgang war damals noch deutlich anders. Es gab keinen `git-remote(1)`-Befehl, mit dem man seine Remotes verwalten konnte. Remotes wurden nicht einmal in der Datei `.git/config` gespeichert. Als Remotes in Version 0.99.2 eingeführt wurden, *gab* es in Git nicht einmal Konfigurationsdateien.\n\nStattdessen musste man Remotes konfigurieren, indem man eine Datei in das Verzeichnis `.git/branches` schrieb, was dem heutigen Empfinden nach gegen jegliche Intuition geht. Aber der Mechanismus funktioniert auch heute noch:\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nAber das ist noch nicht alles! Das Verzeichnis wurde bald darauf mit der Git-Version 0.99.5 in „remotes“ umbenannt, also gibt es in einem modernen Git-Client insgesamt drei verschiedene Möglichkeiten, Remotes zu konfigurieren.\n\nDie meisten von euch haben wahrscheinlich weder `.git/branches` noch `.git/remotes` verwendet, denn beide Mechanismen gelten seit 2005 bzw. 2011 als veraltet. Darüber hinaus werden diese Verzeichnisse in Git 3.0 endgültig entfernt.\n\n## Git-Branding\n\nIm Jahr 2007 wurde das erste Git-Logo erstellt. Ob man das schon als Logo bezeichnen kann, ist fraglich, da es nur aus drei roten Minuszeichen über drei grünen Pluszeichen bestand. Dies sollte widerspiegeln, wie die Ausgabe von `git diff` aussah:\n\n![Drei rote Minuszeichen über drei grünen Pluszeichen, die die Ausgabe von `git diff` widerspiegeln](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nEtwas später, im Jahr 2008, wurde die Website [git-scm.com](https://git-scm.com) veröffentlicht:\n\n![Startseite für git-scm.com im Jahr 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nIm Jahr 2012 wurde die Git-Webseite von Scott Chacon und Jason Long [überarbeitet](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/). Sie sieht ziemlich ähnlich aus wie heute:\n\n![Die Git-Website wurde 2012 überarbeitet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nDieses neue Design der Website weist das neue rot-orangefarbene Logo von Jason Long auf, das auch derzeit verwendet wird:\n\n![Git-Logo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit begann schon in der Version 1.0, dem modernen Git sehr ähnlich zu sehen. Daher folgt nun der große historische Sprung zu Git 2.0. Diese Version wurde etwa 10 Jahre nach Git 1.0 veröffentlicht und war die erste Version, die absichtlich abwärtskompatible Änderungen in zentralen Workflows enthielt.\n\n### Standardverhalten von `git-push(1)`\n\nDie Änderung, die wohl die meiste Verwirrung in dieser Version verursachte, war das geänderte Standardverhalten von `git-push(1)`.\n\nEs gibt ein paar verschiedene Aktionen, die Git ausführen kann, wenn du in ein Remote-Repository pusht und nicht genau angibst, was genau du pushen möchtest:\n\n- Git kann verweigern, irgendetwas zu tun, und bittet dich um weitere Informationen darüber, was genau du pushen möchtest.\n- Git kann den aktuell ausgecheckten Branch pushen.\n- Git kann den aktuell ausgecheckten Branch pushen, aber nur, wenn es weiß, dass es ein Äquivalent auf der Remote-Seite gibt.\n- Git kann alle deine Branches pushen, die ein Äquivalent auf der Remote-Seite haben.\n\nDas Verhalten des modernen Git ist die sogenannte „einfache“ Strategie, also die dritte der oben angeführten Optionen. Vor Git 2.0 war das Standardverhalten jedoch die „Matching“-Strategie, also die letzte der genannten Optionen.\n\nDie „Matching“-Strategie war deutlich riskanter. Man musste vor dem Pushen immer sicherstellen, dass es in Ordnung war, alle lokalen Branches zu pushen, die ein Äquivalent auf der Remote-Seite haben. Andernfalls hätte man möglicherweise unbeabsichtigt Änderungen gepusht. Daher wurde beschlossen, die Strategie auf die „einfache“ Strategie zu ändern, um das Risiko zu verringern und Einsteiger(inne)n die ersten Schritte mit Git zu erleichtern.\n\n### `git-add(1)`\n\nEine weitere große Änderung war das Standardverhalten von `git-add(1)` im Hinblick auf nachverfolgte Dateien, die gelöscht wurden. Vor Git 2.0 hätte `git-add(1)` gelöschte Dateien nicht automatisch gestaged, sondern du hättest jede gelöschte Datei manuell mit `git-rm(1)` hinzufügen müssen, damit sie Teil des Commits ist. Mit Git 2.0 wurde dieses Verhalten geändert, sodass `git-add(1)` auch gelöschte Dateien zum Index hinzufügt.\n\n## Wir feiern die Git-Community\n\nIch werde dich nicht mit Details darüber langweilen, wie Git heute funktioniert – du nutzt es wahrscheinlich ohnehin täglich, und wenn nicht, gibt es viele tolle Tutorials, die dir beim Einstieg helfen. Stattdessen wollen wir die Git-Community hochleben lassen – sie ist es nämlich, dank der Git auch 20 Jahre später noch wunderbar funktioniert.\n\nIm Laufe der Zeit hat Git:\n\n- 56 721 Commits seit der Veröffentlichung von Git 2.49 erhalten.\n- Beiträge von mehr als 2 000 verschiedenen Personen erhalten.\n- 60 Hauptversionen veröffentlicht.Das Git-Projekt hat auch einen stetigen Zustrom neuer Mitwirkender durch die Teilnahme am [Google Summer of Code](https://summerofcode.withgoogle.com/) und [Outreachy](https://www.outreachy.org/) erfahren. Neue Mitwirkende wie diese werden dafür sorgen, dass das Git-Projekt auch langfristig weitergeführt wird.\n\nDaher möchte ich allen Mitwirkenden von Herzen danken. Es sind eure Beiträge, die Git erst möglich gemacht haben.\n\n## Ein Blick in die Zukunft\n\nEs steht außer Frage, dass Git den Wettlauf um das beste Versionskontrollsystem gewonnen hat. Es hat einen bedeutenden Marktanteil, und es ist nicht einfach, Open-Source-Projekte zu finden, die ein anderes Versionskontrollsystem als Git verwenden. Git hat also eindeutig vieles richtig gemacht.\n\nDennoch ist die Entwicklung nicht stillgestanden und auch in Zukunft werden viele Herausforderungen auf Git warten. Einerseits sind das technische Herausforderungen:\n- Modernisierung einer alternden Codebasis\n- Skalierung mit der ständig wachsenden Größe von Monorepos\n- Bessere Handhabung großer Binärdateien\n\nAndererseits tauchen Probleme sozialer Art auf:\n- Verbesserung der Benutzerfreundlichkeit von Git\n- Förderung der Git-Community, damit das Projekt langfristig gesund bleibt\n\nEs gibt immer noch viel zu tun und wir bei GitLab sind stolz darauf, Teil dieser Bemühungen zu sein. Gemeinsam können wir sicherstellen, dass Git auch in den nächsten 20 Jahren ein so fantastisches Versionskontrollsystem bleibt.\n\n## Erfahre mehr über Git\n\n- [Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Was gibt es Neues in Git 2.49.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-49-0/)\n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n- [Der Anfängerleitfaden zum „reftable“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)",[9,682],"2025-05-20",{"slug":796,"featured":91,"template":686},"journey-through-gits-20-year-history","content:de-de:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","de-de/blog/journey-through-gits-20-year-history.yml","de-de/blog/journey-through-gits-20-year-history",{"_path":802,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":803,"content":809,"config":820,"_id":822,"_type":14,"title":823,"_source":16,"_file":824,"_stem":825,"_extension":19},"/de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"ogTitle":804,"schema":805,"ogImage":806,"ogDescription":807,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":808,"title":804,"canonicalUrls":808,"description":807},"Co-Create: Wie Kunden GitLab gemeinsam entwickeln","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","Erfahre, wie Unternehmen wie Thales, Scania und Kitware mit GitLab-Entwickler(inne)n zusammenarbeiten, um sinnvolle Funktionen beizusteuern, von denen die gesamte Community profitiert.","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"heroImage":806,"body":810,"authors":811,"updatedDate":813,"date":814,"title":815,"tags":816,"description":807,"category":819},"Im vergangenen Jahr haben über 800 Community-Mitglieder mehr als 3 000 Beiträge zu GitLab geleistet. Darunter sind auch Teammitglieder aus globalen Unternehmen wie Thales und Scania, die im Rahmen des [Co-Create-Programms (nur in englischer Sprache verfügbar)](https://about.gitlab.com/community/co-create/) die Zukunft von GitLab mitgestalten. Bei diesem Programm arbeiten Kund(inn)en direkt mit GitLab-Entwickler(inne)n zusammen, um sinnvolle Funktionen zur Plattform beizutragen.\n\nDurch Workshops, Paarprogrammierungssitzungen und kontinuierlichen Support erhalten die Programmteilnehmenden praktische Erfahrungen mit der Architektur und der Codebase von GitLab, während sie Probleme lösen oder bestehende Funktionen verbessern.\n\n„Unsere Erfahrungen mit dem Co-Create-Programm waren unglaublich“, erklärt Sébastien Lejeune, Open-Source-Beauftragter bei Thales. „Es hat nur zwei Monate gedauert, bis wir unseren Beitrag mit einem GitLab Contributor Success Engineer besprochen haben und er in die GitLab-Release aufgenommen wurde.“\n\nIn diesem Beitrag zeigen wir, wie Kund(inn)en das Co-Create-Programm genutzt haben, um ihre Ideen in Code zu verwandeln und dabei zu lernen und mitzuwirken.\n\n## Die Co-Create-Erfahrung\n[Das GitLab Development Kit (GDK) (Dokumentation nur in englischer Sprache verfügbar)](https://gitlab.com/gitlab-org/gitlab-development-kit) hilft Mitwirkenden, mit der Entwicklung von GitLab zu beginnen. „Mein Rat für neue Mitwirkende lautet, dass man mit dem GDK nichts kaputt machen kann“, sagt Hook. „Wenn du eine Änderung vornimmst und sie nicht funktioniert, kannst du sie rückgängig machen oder von vorne beginnen. Das Schöne am GDK ist, dass man tüfteln, testen und lernen kann, ohne sich Gedanken über die Umgebung machen zu müssen.“\n\nJedes Unternehmen, das am Co-Create-Programm teilnimmt, erhält während seiner gesamten Beitragsphase Unterstützung:\n\n- __Technischer Onboarding-Workshop __: Eine spezielle Sitzung, um das GitLab Development Kit einzurichten und die Architektur von GitLab zu verstehen\n- __Persönlicher Engineering-Support__: Kontakt zu GitLab-Entwickler(inne)n für Paarprogrammierung und technische Beratung\n- __Vertiefende Einblicke in die Architektur__: Spezialisierte Sitzungen zu bestimmten GitLab-Komponenten, die für das Thema, zu dem das Unternehmen beiträgt, relevant sind\n- __Code-Review-Support__: Detailliertes Feedback und Anleitung für den Merge-Request-Prozess\n- __Regelmäßige Rückmeldungen__: Laufende Zusammenarbeit, um den Fortschritt zu sichern und Herausforderungen zu bewältigen\n\nDiese Struktur sorgt dafür, dass Teams unabhängig von ihrer Erfahrung mit der Codebase von GitLab oder der Programmiersprache Ruby/Go effektiv mitarbeiten können. John Parent von Kitware erklärt: „Wenn du GitLab noch nie gesehen oder damit gearbeitet hast, siehst du dich mit einer ausgeklügelten Architektur und so viel Code in verschiedenen Projekten konfrontiert. Mithilfe des Co-Create-Programms lässt sich das, was wochenlange interne Schulungen erfordern würde, in einen gezielten Crashkurs umwandeln.“\n\nDas Ergebnis ist ein Programm, das nicht nur dabei hilft, neue Funktionen zu entwickeln, sondern auch dauerhafte Beziehungen zwischen GitLab und seiner Benutzer-Community aufzubauen. „Für unsere Entwickler(innen) ist es inspirierend zu sehen, mit welcher Leidenschaft unsere Kund(inn)en an GitLab mitarbeiten und es gemeinsam weiterentwickeln“, sagt Shekhar Patnaik, Principal Engineer bei GitLab. Die Kund(inn)en erleben den „GitLab-Weg“ und die Entwickler(innen) sehen, wie sie die Zukunft von GitLab mitgestalten.“\n\n## Verbesserung der Projekt-Benutzeroberfläche mit Thales\nAls Thales Verbesserungsmöglichkeiten für die leere Projektoberfläche von GitLab erkannte, reichten sie nicht nur eine Feature-Anfrage ein, sondern entwickelten die Lösung gleich selbst. Ihre Beiträge konzentrierten sich auf die Vereinfachung der Einrichtung neuer Projekte, indem sie die SSH-/HTTPS-Konfiguration mit einer Registerkarten-Oberfläche vereinfachten und eine Kopier-/Einfügefunktion für die Code-Schnipsel hinzufügten. Diese Änderungen hatten einen erheblichen Einfluss auf den Workflow der Entwickler(innen).\n\nDas Team hat aber nicht nur die Benutzeroberfläche verbessert. Quentin Michaud, PhD Fellow für Cloud Applications on the Edge bei Thales, trug zur Verbesserung des GitLab Development Kit (GDK) bei. Als Paketbetreuer für Arch Linux hat Michaud mit seinem Fachwissen die Dokumentation des GDK verbessert und die Containerisierung unterstützt, um zukünftigen Mitwirkenden den Einstieg zu erleichtern.\n\n„Meine Erfahrung mit Open Source half mir bei der Problembehebung der GDK-Unterstützung für Linux-Distributionen“, sagt Michaud. „Während ich die Dokumentation zur Paketversionierung verbesserte, sah ich, dass das Contributor-Success-Team von GitLab ebenfalls daran arbeitete, GDK in einem Container einzurichten. Zu sehen, wie unsere Bemühungen zusammenlaufen, war ein großartiger Moment für mich – er zeigte, wie Open-Source-Zusammenarbeit zu besseren Lösungen führen kann.“\n\nDie positive Erfahrung für das Thales-Team bedeutet, dass Lejeune das Co-Create-Programm jetzt als „ein überzeugendes Beispiel dafür nutzt, unseren Manager(inne)n die Rentabilität von Beiträgen zu Open-Source-Software zu zeigen.“\n\n## Verbesserung der Paketunterstützung mit Scania\nAls Scania erweiterte Paketunterstützung in GitLab benötigte, sah das Unternehmen die Möglichkeit, selbst dazu beizutragen und sie zu entwickeln.\n\n„Wir sind langjährige GitLab-Benutzer(innen) und fördern Open Source aktiv in unserem Unternehmen. Das Co-Create-Programm bot uns eine sinnvolle Möglichkeit, direkt zu Open Source beizutragen“, sagt Puttaraju Venugopal Hassan, Solution Architect bei Scania.\n\nDas Team begann mit kleineren Änderungen, um sich mit der Codebase und dem Review-Prozess vertraut zu machen, und ging dann zu größeren Funktionen über. „Einer der lohnendsten Aspekte des Co-Create-Programms war es, auf den gesamten Prozess zurückzublicken und zu sehen, wie weit wir gekommen sind“, sagt Océane Legrand, Softwareentwicklerin bei Scania. „Wir haben mit der Erkundung und kleineren Änderungen angefangen, aber mit der Zeit haben wir größere Aufgaben übernommen. Es ist toll, diese Entwicklung zu sehen.“\n\nZu den Beiträgen von Scania gehören Fehlerkorrekturen für die Paket-Registry und Bemühungen, die Conan-Paket-Registry zu verbessern, um sie der allgemeinen Verfügbarkeit (GA) näher zu bringen und gleichzeitig die Unterstützung für Conan Version 2 zu implementieren. Ihre Arbeit und die Zusammenarbeit mit GitLab zeigt, wie das Co-Create-Programm die Funktionen der Paket-Registry von GitLab erheblich verbessern kann.\n\n„Unsere Erfahrungen mit dem Co-Create-Programm waren von Anfang an sehr gut organisiert. Wir hatten Schulungen, die uns durch alles führten, was wir für unseren Beitrag brauchten. In Einzelgesprächen mit jemandem aus dem Entwicklungsteam von GitLab erhielten wir außerdem einen detaillierten Einblick in die Paketarchitektur von GitLab, was den Beitragsprozess deutlich vereinfachte“, sagt Juan Pablo Gonzalez, Softwareentwickler bei Scania.\n\nDas Programm wirkt sich nicht nur auf die Programmierung aus – Teilnehmende erwerben durch ihre Beiträge auch wertvolle Fähigkeiten. Bei der Veröffentlichung von GitLab 17.8 wurden sowohl [Legrand als auch Gonzalez als GitLab MVPs (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp) ausgezeichnet. Legrand sprach darüber, wie sich ihre Arbeit im Open-Source-Bereich sowohl auf GitLab als auch auf Scania auswirkt und wie sie und ihr Team neue Fähigkeiten erwerben: „Durch die Mitarbeit im Co-Create-Programm habe ich neue Fähigkeiten erworben, z. B. Erfahrungen mit Ruby und Hintergrundmigrationen. Als mein Team bei Scania während eines Upgrades mit einem Problem konfrontiert wurde, konnte ich bei der Problembehebung helfen, weil ich das Problem bereits aus dem Co-Create-Programm kannte.“\n\n## Optimierung der Authentifizierung für High-Performance-Computing mit Kitware\nKitware brachte sein Fachwissen aus der Zusammenarbeit mit nationalen Laboratorien ein, um das Authentifizierungsframework von GitLab zu verbessern. Kitware unterstützte den OAuth2 Flow zur Erteilung von Geräteautorisierungen in GitLab und implementierte neue Datenbanktabellen, Controller, Ansichten und Dokumentationen. Dieser Beitrag erweitert die Authentifizierungsoptionen von GitLab und macht es vielseitiger für Geräte ohne Browser oder mit begrenzten Eingabemöglichkeiten.\n\n„Das Co-Create-Programm ist der effizienteste und effektivste Weg, um als Externe(r) zu GitLab beizutragen“, sagt John Parent, Entwicklungsingenieur bei Kitware. „Durch die Pairing-Sitzungen mit den Entwickler(inne)n haben wir bessere Implementierungen gefunden, die wir im Alleingang vielleicht übersehen hätten.“\n\nAls langjähriger Mitwirkender im Open-Source-Bereich schätzt Kitware besonders den Entwicklungsansatz von GitLab. „Ich bin davon ausgegangen, dass GitLab bei seiner Größe nicht auf vorgefertigte Lösungen zurückgreifen würde, aber es war großartig zu sehen, dass sie eine Ruby-Abhängigkeit eingebaut haben, anstatt eine eigene Lösung zu entwickeln“, sagt Parent. „Da ich aus der C++-Welt komme, wo Paketmanager selten sind, war es erfrischend zu sehen, wie einfach dieser Ansatz sein kann.“\n\n## Gemeinsam besser entwickeln: Vorteile des Co-Create-Programms\nDas Co-Create-Programm schafft Werte für beide Seiten. „Das Programm überbrückt die Kluft zwischen uns als GitLab-Entwickler(innen) und unseren Kund(inn)en“, erklärt Imre Farkas, Staff Backend Engineer bei GitLab. „Während der Zusammenarbeit erfahren wir, welche Herausforderungen sie tagtäglich haben, auf welche Teile von GitLab sie sich verlassen und wo Verbesserungen möglich sind. Es ist toll zu sehen, mit welcher Begeisterung sie sich an der Entwicklung von GitLab beteiligen.“\n\nDieser kollaborative Ansatz beschleunigt auch die Entwicklung von GitLab. Shekhar Patnaik, leitender Ingenieur bei GitLab, bemerkt dazu: „Durch das Co-Create-Programm helfen uns unsere Kund(inn)en, unsere Roadmap voranzutreiben. Ihre Beiträge ermöglichen es uns, wichtige Funktionen schneller bereitzustellen, wovon unsere gesamte Nutzerbasis profitiert. Wenn wir das Programm erweitern, haben wir das Potenzial, die Entwicklung unserer wichtigsten Funktionen zu beschleunigen, indem wir mit den Menschen zusammenarbeiten, die sich auf sie verlassen.“\n\n## Erste Schritte mit dem Co-Create-Programm\nBist du bereit, deine Feature-Anfragen in die Realität umzusetzen? Ganz gleich, ob du wie Thales die Benutzeroberfläche von GitLab verbessern, wie Scania die Paketunterstützung verbessern oder wie Kitware die Authentifizierung optimieren möchtest – das Co-Create-Programm heißt alle Unternehmen willkommen, die die Zukunft von GitLab aktiv mitgestalten und gleichzeitig wertvolle Open-Source-Erfahrungen sammeln möchten.\n\nEin(e) GitLab-Vertreter(in) kann dir sagen, wie du am Co-Create-Programm teilnehmen kannst. Weitere Informationen findest du auch auf der [Seite des Co-Create-Programms](https://about.gitlab.com/community/co-create/).\n",[812],"Fatima Sarah Khalid","2025-02-07","2025-01-30","Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln",[817,9,818],"contributors","customers","customer-stories",{"slug":821,"featured":91,"template":686},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:de-de:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":827,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":828,"content":834,"config":845,"_id":847,"_type":14,"title":848,"_source":16,"_file":849,"_stem":850,"_extension":19},"/de-de/blog/the-ultimate-guide-to-sboms",{"ogTitle":829,"schema":830,"ogImage":831,"ogDescription":832,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":833,"title":829,"canonicalUrls":833,"description":832},"Der ultimative Leitfaden zu SBOM","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative Leitfaden zu SBOM\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","Unser Leitfaden erklärt die Software Bill of Materials (SBOM) einfach und praxisnah. ✓ Definition ✓ Bedeutung ✓ Arten ✓ Vorteile ✓ GitLab-SBOM ➤ Lesen!","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms",{"heroImage":831,"body":835,"authors":836,"updatedDate":838,"date":839,"title":829,"tags":840,"description":844,"category":841},"In der heutigen digitalen Landschaft ist der Fokus auf Anwendungssicherheit innerhalb der Softwarebereitstellungskette kritischer denn je. Die Integration von Abhängigkeiten in Software erfordert Transparenz und Sicherheitsmaßnahmen, die oft komplex in der Implementierung und Verwaltung sind. Hier wird eine Software Bill of Materials (SBOM) unverzichtbar.\n\nUnser Leitfaden taucht tief in die Welt der SBOMs ein, beleuchtet ihre zentrale Rolle in einer multifunktionalen [DevSecOps-Strategie](https://about.gitlab.com/de-de/topics/devsecops/) und zeigt auf, wie du die SBOM-Gesundheit deiner Anwendung verbessern kannst – mit dem Ziel, die Cybersecurity deines Unternehmens zu stärken.\n\n## Inhalt - Der ultimative Guide zu SBOMs\n\n- [Was ist eine SBOM?](#was-ist-eine-software-bill-of-materials%3F)\n- [Warum sind SBOMs wichtig?](#warum-sind-sboms-wichtig%3F)\n- [Arten von SBOM-Datenaustauschstandards](#arten-von-sbom-datenaustauschstandards)\n- [Vorteile der Kombination von SBOMs und Software-Vulnerability-Management](#vorteile-der-kombination-von-sboms-und-software-vulnerability-management)\n- [Dynamische GitLab SBOMs](#dynamische-gitlab-sboms)\n- [SBOM-Generierung und -Verwaltung skalieren](#sbom-generierung-und-sbom-verwaltung-skalieren)\n- [SBOMs einlesen und zusammenführen](#sboms-einlesen-und-zusammenführen)\n- [Schwachstellen schneller beheben](#schwachstellen-schneller-beheben)\n- [Kontinuierliche SBOM-Analyse](#kontinuierliche-sbom-analyse)\n- [Vertrauen in SBOMs aufbauen](#vertrauen-in-sboms-aufbauen)\n- [Die Zukunft der SBOM-Funktionalität von GitLab](#die-zukunft-der-sbom-funktionalität-von-gitlab)\n- [Erste Schritte mit SBOMs](#erste-schritte-mit-sboms)\n- [SBOM-FAQ](#sbom-faq)\n\n## Was ist eine Software Bill of Materials?\n\nEine SBOM dient als umfassende [Liste der Komponenten](https://www.cisa.gov/sbom#), die Software ausmachen. Sie beleuchtet das Netzwerk von Bibliotheken, Tools und Prozessen, die im gesamten Entwicklungslebenszyklus verwendet werden. In Kombination mit Tools zum Management von Sicherheitslücken offenbart eine SBOM nicht nur genau diese potenziellen Sicherheitslücken in Softwareprodukten, sondern ebnet auch den Weg für strategische Risikominderung. \n\nEine SBOM ist ein verschachteltes Inventar oder eine Liste von Punkten, die Softwarekomponenten ausmachen. Zusätzlich zu den Komponenten selbst enthalten SBOMs wichtige Informationen über die Bibliotheken, Tools und Prozesse, die zur Entwicklung, zum Aufbau und zur Bereitstellung eines Software-Artefakts verwendet werden.\n\nDas Konzept des SBOM existiert seit mehr als einem Jahrzehnt. Im Rahmen der Bemühungen, die im Jahr 2023 veröffentlichte Nationale Cyber-Strategie umzusetzen, hilft CISA Secure by Design-Softwareherstellern, Sicherheitsprinzipien zu übernehmen und Cybersicherheit in ihre Produkte zu integrieren. Die [deutsche Regierung](https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/TR-03183-2-SBOM-Anforderungen.html) hat bewährte Verfahren herausgegeben, die Softwareentwickler(innen) im öffentlichen Sektor dazu bewegen, SBOMs in ihre Softwarepakete aufzunehmen. Auch auf dem privaten Sektor sindSBOMs immer mehr auf dem Vormarsch.\n\nObwohl SBOMs oft mit eigenständiger Software erstellt werden, integrieren Plattformen wie GitLab die SBOM-Generierung schon früh in den DevSecOps-Workflow.\n\n![supply chain security sdlc](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## Warum sind SBOMs wichtig?\n\nModerne Softwareentwicklung ist darauf fokussiert, Anwendungen schneller und effizienter zu liefern. Das führt oft dazu, dass Entwickler(innen) Code aus Open-Source-Repositories oder proprietären Paketen in ihre Anwendungen einbauen. Laut dem [Open Source Security and Risk Analysis-Bericht 2024 von Synopsys](https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2024.pdf), der über 1.000 kommerzielle Codebasen aus 17 Branchen im Jahr 2023 untersuchte, enthielten 96 % der gesamten Codebasen Open Source und 84 % der bewerteten Codebasen zeigten deutlicheSicherheitslücken.\n\nDie Einbindung von Code aus unbekannten Repositories erhöht das Risiko von Schwachstellen, die von Hackern ausgenutzt werden können. Tatsächlich wurde der [Angriff auf SolarWinds im Jahr 2020](https://www.spektrum.de/news/solarwinds-ein-hackerangriff-der-um-die-welt-geht/1819187) durch die Aktivierung einer bösartigen Code-Injektion in einem Paket ausgelöst, das von SolarWinds Orion-Produkt verwendet wurde. Kunden entlang der gesamten Softwarebereitstellungskette waren erheblich davon betroffen. Andere Angriffe, einschließlich der log4j-Schwachstelle, die mehrere kommerzielle Softwareanbieter traf, unterstrichen die Notwendigkeit einer genauen Untersuchung von Anwendungsabhängigkeiten, um Risiken in der gesamten [Softwarebereitstellungskette](https://about.gitlab.com/de-de/solutions/supply-chain/) zu bewerten.\n\nDarüber hinaus stellt das Auffinden und Beheben einer Sicherheitslücke einen Kostenfaktor dar –was die Bedeutung von SBOMs weiter unterstreicht. SBOMs ermöglichen Transparenz in Bezug auf Abhängigkeiten und können dazu genutzt werden, Schwachstellen sowie Lizenzen zu identifizieren, die nicht den internen Vorgaben entsprechen.\n\n## Arten von SBOM-Datenaustauschstandards   \n\nSBOMs sind am effektivsten, wenn die Generierung und Verarbeitung von Informationen wie Name, Version, Packager und weiteren Daten automatisiert erfolgen kann. Dies wird optimal erreicht, wenn alle Beteiligten ein standardisiertes Format für den Datenaustausch verwenden.\n\nEs gibt zwei wesentliche Standards für den SBOM-Datenaustausch:\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)\n- [SPDX](https://spdx.dev/)\n\nGitLab setzt für die SBOM-Generierung auf CycloneDX, da dieser Standard präzise und benutzerfreundlich ist, komplexe Abhängigkeiten vereinfacht und durch seine Erweiterbarkeit auch spezialisierte sowie zukünftige Anwendungsfälle abdeckt.\n\n## Vorteile der Kombination von SBOMs und Software-Vulnerability-Management\n\nSBOMs sind für DevSecOps-Teams und Software-Nutzer(innen) aus mehreren Gründen äußerst vorteilhaft:\nSie ermöglichen einen Standardansatz, um zu verstehen, welche zusätzlichen Softwarekomponenten in einer Anwendung enthalten sind und wo sie deklariert sind.\nSie bieten einen kontinuierlichen Einblick in den Entstehungsprozess einer Anwendung, einschließlich Details über die Herkunft des Codes von Drittanbietern und Host-Repositories.\nSie bieten ein hohes Maß an Sicherheitstransparenz, sowohl für den von Erstanbietern entwickelten Code als auch für die übernommene Open-Source-Software.\nDie Details, die SBOMs bieten, ermöglichen es einem [DevOps-Team](https://about.gitlab.com/de-de/topics/devops/), Schwachstellen zu identifizieren, die potenziellen Risiken zu bewerten und sie dann zu entschärfen.\nSBOMs können die Transparenz liefern, die die Käufer von Anwendungen heute verlangen.\n\n## Dynamische GitLab-SBOMs \n\nDamit SBOMs ihr volles Potenzial entfalten können, müssen sie automatisch generiert, mit Anwendungssicherheitsscans verbunden, in Dashboards integriert und kontinuierlich aktualisiert werden. GitLab unterstützt all diese Ziele und bietet dabei umfassende Funktionen zur Sicherung der Softwarebereitstellungskette.\n\n![Dynamic SBOM management](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### SBOM-Generierung und SBOM-Verwaltung skalieren\n\nZur Einhaltung interner Richtlinien und Vorschriften ist es wichtig, über genaue und umfassende SBOMs zu verfügen, die Open-Source-, Drittanbieter- und unternehmenseigene Software abdecken. Um SBOMs für jede Komponente und Produktversion effektiv zu verwalten, ist ein rationalisierter Prozess für die Erstellung, Zusammenführung, Validierung und Genehmigung von SBOMs erforderlich. Die Abhängigkeitslistenfunktion von GitLab fasst bekannte Schwachstellen- und Lizenzdaten in einer einzigen Ansicht auf der GitLab-Benutzeroberfläche zusammen. Die Informationen des Abhängigkeitsdiagramms werden auch als Teil des Abhängigkeits-Scanberichts generiert. Dadurch erhalten Benutzer(innen) einen umfassenden Einblick in Abhängigkeiten und Risiken innerhalb ihrer Projekte oder in Projektgruppen. Darüber hinaus kann in der CI-Pipeline ein JSON-Artefakt im CycloneDX-Format erzeugt werden. Diese API bietet einen differenzierteren und anpassbaren Ansatz für die SBOM-Erstellung. SBOMs können über die Benutzeroberfläche, eine bestimmte Pipeline oder ein Projekt oder über die GitLab-API exportiert werden.\n\n### SBOMs einlesen und zusammenführen\n\nGitLab kann SBOMs von Drittanbietern einlesen und bietet eine umfängliche Sicherheitstransparenz sowohl für Drittanbieter-Code als auch für eingebundene Open-Source-Software. Mit GitLab kannst du einen CI/CD-Job verwenden, um mehrere CycloneDX-SBOMs nahtlos in eine einzige SBOM zusammenzuführen. Durch die Verwendung implementierungsspezifischer Details in den CycloneDX-Metadaten jeder SBOM, wie etwa die Position von Build- und Sperrdateien, werden doppelte Informationen aus der resultierenden Datei entfernt. Diese Daten werden auch automatisch mit Lizenz- und Schwachstelleninformationen für die in der SBOM enthaltenen Komponenten angereichert.\n\n### Schwachstellen schneller beheben\n\nDie schnellere Entwicklung hochwertiger Produkte erfordert aussagekräftige Sicherheitsergebnisse, damit Entwickler(innen) die kritischsten Schwachstellen beheben können. GitLab hilft bei der Sicherung deiner Bereitstellungskette, indem es nach Schwachstellen im Quellcode, in Containern, Abhängigkeiten und laufenden Anwendungen sucht. GitLab bietet einen umfassenden Sicherheitsscanner mit Funktionen für statische Anwendungssicherheitstests (SAST), dynamische Anwendungssicherheitstests (DAST), Containerscans und Softwarekompositionsanalysen (SCA), um dich umfassend vor neuen Bedrohungen zu schützen. Um Entwickler(innen) und Sicherheitsingenieur(innen) zu helfen, Schwachstellen besser zu verstehen und effizienter zu beheben, bietet GitLab Duo Vulnerability Explanation, eine KI-gestützte Funktion. Sie erläutert eine bestimmte Schwachstelle, wie sie ausgenutzt werden kann und empfiehlt vor allem, wie die Schwachstelle zu beheben ist. In Kombination mit GitLab Duo Vulnerability Resolution können DevSecOps-Teams Schwachstellen mit nur wenigen Klicks intelligent identifizieren, analysieren und beheben.\n\nDie Plattform unterstützt auch die Erstellung neuer Richtlinien (und die Durchsetzung der Compliance), die auf neu entdeckten Schwachstellen basieren.\n\n### Kontinuierliche SBOM-Analyse\n\nGitLab Continuous Vulnerability Scanning löst Scans in allen Projekten aus, bei denen entweder Container-Scans, Abhängigkeits-Scans oder beide aktiviert sind, unabhängig von einer Pipeline. Wenn neue Common Vulnerabilities and Exposures (CVEs) in der National Vulnerability Database (NVD) gemeldet werden, müssen die Benutzer(innen) ihre Pipelines nicht neu starten, um die neuesten Feeds zu erhalten. GitLabs Vulnerability Research Team fügt diese CVEs zur GitLab Advisory Database hinzu – und diese Hinweise werden automatisch als Schwachstellen in GitLab gemeldet. Dadurch wird GitLabs SBOM dynamisch.\n\n### Vertrauen in SBOMs aufbauen\n\nOrganisationen, die [Compliance-Funktionen](https://about.gitlab.com/de-de/solutions/compliance/) benötigen, können GitLab verwenden, um Bestätigungen für alle Build-Artefakte zu erstellen, die vom [GitLab Runner](https://docs.gitlab.com/runner/) produziert werden. Der Prozess ist sicher, da er vom GitLab Runner selbst durchgeführt wird, ohne dass Daten an einen externen Dienst übergeben werden müssen.\n\n### Die Zukunft der SBOM-Funktionalität von GitLab\n\nDie Sicherheit der [Softwarebereitstellungskette](https://about.gitlab.com/direction/supply-chain/) bleibt aufgrund der häufigen Angriffe auf große Softwareanbieter und der gezielten Bemühungen von Angreifern im Open-Source-Ökosystem ein kritisches Thema in der Cybersecurity- und Softwareindustrie. Auch wenn sich die SBOM-Branche schnell weiterentwickelt, gibt es weiterhin Bedenken, wie SBOMs generiert werden, wie häufig diese Generierung erfolgt, wo sie gespeichert werden, wie man mehrere SBOMs für komplexe Anwendungen kombiniert, wie man sie analysiert und wie man sie für Anwendungen nutzt.\n\nGitLab hat SBOMs zu einem integralen Bestandteil seiner Softwarebereitstellungskettenstrategie gemacht und verbessert kontinuierlich seine SBOM-Fähigkeiten innerhalb der DevSecOps-Plattform, einschließlich der Planung neuer Funktionen und Funktionalitäten. Zu den jüngsten Verbesserungen gehören die Automatisierung der Bestätigungserstellung, die digitale Signierung von Build-Artefakten und die Unterstützung extern generierter SBOMs. \n\nDarüber hinaus hat GitLab innerhalb der Plattform ein solides [SBOM Maturity Model](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/) , etabliert, das Schritte wie die automatische SBOM-Generierung, das Sourcing von SBOMs aus der Entwicklungsumgebung, die Analyse von SBOMs für Artefakte und die Förderung der digitalen Signierung von SBOMs umfasst. GitLab plant auch die Einführung der automatischen digitalen Signatur von Build-Artefakten in zukünftigen Versionen.\n\n### Erste Schritte mit SBOMs\n\nDie Nachfrage nach SBOMs ist bereits hoch. Behörden empfehlen oder verlangen zunehmend die Erstellung von SBOMs von Softwareanbietern, Entwickler(innen) von Bundessoftware und sogar Open-Source-Communities. \n\nInformiere dich über die SBOM-Funktionen für GitLab Ultimate in der DevSecOps-Plattform von GitLab, um diese Anforderungen zu erfüllen.\n\n## SBOM-FAQ\n### Was ist eine SBOM?\n\nEine SBOM (Software Bill of Materials) ist eine detaillierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Software verwendet werden. Sie bietet Transparenz über die verwendeten Elemente, um Sicherheitslücken zu identifizieren und die Software-Compliance sicherzustellen. SBOMs helfen, Schwachstellen zu erkennen und Software-Supply-Chain-Risiken zu minimieren.\n\n### Warum sind SBOMs wichtig?  \n\nSBOMs sind aus mehreren Gründen entscheidend:\nEinblick in Abhängigkeiten: Das Verständnis der Bestandteile deiner Software hilft, Risiken in Verbindung mit Drittanbieter-Komponenten zu identifizieren und zu mindern.\nErhöhte Sicherheit: Mit detaillierten Einblicken in die Komponenten einer Anwendung können Organisationen Schwachstellen schnell identifizieren und beheben.\nRegulatorische Compliance: Zunehmend fordern Vorschriften und Best Practices eine SBOM für Softwarepakete, insbesondere im öffentlichen Sektor.\nEffiziente Entwicklung: Entwickler(innen) können auf eine SBOM zurückgreifen, um Einblicke in verwendete Bibliotheken und Komponenten zu erhalten, was Zeit spart und Fehler im Entwicklungszyklus reduziert.\n\n### Welche Standards werden für den SBOM-Datenaustausch verwendet?\n\nEs gibt zwei vorherrschende Standards:\n\n- CycloneDX: CycloneDX ist für seine benutzerfreundliche Herangehensweise bekannt, die es ermöglicht, komplexe Beziehungen zwischen Softwarekomponenten zu vereinfachen und spezielle Anwendungsfälle zu unterstützen. Der Standard ist erweiterbar und eignet sich gut für zukünftige Anforderungen.\n- SPDX: Ein weiteres weit verbreitetes Framework für den SBOM-Datenaustausch, das detaillierte Informationen über die in der Softwareumgebung enthaltenen Komponenten bereitstellt.\n\nGitLab verwendet speziell CycloneDX für die SBOM-Generierung, da es aufgrund seiner Präskriptivität und Erweiterbarkeit gut für zukünftige Anforderungen geeignet ist.\n\n### Wie geht GitLab mit SBOMs um?\n\nGitLab legt besonderen Wert auf die Erstellung dynamischer SBOMs, die:\nAutomatisch generiert werden: So wird sichergestellt, dass stets aktuelle Informationen über die Softwarezusammensetzung vorliegen.\nIn Tools integriert sind: SBOMs werden mit Sicherheits-Scanning-Tools verbunden, um umfassende Risikobewertungen zu ermöglichen.\nEinfach zu verwalten sind: GitLab unterstützt die Einlesung und das Zusammenführen von SBOMs für eine umfassende Analyse.\nKontinuierlich analysiert werden: Die Plattform bietet fortlaufende Scans von Projekten, um neu auftretende Schwachstellen frühzeitig zu erkennen.\n\n### Wie kann ich SBOMs in meinem Unternehmen implementieren?\n\nDie steigende Nachfrage nach SBOMs spiegelt die zunehmende Bedeutung von Softwaresicherheit und Integrität der Lieferkette wider. Für Unternehmen, die bereit sind, SBOMs einzuführen, bietet das Ultimate-Paket von GitLab eine robuste Plattform zur Erstellung und Verwaltung von SBOMs innerhalb eines DevSecOps-Workflows. Durch den Einsatz der GitLab-Tools können Teams die Einhaltung von Vorschriften gewährleisten, die Sicherheit verbessern und Entwicklungsverfahren optimieren.\n\n[\nTeste GitLab Ultimate kostenlos.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/blog/&glm_content=default-saas-trial)\n\n---\n\nDisclaimer \n*Dieser Blog enthält Informationen zu zukünftigen Produkten, Features und Funktionen. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Sie sollten nicht als Grundlage für Kauf- oder Planungsentscheidungen verwendet werden. Wie bei allen Projekten unterliegen die in diesem Blog erwähnten Elemente und verlinkten Seiten Änderungen oder Verzögerungen. Die Entwicklung, Veröffentlichung und das Timing von Produkten, Features oder Funktionen liegen im alleinigen Ermessen von GitLab.*\n",[837],"Sandra Gittlen","2025-04-01","2022-10-25",[841,842,843,9,187],"security","DevSecOps","performance","Erfahre, was eine Software Bill of Materials (SBOM) ist und warum sie zu einem integralen Bestandteil der modernen Softwareentwicklung geworden ist.",{"slug":846,"featured":6,"template":686},"the-ultimate-guide-to-sboms","content:de-de:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","de-de/blog/the-ultimate-guide-to-sboms.yml","de-de/blog/the-ultimate-guide-to-sboms",{"_path":852,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":853,"content":859,"config":866,"_id":868,"_type":14,"title":869,"_source":16,"_file":870,"_stem":871,"_extension":19},"/de-de/blog/what-is-docker",{"title":854,"description":855,"ogTitle":854,"ogDescription":855,"noIndex":6,"ogImage":856,"ogUrl":857,"ogSiteName":673,"ogType":674,"canonicalUrls":857,"schema":858},"So optimierst du mit Docker und GitLab deinen DevOps-Prozess","Docker Container bieten deinem Team mehr Raum für Kollaboration, kontinuierliche Integration und Kreativität. Wir zeigen dir, wie die Umsetzung klappt.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664248/Blog/Hero%20Images/AdobeStock_564261524.jpg","https://about.gitlab.com/blog/what is docker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So optimierst du mit Docker und GitLab deinen DevOps-Prozess\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":854,"description":855,"authors":860,"heroImage":856,"date":862,"body":863,"category":10,"tags":864},[861],"GitLab Germany Team","2025-02-27","# So optimierst du mit Docker und GitLab deinen DevOps-Prozess\n\nIn wenigen Jahren hat sich Docker zu einem globalen Standard entwickelt. Laut aktuellen Statistiken liegt sein Marktanteil in der Containerisierung bei über [80 %](https://6sense.com/tech/containerization/docker-market-share); fast 50 % aller Entwickler(innen) nutzen Docker; und zum Zeitpunkt des Verkaufs des Unternehmens an Mirantis [schätzte man die Zahl seiner Nutzer auf 15 Millionen weltweit](https://cloudnativenow-com.translate.goog/features/docker-inc-dev-tools-boast-15-million-users/?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=rq). Wenn du im DevOps-Bereich tätig bist, kommst du um Docker somit nicht herum.\n\nDie Vorteile von Docker sprechen für sich. Gegenüber der früher dominanten Virtualisierung läuft es sowohl stabiler als auch schneller. Es unterstützt die Kernziele von [DevOps](https://about.gitlab.com/de-de/topics/devops/), erhöht signifikant die Transparenz eines Projekts und spart Ressourcen ein.\nEntwickler(innen), die mit GitLab arbeiten, können aufgrund einer nahtlosen Integration Docker-Container für sich nutzen. Gleichzeitig gleicht GitLab einige der Nachteile, die bei der Verwendung von Docker auftreten können, aus. Diese enge Verzahnung optimiert die Vorteile beider Anwendungen und bringt deinen DevOps-Prozess weiter nach vorne.\nIn diesem Artikel zeigen wir dir, wie das funktioniert und wie du Docker und GitLab am besten miteinander kombinierst. Aber fangen wir mit einer kurzen Definition an.\n\n## Was ist Docker?\n\nDocker ist eine Plattform zur Containerisierung. Dahinter steht ein neuer Ansatz, über Anwendungen nachzudenken.\nIn der traditionellen „monolithischen” Sichtweise ist das Programm wie eine Art Geschichte angelegt, mit einem Anfang, einem Ende und einer stringenten inneren Logik. Weil alle Funktionen geteilten Annahmen unterworfen sind, lassen sich einzelne Komponenten nur schwer voneinander trennen und ausgliedern.\nBei Docker bildet jede logische Funktion eines Programms eine eigenständige Anwendung, die für sich steht und isoliert ausgeführt werden kann. Dieser Ansatz ist eher modular, die einzelnen Anwendungen können in immer neuen Kombinationen zusammengesetzt und miteinander verzahnt werden. Man könnte sagen: Docker ist kybernetisch, weil es von Systemen, Regelkreisen und Kontrollmechanismen bestimmt wird.\nDocker-Container enthalten alles, was eine Anwendung zur Ausführung benötigt. Mit Docker kannst du Container definieren und anlegen, im Rahmen der Entwicklung plattformunabhängig testen und verbessern und unkompliziert ausliefern.\nDank seiner führenden Rolle ist Docker zu einem Synonym für Containerisierung geworden. Lange bevor Docker aber den Entwicklungsprozess revolutionierte, nutzten DevOps-Teams einen sehr ähnlichen Ansatz namens Virtualisierung.\n\n## Virtualisierung: Die Vorstufe der Containerisierung\n\nDer Grundgedanke der Virtualisierung stammt bereits aus den 1960ern, als IBM an Lösungen arbeitete, die es Anwendern ermöglichen sollten, auf nur einem Rechner mehrere Betriebssysteme laufen zu lassen. Virtualisierung in DevOps nimmt diesen Gedanken zum Ausgangspunkt dafür, Programme so anzulegen und zu verpacken, dass sie unabhängig von den spezifischen Gegebenheiten des Hosts laufen.\n\nJede dieser „virtuellen Maschinen” (VM) bringt alle Anwendungen mit, die für die Ausführung benötigt werden, einschließlich eines eigenen Betriebssystems. Damit können Projektteilnehmer(innen) die Anwendung nutzen, ohne sich mit Kompatibilitätsproblemen auseinandersetzen zu müssen.\n\nVirtuelle Maschinen sind extrem stabil, sicher und werden auch heute noch in vielen Bereichen bevorzugt genutzt. Allerdings haben sie zwei Nachteile:\n\n- Das in jeder VM enthaltene Betriebssystem belastet den Speicher und beeinträchtigt die Systemleistung des Hosts.\n- Der„Hypervisor” einer VM, der für den Betrieb benötigt wird, Ressourcen. Docker ist kein Ersatz für virtuelle Maschinen. Es soll sie vielmehr optimieren und ihre Nachteile so weit wie möglich beseitigen.\n\n## Wie Docker die Nachteile virtueller Maschinen ausgleicht\n\nContainer sind virtuellen Maschinen sehr ähnlich, betonen aber den Aspekt der Isolation über den der Autonomie (wir werden darauf noch genauer eingehen). In ihnen sind ebenfalls alle relevanten Daten und Apps enthalten. Das ermöglicht eine Ausführung unabhängig vom Host-Betriebssystem. Der Unterschied zur Virtualisierung besteht darin, dass Docker-Container kein eigenes Betriebssystem enthalten. Sie teilen sich stattdessen den Kernel des Hosts. Das ist effizienter, schont Systemressourcen und macht Container vor allem weitaus schneller als VM.\n\nDie Vorzüge von Docker waren derart offensichtlich, dass es einen rasanten Aufstieg durchmachte. 2013 veröffentlicht, wurde es ein Jahr später Teil der Pakete von Red Hat Enterprise Linux 7.0 und openSUSE. Die Beliebtheit von Docker war zu diesem Zeitpunkt bereits so stark angewachsen, dass sich einige der größten IT-Unternehmen der Welt zusammenschlossen, um ein System zu entwickeln, mit dem sich Docker-Container besser verwalten lassen sollten. Das daraus entstandene [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/) wird bis heute zur Orchestrierung (Verwaltung) von Containern verwendet.\n\n## Docker: Grundbegriffe\n\nDas Grundkonzept von Docker Containern ist die „Isolation”. Dieses Prinzip unterscheidet sie von den grundsätzlich sehr ähnlichen virtuellen Maschinen.\nVirtuelle Maschinen bilden ein eigenständiges System, das auf keine äußeren Ressourcen angewiesen ist. Container isolieren zwar ebenfalls den größten Teil ihrer Prozesse und Anwendungen, teilen sich aber mit dem Host den Kernel. Es mag so scheinen, als seien diese Unterschiede zwischen den beiden Begriffen eher gering. In der Praxis aber können sie recht große Konsequenzen haben.\n\nDer Lebenszyklus von Docker-Containern beginnt mit sogenannten „Images”. Was ist ein Docker-Image? In ihm ist gewissermaßen der „Bauplan” (oder auch das „Rezept”) enthalten, wie die ausführbaren Docker-Container zusammengestellt werden sollen. Entwickler(innen) „schreiben” den Bauplan in ein Docker-File, zu dem sie Informationen in Schichten („Layern”) sowie die erforderlichen Daten hinzufügen. Eine der entscheidenden Eigenschaften von Docker besteht darin, dass es ein Standardformat für diese Images bereitstellt.\n\nImages werden in der „Registry\" gespeichert und verwaltet. Hier können Änderungen der verschiedenen Versionen nachvollzogen werden, die ein Image bis zum heutigen Stand durchlaufen hat. GitLab bietet ebenfalls eine solche Registry an, von der aus du deine Programme direkt testen und optimieren kannst. Sobald ein Docker-Image mittels seiner Runtime zur Ausführung kommt, entsteht ein Container. Container sind somit das aktivierte Gegenstück eines Images. Sie sind sofort lauffähig und müssen nicht erst „hochgefahren” werden.\n\n## Wie funktioniert Docker im Rahmen von DevOps?\n\nGeschwindigkeit und Effizienz sind zweifelsohne wichtige Aspekte in allen Wirtschaftsbereichen. Im DevOps aber sind sie geradezu essenziell. Dies erklärt die besonders hohe Wertschätzung, die Docker in der Entwicklung genießt. Doch enden die Stärken von Docker dort nicht. Vielmehr kann die Containerisierung alle zentralen Aspekte von DevOps unterstützen:\n\n- Kollaboration: Container können auf jedem Rechner mit denselben Funktionalitäten gestartet werden. Das reduziert Probleme bei der plattformübergreifenden Zusammenarbeit, auch innerhalb eines Teams.\n\n- Kontinuierliche Verbesserung: Als Teil der Kollaboration können immer wieder sehr einfach neue Images geschrieben und neue Container generiert werden, die Optimierungen enthalten. So wird der Prozess der kontinuierlichen Verbesserung deutlich vereinfacht.\n\n- Kundenorientierung: Weil Docker-Container einfach und schnell auf allen Systemen laufen, kann der aktulle Stand eines Projekts jederzeit mit den Kund(inn)en geteilt werden. Damit kann man sich immer wieder wertvolles Feedback holen und das Produkt voll und ganz auf die Kundenwünsche ausrichten.\n\n- Lernen aus Fehlern: Einen Fehler in einer Entwicklungsumgebung zu beheben, war früher aufwändig und komplex. Mit Docker hingegen werden diese Änderungen zu einem selbstverständlichen Teil des Prozesses. Dies führt zu einer Arbeitsphilosophie, bei der mehr ausprobiert werden darf, neue Ideen stets willkommen sind und das Projekt durch Fehler gewinnt, statt durch sie aufgehalten zu werden.\n\n## DevSecOps: Wie sicher sind Docker-Container?\n\nContainer opfern gegenüber virtuellen Maschinen ein wenig Sicherheit zugunsten einer besseren Performance. Virtuelle Maschinen sind dank ihres mitgelieferten Betriebssystems vollständig unabhängig vom Host. Docker allerdings teilt sich den Kernel. Das bedeutet in Hinblick auf die Sicherheit, dass:\n\n- Sicherheitslücken im Kernel auch Auswirkungen auf die Container des Hosts haben können.\n- Sicherheitsprobleme mit einem Container auf alle Container übergreifen können.\n- Sicherheitslücken im Kernel das gesamte Host-System infizieren können - und von dort aus dann die Container.\n\nHinzu kommt, dass es bei Docker mehrere potentielle Stellen für Sicherheitsrisiken gibt. So gibt es nicht nur ein einziges Image, sondern mehrere Instanzen, den Docker-Daemon (der im Hintergrund die Anfragen an Docker verarbeitet), die Cloud in der der Server gehostet wird sowie verschiedene Netzwerke, welche die Kommunikation zwischen den Containern orchestrieren. Im Prinzip muss jede dieser potenziellen Schwachpunkte individuell gesichert werden.\n\n## Wie du die Sicherheit von Docker verbessern kannst\n\nZum Glück gibt es einige einfach umzusetzende Punkte, mit denen du den Einsatz von Docker in deinen Entwicklungsprojekten vor Eingriffen schützen kannst:\n\nNutze die Möglichkeit, Ressourcen zu beschränken. Mit der „Ressource Quota” schränkst du den Zugriff auf Speicher und CPU gezielt ein. Das ist bereits deswegen sinnvoll, da es die Performance des gesamten Container-Systems optimiert. Darüber hinaus blockiert es auch die Möglichkeit, dass ein „infizierter” Container die gesamte Systemleistung reduziert.\n\nVermeide es, die Zugriffsrechte zu umgehen, indem du einen Container als „root” laufen lässt. Das mag in manchen Situationen zwar komfortabler sein, sobald du aber geschützte Testumgebungen verlässt und kollektiv an einem Projekt arbeitest, solltest du der Datensicherheit stets oberste Priorität zuweisen. Stelle sicher, dass deine Registry ausreichend gesichert ist.\nUm die Sicherheit deiner Projekte weiter zu erhöhen, bietet sich GitLab als ein hervorragendes Instrument an, um Container im Rahmen von DevSecOps sicherer zu machen.\n\n## Welche Rolle spielt Docker für GitLabs DevSecOps-Funktionalität?\n\nSicherheitsaspekte spielen für GitLab eine zentrale Rolle: Der Schutz deiner Daten ist nicht von der Entwicklung zu trennen, sowohl was die Arbeit innerhalb des Teams angeht, als auch die Absprache und kontinuierliche Verbesserung mit Kund(inn)en. GitLab nutzt Docker-Container, um diesen Schutz jederzeit zu gewährleisten.\n\nEine der zentralen Funktionen von GitLab ist das [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/). Es basiert auf dem Gedanken, dass Sicherheits-Schwachpunkte bereits im Docker-Image ihren Ursprung haben können, oft in der Form von Abhängigkeiten, die du nicht selbst geschrieben hast, sondern aus externen Quellen importierst. Du kannst entweder nur die Container scannen oder die Abhängigkeiten - wobei wir dir für optimalen Schutz stets beides empfehlen.\n\nAuf einer noch grundlegenderen Ebene unterstützen selbstverständlich auch die allgemeinen Sicherheits-Features von GitLab die Verwendung von Docker-Images und Docker-Containern. Eine zentrale Funktion ist beispielsweise Auto-Remediation, eine intelligente kollaborative Anwendung, die dir bereits beim Entwickeln Vorschläge zur Fehlervermeidung und zu effizienterem Code macht.\n\n## 3 Docker Herausforderungen und wie GitLab bei der Lösung hilft\n\nDocker ist ein bestechendes Konzept, das die Arbeit für Millionen Entwickler(innen) täglich besser und einfacher macht. Seine Flexibilität und Individualisierung aber stellen Nutzer(innen) zugleich vor einige Herausforderungen.\nSehen wir uns drei zentrale Herausforderungen näher an - und wie GitLab dabei helfen kann, sie zu bewältigen.\n### Standardisierung:\n\nDocker ist ein offenes Konzept, das Entwickler(innen) höchst individuelle Lösungswege eröffnet. Wenn aber in Teams verschiedene Mitglieder an einem Projekt arbeiten und dabei sehr unterschiedliche Coding-Stile benutzen oder teilweise sogar widersprüchliche Anweisungen geben, kann es zu Konflikten kommen.\n\nGitLab bietet Standardisierungsoptionen an, beispielsweise durch [CI/CD-Templates](https://docs.gitlab.com/ee/ci/examples/), mit denen das gesamte DevOps-Team arbeiten kann. Shared Runners ermöglichen anschließend das Testen des aktuellen Standes in einer von dir vorgegebenen oder standardisierten Umgebung.\nAll dies ist gerade bei großen Projekten eine unermessliche Hilfe, da dabei bis zu tausende Container gleichzeitig miteinander abgestimmt werden müssen.\n\n### Ressourcenoptimierung:\n\nDocker Container nutzen Ressourcen in der Regel weitaus schonender als virtuelle Maschinen. Wie oben angesprochen kann sich die Gesamtzahl aller Container aber zu riesigen Zahlen summieren.\nMit verschiedenen Funktionen sorgt GitLab dafür, dass gerade speicherintensive Jobs optimiert- und gewisse Container zeitweise deaktiviert werden, um die Systemleistung zu verbessern.\n\n### Orchestrierung:\n\nDas wichtigste Thema in der Containerisierung ist heute zweifelsohne die Orchestrierung. Wenn du sehr viele Container nutzt, die zusammen mit den Anwendungen auf verschiedenen Servern untergebracht sind und zu unterschiedlichen Zeiten und in immer neuen Konstellationen miteinander kombiniert werden sollen, kommt es leicht zu Engpässen, Ausfällen oder Fehlern.\nKubernetes ist die komplexe Lösung für diese Probleme und GitLab ist direkt mit Kubernetes abgestimmt. Du kannst mit GitLab und Kubernetes die gesamte [CI/CD](https://about.gitlab.com/topics/ci-cd/)-Pipeline automatisieren und dabei dein System optimieren.\n\n## FAQ\n\n### Was ist Docker Compose?\n\nDocker Compose ist ein Tool, das dir bei der Orchestrierung hilft. Es findet in Multi-Container-Umgebungen Anwendung. In diesem Artikel haben wir bisher angenommen, dass eine Anwendung einem Container entspricht. Das ist zur Erklärung der grundlegenden Zusammenhänge sinnvoll. In der Praxis aber ergeben sich zumeist weitaus komplexere Sachverhalte.\n\nEin typischer Fall besteht darin, dass eine Anwendung mehrere Container benötigt, die zu unterschiedlichen Zeitpunkten gestartet und beendet werden. Diesen Ablauf präzise zu definieren sowie dabei die einzelnen Container-Aktionen aufeinander abzustimmen und im Rahmen eventueller Fehler oder Probleme zu optimieren, erweist sich als komplex. Wie [Data Scientist](https://datascientest.com/de/docker-compose-von-der-installation-bis-zur-bereitstellung-von-anwendungen) betont, liegt die Schwierigkeit darin, die verschiedenen Container „separat auszuführen, während sie gleichzeitig miteinander kommunizieren.”\n\n[Docker Compose](https://forum.gitlab.com/t/how-to-use-docker-compose-in-gitlab-ci/97671) unterstützt die Orchestrierung bei genau diesen Szenarien. Entwickler(innen) können in einer speziellen Datei mit einer laut [Heise](https://www.heise.de/hintergrund/Multi-Tier-Applikationen-mit-Docker-Compose-Machine-und-Swarm-3014669.html?seite=3) „simplen Syntax” alle Aktionen festlegen, die beim Aufbau und der Interaktion der Container zum Tragen kommen. Zurecht gilt Docker Compose deswegen als „ein mächtiges Werkzeug für den Einsatz und die Verwaltung von Multi-Container-Anwendungen”.\n\n### Wie funktioniert die Continuous Integration von Docker in GitLab?\n\nDocker wirkt sich positiv auf alle drei Prinzipien von CI/CD aus, vom kontinuierlichen Deployment bis hin zur kontinuierlichen Lieferung (delivery). Bei der kontinuierlichen Integration aber (Continuous Integration) sind die Vorteile ganz besonders offensichtlich.\nBei der Continuous Integration (CI) werden sämtliche branches (Enwticklungszweige) so oft wie möglich mit der main branch (dem Hauptentwicklungszweig) zusammengeführt. Dadurch haben alle Mitglieder eines Teams stets Zugriff auf den aktuellen Stand des Projekts und eine Änderung an einem Teil der Anwendung kann direkt auf seine Auswirkungen auf andere Bereiche hin überprüft werden. So wird vermieden, dass möglicherweise schwerwiegende Fehler im Zusammenspiel erst kurz vor Veröffentlichung des Produkts entdeckt werden.\n\nContainer sind das optimale Instrument, um Continuous Integration in deiner CI/CD-Pipeline zu realisieren. In ihrer containerisierten Form können Anwendungen schnell und in verschiedenen Umgebungen getestet werden. Das Feedback lässt sich unmittelbar auswerten und bewerten. Anschließend machst du Änderungen für alle branches durch das Definieren eines neuen, aktualisierten Images sichtbar und überprüfbar.\nZusammenfassend lässt sich sagen, dass Container die Integration im CI/CD-Prozess robuster und zuverlässiger gestalten und somit die Basis für erfolgreiches Deployment und Delivery bereiten.\n\n### Wann empfiehlt es sich, mit virtuellen Maschinen zu arbeiten statt mit Docker?\n\nDocker ist eine Weiterentwicklung virtueller Maschinen. Daraus sollte aber nicht der Schluss gezogen werden, dass es sich bei VM um eine veraltete oder gar überholte Technologie handelt. Vielmehr bleiben die Vorzüge dieses Modells auch in Zukunft bestehen.\n[Computer Weekly](https://www.computerweekly.com/de/ratgeber/Sechs-Anwendungsfaelle-fuer-die-sich-Docker-eignet) hat drei Situationen ermittelt, in denen Virtualisierung die bessere Option darstellt:\n\n__- Bei besonders sensiblen Daten:__ hier kann ein Höchstmaß an Isolierung erforderlich sein. Da sie mit dem Host in der Regel in keinem direkten Austausch stehen, sind virtuelle Maschinen hier zweifelsfrei die sicherste Wahl.\n\n__- Bei grafikintensiven Anwendungen__ lassen sich zwar grundsätzlich auch über Container verwenden, in der Regel aber ist Virtualisierung hier einfacher in der Handhabung.\n__In kleinen Teams__– wenn du nur selten Änderungen an deinen Anwendungen vornimmst, sind virtuelle Maschinen eine hervorragende Alternative, weil sie leichter zu verwalten sind.\n\n### Läuft Docker auch auf Windows und MacOs?\n\nDocker kann auf allen Hosts laufen, die Docker unterstützen. Tatsächlich aber ist die Plattform vor allem auf eine Linux-Nutzung hin optimiert.\nDie originäre Version von Docker ist so ausgelegt, dass sie die Funktionalitäten eines Linux-Kernels mit dem Host teilen kann. In diesem Umfeld funktionieren Container am effizientesten und die Vorteile der Containerisierung kommen voll zur Geltung.\n\nUm Docker auch für Windows und MacOs nutzbar zu machen, stehen entsprechende Docker-Versionen zur Verfügung. Diese aber geben das strenge Isolierungs-Prinzip auf und fügen eine virtuelle Maschine hinzu, welche eine Nutzung auf Linux-fremden Umgebungen erlaubt.\nAuch, wenn Docker unter Windows und MacOs nicht ganz so effizient ist wie unter Linux, ist die benötigte VM sehr leicht und schränkt Geschwindigkeit und Speicher nicht so stark ein wie eine vollständige virtuelle Maschine. Die gelegentliche Behauptung, Docker lasse sich nur unter Linux sinnvoll verwenden, ist deswegen zweifelsfrei sehr radikal.\n",[865,9],"DevOps",{"slug":867,"featured":6,"template":686},"what-is-docker","content:de-de:blog:what-is-docker.yml","What Is Docker","de-de/blog/what-is-docker.yml","de-de/blog/what-is-docker",{"_path":873,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":874,"content":880,"config":888,"_id":890,"_type":14,"title":891,"_source":16,"_file":892,"_stem":893,"_extension":19},"/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"ogTitle":875,"schema":876,"ogImage":877,"ogDescription":878,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":879,"title":875,"canonicalUrls":879,"description":878},"Was ist Git? | Einfach erklärt | Praxis-Tutorial","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist Git? Der ultimative Leitfaden zur Rolle und Funktionalität von Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-11-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673991/Blog/Hero%20Images/Git.jpg","Wir zeigen dir, was hinter Git steckt und wie du das Tool optimal nutzt. ✓ Definition ✓ Bedeutung ✓ Funktionen ✓ Vorteile ✓ Befehle ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"heroImage":877,"body":881,"authors":882,"updatedDate":883,"date":884,"title":885,"tags":886,"description":887,"category":10},"Git ist ein unverzichtbares Tool in der modernen Softwareentwicklung. In diesem umfassenden Leitfaden erklären wir detailliert, was das Git-Tool ist, welche Rolle es bei der Versionsverwaltung von Quellcode spielt und wie es funktioniert. Egal, ob du Anfänger(in) oder Expert(in) bist: Dieser Leitfaden vermittelt dir ein tiefes Verständnis von Git und seinen vielen Funktionen.\n\n## Inhalt - Alles über Git\n\n- [Was ist Git?](#was-ist-git%3F)\n- [Was ist Versionskontrolle?](#was-ist-versionskontrolle%3F)\n- [Was sind die Funktionen von Git?](#was-sind-die-funktionen-von-git%3F)\n- [Visualisierung deines Projektverlaufs](#visualisierung-deines-projektverlaufs)\n- [Mehr Autonomie für Teams](#mehr-autonomie-f%C3%BCr-teams)\n- [Optimierung von Entwicklungs-Workflows](#optimierung-von-entwicklungs-workflows)\n- [Was sind die Vorteile von Git?](#was-sind-die-vorteile-von-git%3F)\n- [Was sind die Hauptbefehle von Git?](#was-sind-die-hauptbefehle-von-git%3F)\n- [Git und GitLab](#git-und-gitlab)\n- [FAQ zu Git](#faq-zu-git)\n\n## Was ist Git?\n\nGit ist ein Tool zur Versionskontrolle, das sich in der Welt der Softwareentwicklung schnell zu einem Muss entwickelt hat. Da mit Git Änderungen an Projekten genauestens verfolgt werden können, ist es ein unverzichtbares Tool für Entwickler(innen), um ihre Projekte effizient zu verwalten. Damit es für alle, die in der Softwareentwicklung weiterkommen möchten, unverzichtbar, Git zu beherrschen.\n\n### Was ist Versionskontrolle?\n\n[Versionskontrolle](https://about.gitlab.com/de-de/topics/version-control/) ermöglicht es dir, Änderungen am Quellcode einer Software zu verfolgen. Daher besteht jede gelieferte Softwareversion aus einer Reihe bestimmter Versionen jeder ihrer Komponenten und Quellcodedateien. Ein Icon wurde beispielsweise nur zwei Mal geändert, während eine Codedatei im Laufe der Zeit dutzende Änderungen durchgemacht hat.\n\n## Was sind die Funktionen von Git?\n\nIn der Entwicklung ist es wichtig, Änderungen am Quellcode einer Software rigoros zu verwalten. Ohne diese kann unmöglich sichergestellt werden, dass Entwicklungsteams konsistent und zuverlässig arbeiten können. Ein fein abgestimmtes Änderungsmanagement kann es auch einfacher machen, die Ursache eines Problems zu identifizieren. Außerdem verringert es das Risiko von Konflikten und das Überschreiben von Dateien. In der Tat erleichtert und rationalisiert Git die Versionsverwaltung von Software genau zu diesem Zweck.\n\nUm Git und seine Funktionsweise besser zu verstehen, haben wir hier einige Hauptfunktionen angeführt, mit denen die Quellcodeverwaltung sowie de Zusammenarbeit zwischen Teams auf einfache Weise optimiert werden kann.\n\n### Visualisierung deines Projektverlaufs\n\nIn der Welt der Softwareentwicklung ist der [Commit-Verlauf](https://about.gitlab.com/blog/keeping-git-commit-history-clean/) ein Grundpfeiler, um den Projektfortschritt auf Git zu verfolgen. Daher bietet Git Entwickler(inne)n einen detaillierten Gesamtverlauf aller Änderungen am Quellcode.\n\nFür jeden neuen Commit wird Folgendes erfasst:\n\n* Spezifische Änderungen an Projektdateien\n* Eine erläuternde Nachricht des Entwicklerteams, das die Änderung vorgenommen hat\n\nDiese Elemente tragen dazu bei, die Kommunikation und den Auftrag des Entwicklungsteams zu verbessern, sodass es die Einzelheiten jeder Codeänderung schneller verstehen kann.\n\nMit diesem Verlauf kannst du nicht nur die Entwicklung des Projekts überwachen, sondern auch zurückgehen und Teile der Änderung rückgängig machen oder auch nur einen Teil der Änderungen von einem Branch zu einem anderen übertragen. Diese Funktion ist daher entscheidend, um die Transparenz, Konsistenz und Qualität des Quellcodes eines Projekts in Git zu wahren. Außerdem wird dadurch die Zusammenarbeit im Entwicklungsteam gefördert und die betriebliche Effizienz bei der Problembehebung gesteigert.\n\nSieh dir in unserem Tutorial an, [wie du deinen ersten Git-Commit erstellst](https://docs.gitlab.com/ee/tutorials/make_first_git_commit/).\n\n### Mehr Autonomie für Teams\n\nEin weiteres wesentliches Merkmal des Git-Tools ist die [verteilte Entwicklung](https://git-scm.com/about/distributed). Dank seiner dezentralen Struktur ermöglicht es Git den Teams, gleichzeitig am selben Projekt zu arbeiten. Jedes Teammitglied hat seine eigene Kopie des Projekts, in der Änderungen versioniert werden können. Dadurch können sie autonom an bestimmten Funktionen arbeiten, ohne dass es zu Konflikten oder Überschreibungen kommt. Dieser Ansatz bietet den Entwickler(inne)n große Flexibilität, denn so können sie verschiedene Ideen ausarbeiten oder mit neuen Funktionen experimentieren, ohne die Arbeit ihrer Kolleg(inn)en zu stören.\n\nDie verteilte Entwicklung verbessert auch die Resilienz gegenüber Serverausfällen. So hat jede Person im Falle eine Ausfalls eine Kopie, mit der sie offline weiterarbeiten kann. Die Änderungen können dann synchronisiert werden, sobald der Server wieder verfügbar ist. Dadurch wird verhindert, dass die Arbeit des Entwicklungsteams unterbrochen wird und es zu Einschränkungen der Betriebsteams kommt.\n\n### Optimierung von Entwicklungs-Workflows\n\nEine der leistungsstärksten Funktionen von Git ist die Möglichkeit, [Branches und ihre Zusammenführer zu verwalten (Branching und Zusammenführen)](https://git-scm.com/about/branching-and-merging). Dadurch können Teams parallel auf kooperative und organisierte Weise arbeiten. Jede neue Ergänzung am Code und jeder Bugfix kann unabhängig getestet und entwickelt werden, um sicherzustellen, dass er zuverlässig ist. Die Entwickler(innen) können die Änderungen dann einfach in den Haupt-Branch des Projekts zusammenführen.\n\nDurch diesen Ansatz können Teams die Entwicklung des Codes nachverfolgen, einfach und effizient zusammenarbeiten, Konflikte zwischen verschiedenen Versionen reduzieren und die kontinuierliche Integration der entwickelten Funktionen sicherstellen.\n\nMit diesen beiden Funktionen können Teams kontinuierlich und im Sinne der Agile-Methodik Projekte entwickeln und regelmäßig neue Codeversionen bereitstellen. Diese Vorgehensweise erleichtert das Change Management deutlich und senkt gleichzeitig das Fehlerrisiko.\n\n## Was sind die Vorteile von Git?\n\nUm Git wirklich zu verstehen, musst du all die Vorteile kennen, die es deinen Entwicklungsteams bietet:\n\n* **Dezentralisierte Versionsverwaltung:** Mit Git haben alle Entwickler(innen) eine vollständige Kopie des Projektverlaufs und können dadurch unabhängig arbeiten.\n* **Ein Tool für Sicherheit:** Anders als andere Tools zur Versionskontrolle wurde Git mit dem Gedanken entwickelt, die Integrität aller Elemente im Repository mit einem kryptografischen Secure Hash Algorithm (aktuell SHA1 und [SHA-256](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/)) sicherzustellen. Dieser Algorithmus soll den Code und den Verlauf des Projekts vor Änderungen – egal, ob böswillig oder nicht – schützen. Darüber hinaus kann jeder Commit (also jede Erstellung einer neuen Version) automatisch signiert werden (GPG), um die Nachvollziehbarkeit zu gewährleisten. Dies macht Git zu einem besonders sicheren Tool, das die Integrität und Authentizität deines Quellcodes und seines Verlaufs sicherstellt.\n* **Ein schnelles und effektives Tool:** Das Git-Tool wurde entwickelt, um die Effizienz bei der Entwicklung zu maximieren. Dank seiner Geschwindigkeit können Entwickler(innen) komplexe Vorgänge wie Commits, Branching und das Zusammenführen äußerst rasch durchführen, und das sogar in großen Codebases. Es sorgt auch für einen minimalen Fingerabdruck auf der Festplatte und beim Netzwerkaustausch. Diese Effizienz führt zu kürzeren Reaktionszeiten bei Backups, Beratungen und Änderungen am Projektverlauf.\n* **Mehr Flexibilität beim Arbeiten:** Git unterstützt eine Vielzahl an Entwicklungs-Workflows. Egal, ob du zentralisierte Entwicklungsmodelle oder eher einen linearen Ansatz bevorzugst: Git lässt sich einfach anpassen. Diese Fähigkeit, verschiedene Workflows zu verwalten, bietet Teams zahlreiche Optionen für ihre Arbeitsweise.\n* **Einfache Integration:** Git zeichnet sich dadurch aus, dass es sich in eine ganze Reihe bestehender Entwicklungstools und -plattformen integrieren lässt. Durch diese breite Kompatibilität können Teams die besten DevSecOps-Tools und -Praktiken nutzen und dadurch ihre Projekte effizienter verwalten.\n* **Ein weithin anerkanntes Open-Source-Projekt:** Ein weiterer bedeutender Vorteil von Git ist, dass es ein Open-Source-Projekt ist und von einer dynamischen, engagierten Community unterstützt wird, wodurch die kontinuierliche Weiterentwicklung sichergestellt wird. Durch diese aktive Beteiligung von Einzelpersonen und Unternehmen in der Git-Community kommen im Rahmen kontinuierlicher Updates regelmäßig neue Funktionen und Verbesserungen hinzu.\n\n## Was sind die Hauptbefehle von Git?\n\nDas Open-Source-Projekt Git bietet eine Vielzahl an Befehlen, um die Teamarbeit zu erleichtern.  \nHier sind einige der am häufigsten verwendeten Befehle.\n\n* **git init:** Ein neues Git-Repository initialisieren.  \n* **git clone \\[url\\]:** Ein vorhandenes Repository klonen.  \n* **git add \\[file\\]:** Eine Datei zum Index hinzufügen.  \n* **git commit:** Die vorgenommenen Änderungen validieren.  \n* **git commit \\-m \"message\":** Änderungen mit einer Nachricht validieren.  \n* **Git-Status:** Den Status der Dateien im Arbeitsverzeichnis anzeigen.  \n* **git push:** Änderungen an das Remote-Repository senden.  \n* **git pull:** Änderungen aus dem Remote-Repository abrufen und sie mit dem lokalen Repository zusammenführen. Alles über git pull erfährst du in diesem umfangreichen Artikel [git fetch vs. git pull](https://about.gitlab.com/de-de/blog/git-pull-vs-git-fetch-whats-the-difference/).\n\nDiese Befehle sind zwar unerlässlich, um mit Git loszulegen – es gibt aber noch viele andere Befehle. Du findest sie in der [Liste der Git-Befehle](https://git-scm.com/docs).\n\n## Git und GitLab\n\nGitLab ist eine kollaborative Open-Source-Entwicklungsplattform, die alle Phasen des DevSecOps-Lebenszyklus abdeckt und einen Git-Server für eine effiziente Teamzusammenarbeit bietet.\n\nNeben der Quellcodeverwaltung bietet GitLab ein umfassendes Programmpaket für kontinuierliche Integration und Verteilung, Verwaltung von Ergebnissen, Sicherheits- und Vorfallmanagement sowie Nachvollziehbarkeit, Aufgabenplanung und -nachverfolgung in Echtzeit, Bereitstellungsüberwachung, Software-Versionsverwaltung und die zugehörigen Dokumente.\n## FAQ zu Git\n\n### Warum sollte man Git verwenden?\n\nBei Git dreht sich alles um Effizienz. Durch das dezentrale System von Git, das auf Branching und Funktionen zum Zusammenführen basiert, können Entwicklungsteams am selben Projekt arbeiten, ohne sich gegenseitig zu stören und (was noch wichtiger ist) ohne Versionskonflikte zu erschaffen.\n\n### Ist Git Software?\n\nGit ist ein Open-Source-Projekt. Daher ist es kostenlos und für alle offen. Du musst jedoch [Git](https://docs.gitlab.com/ee/topics/git/how_to_install_git/) auf deinem Gerät installieren, bevor du mit der Arbeit beginnen kannst.\n\n### Was ist ein Branch in Git?\n\nIn Git ist ein Branch ein Zeiger auf einen Änderungsverlauf. Somit verweist jeder Haupt-Branch auf den letzten Commit, der auf ihm ausgeführt wurde. Es ist daher möglich, viele parallele Branches zu haben, die alle ihren eigenen Verlauf, jedoch die gleiche Wurzel haben.\n\n### Was ist ein Commit?\n\nIn Git ist ein Commit ein Datensatz von Änderungen am Quellcode einer Software. Jeder Commit wird von einer erläuternden Nachricht begleitet, die den Gesamtverlauf aller Änderungen dokumentiert. Dies erleichtert die Nachverfolgung von Projekten. Außerdem gibt es immer die Möglichkeit, bei Problemen zu früheren, funktionierenden Versionen zurückzukehren.\n\n### Was sind die Vorteile von Branches in Git?\n\nDurch die Entwicklung von Funktionen in Branches können Entwickler(innen) gleichzeitig an mehreren unterschiedlichen Funktionen arbeiten. Darüber hinaus wird dadurch vermieden, dass der Haupt-Branch mit instabilem Code kompromittiert wird. Außerdem ist die Implementierung von Branches in Git deutlich leichter als in anderen Versionskontrollsystemen.",[724],"2025-07-10","2024-11-14","Was ist Git? Der ultimative Leitfaden",[682,842,9],"Möchtest du deine Projekte mit Git umsetzen? Entdecke alle Vorteile und Funktionen von Git in unserem umfassenden Guide.",{"slug":889,"featured":6,"template":686},"what-is-git-the-ultimate-guide-to-gits-role-and-functionality","content:de-de:blog:what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","What Is Git The Ultimate Guide To Gits Role And Functionality","de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"_path":895,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":896,"content":902,"config":910,"_id":912,"_type":14,"title":913,"_source":16,"_file":914,"_stem":915,"_extension":19},"/de-de/blog/what-is-gitflow",{"ogTitle":897,"schema":898,"ogImage":899,"ogDescription":900,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":901,"title":897,"canonicalUrls":901,"description":900},"Was ist GitFlow? Ein Leitfaden inkl. Beispiel","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist GitFlow?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","Wir zeigen dir, was sich hinter GitFlow verbirgt. ✓ Definition ✓ Funktionsweise ✓ GitFlow vs. GitLab Flow ✓ Vorteile ✓ Beispiel ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-gitflow",{"heroImage":899,"body":903,"authors":904,"updatedDate":906,"date":907,"title":897,"tags":908,"description":909,"category":10},"In GitFlow erstellen Entwickler(innen) zusätzlich zum „`main`“-Branch (Produktionszweig) einen separaten „`develop`“-Branch und legen diesen als Standard fest. In [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) kannst du jedoch sofort mit der Arbeit am `main`\\-Branch beginnen. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) enthält einen Vorproduktionsbranch, `main`. Du kannst Änderungen in einen Branch zusammenführen und Fehler beheben, bevor du mit der Produktion beginnst. Teams können beliebig viele Vorproduktionsbranches hinzufügen: z. B. von `main` zum Test, vom Test zur Genehmigung oder von der Genehmigung zur Produktion. \n\nHier erklären wir klar und deutlich die Unterschiede zwischen GitFlow und [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/), was GitFlow ist, wie GitFlow funktioniert, welche Vorteile seine Verwendung bietet und beantworten häufig gestellte Fragen. \n\n## Inhaltsverzeichnis\n\n- [Was ist GitFlow?](#was-ist-gitflow%3F)\n- [So funktioniert GitFlow](#so-funktioniert-gitflow)\n- [Was ist der Unterschied zwischen GitFlow und GitLab Flow?](#was-ist-der-unterschied-zwischen-gitflow-und-gitlab-flow%3F)\n  - [GitFlow-Workflow](#gitflow-workflow)\n  - [GitLab-Flow-Workflow](#gitlab-flow-workflow)\n- [Vorteile der Verwendung und Funktionen von GitFlow](#vorteile-der-verwendung-und-funktionen-von-gitflow)\n  - [Vorteil 1: Fehlerbehebungen werden schneller verarbeitet](#vorteil-1-fehlerbehebungen-werden-schneller-verarbeitet)\n  - [Vorteil 2: Garantierte Tests](#vorteil-2-garantierte-tests)\n  - [Vorteil 3: Rationalisierung des Softwareentwicklungsprozesses](#vorteil-3-rationalisierung-des-softwareentwicklungsprozesses)\n  - [Vorteil 4: Effektivere Zusammenarbeit, Konfliktlösung und kontinuierliche Lieferung](#vorteil-4-effektivere-zusammenarbeit-konfliktlösung-und-kontinuierliche-lieferung)\n- [GitFlow-Beispiel](#gitflow-beispiel)\n- [GitLab-Flow- und GitFlow-FAQs (häufig gestellte Fragen)](#gitlab-flow--und-gitflow-faqs-(häufig-gestellte-fragen))\n  - [F: Was ist Git Feature Flow?](#f-was-ist-git-feature-flow%3F)\n  - [F: Lohnt es sich, GitLab Flow zu verwenden?](#f-lohnt-es-sich-gitlab-flow-zu-verwenden%3F)\n  - [F: Welche Option passt besser für mich: GitLab Flow oder GitFlow?](#f-welche-option-passt-besser-für-mich-gitlab-flow-oder-gitflow%3F)\n- [Verwandte Artikel](#verwandte-artikel)\n- [Beginne noch heute mit GitLab](#beginne-noch-heute-mit-gitlab)\n\n## Was ist GitFlow?\n\nGitFlow ist ein Git-Workflow, der Git-Braches (verteiltes Versionskontrollsystem) verwaltet und ein Branchingmodell eines Repositorys in Git. Es wurde entwickelt, um die Komplexität des Software-Release-Managements zu vereinfachen und wurde erstmals im Jahr 2010 von Vincent Driessen verwendet. Besonders größere Teams finden es hilfreich. \n\n## So funktioniert GitFlow\n\nIm Vergleich zur Trunk-basierten Entwicklung verfügt GitFlow über persistente Branches und große Commits. GitFlow kann für Projekte mit festen Release-Zyklen und für bewährte [DevOps](https://about.gitlab.com/de-de/solutions/devops-platform/)\\-Methoden für die kontinuierliche Bereitstellung verwendet werden. GitFlow verfügt über einen strukturierten Workflow, sodass du deine Branches definieren kannst, indem du beispielsweise Feature-Branches zu deinen Entwicklungs- und Hauptbranches hinzufügst, dann einen Release-Branch hinzufügst usw. Dadurch wird es für dein Team einfacher, die Struktur zu verstehen und zu erkennen, wo in der Entwicklungspipeline Änderungen vorgenommen werden müssen. \n\n## Was ist der Unterschied zwischen GitFlow und GitLab Flow?\n\nGitFlow ist ein Branchingmodell für Git, das zusätzlich zu Feature-Branches mehrere main-Branches verwendet. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) löst die Probleme, die GitFlow hatte, und ermöglicht Teammitgliedern, effizienter zu arbeiten. Sehen wir uns die Unterschiede im Workflow im Detail an. \n\n### GitFlow-Workflow\n\nDer GitFlow-Workflow hat fünf Branches: \n\n1. main\u003Cbr>\n2. develop\u003Cbr>\n3. feature\u003Cbr>\n4. release\u003Cbr>\n5. hotfix\u003Cbr>\n\nWenn du GitFlow zur Code-Entwicklung verwendest, hast du einen main-Branch und alle unterstützenden Branches. Der main-Branch hat zwei Branches: den main-Branch für die Veröffentlichung des Produkts und den develop-Branch für die Verwaltung des in Entwicklung befindlichen Quellcodes. Wir stabilisieren den Code im develop-Branch und führen ihn dann in den main-Branch zusammen, wenn er zur Veröffentlichung bereit ist. Im support-Branch erstellen wir Branches wie feature, release und hotfix und fahren mit den einzelnen Arbeiten fort. \n\n### GitLab-Flow-Workflow\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) rationalisiert die Entwicklung, indem es den Aufwand für Freigabe, Markierung, Zusammenführung usw. eliminiert. \n\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) ist eine vereinfachte Version von GitFlow, die funktionszentrierte Entwicklung mit Funktionen zur Problemverfolgung kombiniert. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) macht deine Arbeit einfach, klar und effizient. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) enthält bewährte Methoden, die Softwareentwicklungsteams dabei helfen, Funktionen reibungslos zu veröffentlichen. \n\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) ist der Workflow, der in der GitLab-Entwicklung verwendet wird, und der `main`\\-Branch, ein `pre-production`, einen Branch für Tests vor der Veröffentlichung, `production`, der den veröffentlichten Code verwaltet, und `feature`/`hotfix`, der für die Entwicklung von Funktionen und die Behebung von Fehlern verwendet wird. Teams können beliebig viele Vorproduktionsbranches hinzufügen. Du kannst beispielsweise einen Ablauf von `main` zu Test, von Test zu Approval und von Approval zu Produktion erstellen. \n\nDas Team erstellt Feature-Branches und pflegt gleichzeitig den Produktionsbranch. Sobald der main-Branch zur Bereitstellung bereit ist, führst du ihn in den Produktionszweig zusammen und gibst ihn frei. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) kann auch in Release-Branches verwendet werden. Teams, die eine öffentliche API benötigen, müssen jedoch verschiedene Versionen verwalten. Mit [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) können Sie jedoch v1- und v2-Branches erstellen, die separat verwaltet werden können, sodass Sie zu v1 zurückkehren können, wenn Sie während der Codeüberprüfung einen Fehler finden, was sehr praktisch ist. \n\n## Vorteile der Verwendung und Funktionen von GitFlow\n### Vorteil 1: Fehlerbehebungen werden schneller verarbeitet\n\nEiner der Vorteile der Verwendung von GitFlow besteht darin, dass Fehlerbehebungen in der Produktion schnell verarbeitet werden können. GitFlow ist ein Workflow zur Verwendung von Git (einem verteilten Versionskontrollsystem) bei der Entwicklung komplexer Software in großen Teams. \n\n### Vorteil 2: Garantierte Tests\n\nWenn du Software aus einem Release-Branch veröffentlichst, kannst du einen Zeitraum festlegen, während dessen Benutzer(innen) sie in einer Staging-Umgebung testen können. Dies kann unabhängig von der Code-Entwicklung erfolgen. Und da Commits nachgelagert sind, kannst du sicher sein, dass sie in allen Umgebungen getestet wurden. \n\n### Vorteil 3: Rationalisierung des Softwareentwicklungsprozesses\n\nGitFlow hilft dir, das Beste aus Git herauszuholen. So kannst du den Softwareentwicklungsprozess optimieren. \n\n### Vorteil 4: Effektivere Zusammenarbeit, Konfliktlösung und kontinuierliche Lieferung\n\nDurch die Einführung von GitFlow kann die Zusammenarbeit effizienter gestaltet werden. Zusammenführungskonflikte können schnell gelöst werden, wodurch eine kontinuierliche Lieferung ermöglicht wird. \n\n## GitFlow-Beispiel\nDas folgende Diagramm zeigt ein Beispiel einer GitFlow-Konfiguration. Das Gesamtkonzept und die Struktur der einzelnen Branches sind sicher verständlich. \n\n![AdobeStock 569852816](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\n## GitLab-Flow- und GitFlow-FAQs (häufig gestellte Fragen) \n\n### F: Was ist Git Feature Flow? \nA: Es ist einer der für die Verwendung von Git vorgeschlagen Entwicklungsabläufe. Für eine einfache Entwicklung kann Git Feature Flow verwendet werden. \n\n### F: Lohnt es sich, GitLab Flow zu verwenden? \n\nA: Ja. GitLab Flow reduziert den Aufwand für Veröffentlichung, Taggen, Zusammenführen und mehr. Dies sind Probleme, die häufig in anderen Git-Workflows auftreten. Weitere Informationen findest du [hier](https://about.gitlab.com/de-de/topics/version-control/what-are-gitlab-flow-best-practices/). \n\n### F: Welche Option passt besser für mich: GitLab Flow oder GitFlow? \n\nA: Aufgrund seiner Struktur eignet sich GitFlow besser für große Projekte mit klar getrennten Entwicklungsphasen, während GitLab Flow agiler ist und sich besser für Projekte eignet, bei denen kontinuierliche Lieferung und schnelle Releases im Vordergrund stehen. \n\n## Verwandte Artikel\n\n[Über GitLab DevSecOps](https://about.gitlab.com/de-de/)\n\n## Beginne noch heute mit GitLab\n\nWeitere Informationen zu Git und Versionskontrolle findest du [hier](https://about.gitlab.com/resources/). Möchtest du erfahren, welche Möglichkeiten eine integrierte DevSecOps-Plattform für dein Team bietet? \n\n[Kostenlose Testversion anfordern](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com)\n",[905],"GitLab Team","2025-05-29","2024-09-27",[682,9],"Wir stellen die Unterschiede zwischen GitFlow und GitLab Flow vor, erklären, was GitFlow ist, wie GitFlow funktioniert, welche Vorteile seine Verwendung bietet (inklusive FAQ)",{"slug":911,"featured":6,"template":686},"what-is-gitflow","content:de-de:blog:what-is-gitflow.yml","What Is Gitflow","de-de/blog/what-is-gitflow.yml","de-de/blog/what-is-gitflow",{"_path":917,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":918,"content":924,"config":929,"_id":931,"_type":14,"title":932,"_source":16,"_file":933,"_stem":934,"_extension":19},"/de-de/blog/what-is-open-source-software",{"title":919,"description":920,"ogTitle":919,"ogDescription":920,"noIndex":6,"ogImage":921,"ogUrl":922,"ogSiteName":673,"ogType":674,"canonicalUrls":922,"schema":923},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749690483/Blog/Hero%20Images/blog-image-template-1800x945__11_.png","https://about.gitlab.com/blog/what-is-open-source-software","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open Source & OSS: Was es ist, was es dir bringt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":919,"description":920,"authors":925,"heroImage":921,"date":926,"body":927,"category":10,"tags":928},[861],"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\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/security-compliance/) 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.",[552,9],{"slug":930,"featured":6,"template":686},"what-is-open-source-software","content:de-de:blog:what-is-open-source-software.yml","What Is Open Source Software","de-de/blog/what-is-open-source-software.yml","de-de/blog/what-is-open-source-software",{"_path":936,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":937,"content":940,"config":948,"_id":950,"_type":14,"title":951,"_source":16,"_file":952,"_stem":953,"_extension":19},"/de-de/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":938,"description":939},"GitLab: Was gibt es Neues in Git 2.50.0?","Beiträge des Git-Teams von GitLab und der Git-Community, inklusive der Befehl git-diff-pairs(1) und die Option git-rev-list(1) für gebündelte Referenz-Updates.",{"title":941,"description":939,"authors":942,"heroImage":944,"body":945,"date":946,"category":10,"tags":947},"Was gibt es Neues in Git 2.50.0?",[943],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Das Git-Projekt hat kürzlich\n[Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)\nveröffentlicht. Werfen wir einen Blick auf die Highlights dieser\nVeröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten\nGit-Community enthält.\n\n\n## Neuer Befehl git-diff-pairs(1)\n\n\nDiffs sind das Herzstück jeder Code Review und zeigen alle Änderungen, die zwischen zwei Revisionen vorgenommen wurden. GitLab zeigt Diffs an verschiedenen Stellen an, am häufigsten aber auf der [Registerkarte „Änderungen“ (in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/merge_requests/changes/) eines Merge Requests.\n\n\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nDieser Befehl gibt das vollständige Diff für alle geänderten Dateien zurück. Dies kann eine Herausforderung für die Skalierbarkeit darstellen, vor allem, wenn die Anzahl der Dateien, die innerhalb einer Reihe von Revisionen geändert wurden, sehr groß ist. Dies kann dazu führen, dass der Befehl selbst auferlegte Zeitlimits für das GitLab-Backend erreicht. Bei großen Änderungen wäre es besser, wenn\n\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\n\nEine Möglichkeit dafür ist die Verwendung von\n\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\n\nüber alle geänderten Dateien abzurufen:\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGit bezeichnet diese Ausgabe als [„unbearbeitetes“ Format (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree#_raw_output_format).\n\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\n\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\n\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\n\nschnell und liefert eine Zusammenfassung aller Änderungen. Dieser Befehl kann optional eine Umbenennungserkennung durchführen, indem das Flag `-M` angehängt wird. So kannst du überprüfen, ob identifizierte Änderungen auf eine Dateiumbenennung zurückzuführen sind.\n\n\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\n\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\n\ndirekt angeben:\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nWir können diesen Vorgang für jedes der Dateipaare wiederholen, aber es ist nicht sehr effizient, für jede einzelne Datei einen\n\nseparaten Git-Prozess zu starten.\n\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\n\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\n\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\n\ndie entsprechende Patch-Ausgabe zu generieren.\n\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\n\nakzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl\n\nverwendet werden kann:\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\n\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\n\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\n\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\n\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\n\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n## Gesammelte Referenz-Updates\n\n\nMit dem Git-Befehl [`git-update-ref(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-update-ref)\n\n kannst du Referenzaktualisierungen durchführen. Bei Verwendung mit dem Flag `--stdin` können\n\nmehrere Referenzaktualisierungen in einer einzigen Transaktion gebündelt werden, indem Anweisungen für jede Referenzaktualisierung\n\nangegeben werden, die auf stdin durchgeführt werden soll.\n\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\n\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\n\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n\n```shell\n\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# Gib die Commit-IDs aus\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# Die Referenz „bar“ wurde nicht erstellt.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\n\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\n\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\n\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\n\nMassenaktualisierungen nutzen möchten.\n\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\n\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\n\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nDadurch können erfolgreiche Referenzaktualisierungen fortgesetzt werden, während gleichzeitig angegeben wird, unter welchen Umständen Aktualisierungen abgelehnt wurden und aus welchem Grund. Wir verwenden noch einmal das gleiche beispielhafte Repository wie im vorherigen Beispiel:\n\n\n```shell\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\n\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\n\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\n\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Neue Filteroption für git-cat-file(1)\n\n\nMit [`git-cat-file(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-cat-file) ist es möglich,\n\nInformationen für alle im Repository enthaltenen Objekte über die Option\n\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n\n```shell\n\n# Richte ein einfaches Repository ein.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# Erstelle ein nicht erreichbares Objekt.\n\n$ git commit --amend --no-edit\n\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\n\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\n\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n\n`grep(1)` verwenden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\n\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\n\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\n\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\n\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\n\nihrem Typ gefiltert werden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\n\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\n\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\n\nnachschlagen und so das Durchsuchen der\n\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\n\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n```\n\n\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\n\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\n\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Verbesserte Leistung beim Generieren von Bundles\n\n\nGit bietet die Möglichkeit, über den Befehl\n\n[`git-bundle(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-bundle) ein Archiv eines Repositories zu generieren, das einen\n\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\n\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\n\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\n\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\n\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\n\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\n\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\n\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \n\nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\n\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n\n100 000 Referenzen enthält:\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nWeitere Informationen findest du in unserem Blogbeitrag\n\n[Wie wir die Backup-Zeiten für GitLab-Repos von 48 Stunden auf 41 Minuten verringerten (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/).\n\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\n\n[hier](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Bessere Auflösung von URI-Bundles\n\n\nDurch den [Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus in Git können den Clients\n\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\n\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\n\nunter `refs/heads/*` zusammen mit\n\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\n\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\n\ndie Bundle-URI beim Klonen verwendet wird.\n\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\n\ndemonstriert den Unterschied beim Klonen von\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\n\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\n\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\n\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\n\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\n\nBeschleunigung um 25 %.\n\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*TDiese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n\n## Weiterlesen\n\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\n\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\n\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\n\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\n\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n","2025-06-16",[682,9,270],{"featured":91,"template":686,"slug":949},"what-s-new-in-git-2-50-0","content:de-de:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","de-de/blog/what-s-new-in-git-2-50-0.yml","de-de/blog/what-s-new-in-git-2-50-0",{"_path":955,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":956,"content":960,"config":966,"_id":968,"_type":14,"title":969,"_source":16,"_file":970,"_stem":971,"_extension":19},"/de-de/blog/what-s-new-in-git-2-51-0",{"config":957,"ogImage":944,"title":958,"description":959},{"noIndex":6},"Was ist neu in Git 2.51.0?","Erfahren Sie mehr über die neuesten Beiträge von GitLabs Git-Team und der Git-Community, einschließlich Performance-Optimierungen für git-push(1) und git-fetch(1), die besonders für deutsche Entwicklungsteams relevant sind.",{"title":958,"description":959,"authors":961,"heroImage":944,"date":963,"body":964,"category":10,"tags":965},[962],"Karthik Nayak","2025-08-18","Das Git-Projekt hat kürzlich [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) veröffentlicht. Aufgrund des Sommers auf der Nordhalbkugel und langsamerer Fortschritte war dieser Release-Zyklus mit 8 Wochen eher kurz (normalerweise dauert ein Release-Zyklus etwa 12 Wochen). \n\n**Die wichtigste Neuerung: Git-Operationen werden bis zu 22-mal schneller** - besonders bei großen Repositories mit vielen Branches profitieren Entwicklungsteams von erheblichen Performance-Verbesserungen.\n\nSchauen wir uns diese und andere bemerkenswerte Änderungen in diesem Release an, einschließlich Beiträgen vom Git-Team bei GitLab und der breiteren Git-Community.\n\n## Massive Performance-Verbesserungen: Von Sekunden zu Millisekunden\n\nGroße Repositories mit tausenden von Branches standen vor einem schmerzhaften Engpass. Git-Operationen, die Referenzen aktualisieren, konnten mehrere Sekunden dauern - ein echter Produktivitätskiller für Teams mit umfangreichen CI/CD-Pipelines oder Monorepo-Workflows.\n\n**Git 2.51.0 ändert alles. Eine 10.000-Referenzen-Fetch-Operation, die 3,4 Sekunden dauerte, wird jetzt in 154 Millisekunden abgeschlossen:**\n\n```\nVORHER: git-fetch mit 10.000 Referenzen\nTime: 3.403 s ± 0.775 s\n\nNACHHER: git-fetch mit 10.000 Referenzen  \nTime: 154.3 ms ± 17.6 ms\n\nERGEBNIS: 22× schneller\n```\n\n**Ähnlich dramatische Verbesserungen bei git-push:**\n\n```\nVORHER: git-push mit 10.000 Referenzen\nTime: 4.276 s ± 0.078 s\n\nNACHHER: git-push mit 10.000 Referenzen\nTime: 235.4 ms ± 6.9 ms\n\nERGEBNIS: 18× schneller\n```\n\n### Wie wurde das erreicht?\n\nDas Problem lag in der Art, wie Git Referenz-Transaktionen behandelte. Die Kommandos git-push(1) und git-fetch(1) erstellten eine separate Transaktion für jedes Referenz-Update, was enormen Overhead verursachte - jede Transaktion benötigte eine Initialisierungs- und Abbauphase und löste Auto-Komprimierungen aus.\n\nGit 2.51.0 verwendet nun **gebündelte Updates**: Mehrere Referenzen werden in einer einzigen Transaktion aktualisiert, während einzelne Updates weiterhin fehlschlagen dürfen. Dies eliminiert den Overhead und skaliert linear mit der Anzahl der Referenzen.\n\nDas Beste daran? Benutzer profitieren automatisch von diesen Verbesserungen, ohne Änderungen an ihrem Workflow vornehmen zu müssen.\n\nDieses [Projekt](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Änderungen in Richtung Git 3.0\n\nVor 11 Jahren wurde Git 2.0 veröffentlicht, die letzte große Versionsfreigabe von Git. Obwohl wir keinen spezifischen Zeitplan für die nächste große Git-Veröffentlichung haben, enthält dieses Release Entscheidungen, die in Richtung Git 3.0 getroffen wurden.\n\nDie Git 3.0-Release-Planung ermöglicht es uns, Breaking Changes zu planen und zu implementieren und diese der erweiterten Git-Community zu kommunizieren. Neben der Dokumentation kann Git auch mit diesen Breaking Changes kompiliert werden für diejenigen, die mit diesen Änderungen experimentieren möchten. Weitere Informationen finden Sie im [BreakingChanges-Dokument](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc).\n\nDas Git 2.51.0-Release bringt einige bedeutende Änderungen in Richtung Git 3.0.\n\n### \"reftable\" wird Standard in Git 3.0\n\nIm [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads)-Release wurde das \"reftable\"-Format als neues Backend zur Speicherung von Referenzen wie Branches oder Tags in Git eingeführt, das viele der Probleme des bestehenden \"files\"-Backends behebt. Lesen Sie unseren [Einsteiger-Leitfaden zur Funktionsweise von reftables](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) für weitere Einblicke in das \"reftable\"-Backend.\n\nDas Git 2.51.0-Release markiert den Wechsel zur Verwendung des \"reftable\"-Formats als Standard in Git 3.0 für neu erstellte Repositories und verdrahtet die Änderung hinter einem Feature-Flag. Das \"reftable\"-Format bietet folgende Verbesserungen gegenüber dem traditionellen \"files\"-Backend:\n\n* Es ist unmöglich, zwei Referenzen zu speichern, die sich nur in der Groß-/Kleinschreibung unterscheiden, auf case-insensitiven Dateisystemen mit dem \"files\"-Format. Dieses Problem ist häufig auf Windows- und macOS-Plattformen. Da das \"reftable\"-Backend keine Dateisystem-Pfade zur Kodierung von Referenznamen verwendet, verschwindet dieses Problem.\n\n* Ebenso normalisiert macOS Pfadnamen, die Unicode-Zeichen enthalten, was zur Folge hat, dass Sie nicht zwei Namen mit Unicode-Zeichen speichern können, die unterschiedlich kodiert sind, mit dem \"files\"-Backend. Auch dies ist kein Problem mit dem \"reftable\"-Backend.\n\n* Das Löschen von Referenzen mit dem \"files\"-Backend erfordert, dass Git die komplette \"packed-refs\"-Datei neu schreibt. In großen Repositories mit vielen Referenzen kann diese Datei leicht dutzende Megabytes groß sein; in extremen Fällen kann sie Gigabytes umfassen. Das \"reftable\"-Backend verwendet Tombstone-Marker für gelöschte Referenzen und muss daher nicht alle seine Daten neu schreiben.\n\n* Repository-Hauskeeping mit dem \"files\"-Backend führt normalerweise All-into-One-Repacks von Referenzen durch. Dies kann sehr teuer sein, und folglich ist Housekeeping ein Kompromiss zwischen der Anzahl loser Referenzen, die sich ansammeln und Operationen verlangsamen, die Referenzen lesen, und der Komprimierung dieser losen Referenzen in die \"packed-refs\"-Datei. Das \"reftable\"-Backend verwendet geometrische Komprimierung nach jedem Schreibvorgang, was Kosten amortisiert und sicherstellt, dass das Backend immer in einem gut gewarteten Zustand ist.\n\n* Operationen, die mehrere Referenzen auf einmal schreiben, sind nicht atomisch mit dem \"files\"-Backend. Folglich kann Git Zwischenzustände sehen, wenn es Referenzen liest, während eine Referenz-Transaktion gerade auf die Festplatte committed wird.\n\n* Das Schreiben vieler Referenzen auf einmal ist langsam mit dem \"files\"-Backend, weil jede Referenz als separate Datei erstellt wird. Das \"reftable\"-Backend übertrifft das \"files\"-Backend um mehrere Größenordnungen.\n\n* Das \"reftable\"-Backend verwendet ein Binärformat mit Präfix-Komprimierung für Referenznamen. Als Resultat nutzt das Format weniger Platz im Vergleich zur \"packed-refs\"-Datei.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n### SHA-256 wird Standard in Git 3.0\n\nDas Git-Versionskontrollsystem speichert Objekte in einem inhaltsadressierbaren Dateisystem. Das bedeutet, es verwendet den Hash eines Objekts zur Adressierung von Inhalten wie Dateien, Verzeichnissen und Revisionen, anders als traditionelle Dateisysteme, die sequenzielle Nummern verwenden. Die Verwendung einer Hash-Funktion hat folgende Vorteile:\n\n* Einfache Integritätsprüfungen, da ein einzelner Bit-Flip die Hash-Ausgabe komplett verändern würde.\n* Schnelle Objektsuche, da Objekte nach ihrem Hash indexiert werden können.\n* Objektnamen können signiert werden und Drittparteien können dem Hash vertrauen, um das signierte Objekt und alle Objekte, auf die es verweist, zu adressieren.\n* Kommunikation über Git-Protokoll und Out-of-Band-Kommunikationsmethoden haben einen kurzen zuverlässigen String, der zur zuverlässigen Adressierung gespeicherter Inhalte verwendet werden kann.\n\nSeit seiner Entstehung hat Git den SHA-1-Hashing-Algorithmus verwendet. Sicherheitsforscher haben jedoch einige Schwachstellen in SHA-1 entdeckt, speziell den [SHAttered-Angriff](https://shattered.io), der eine praktische SHA-1-Hash-Kollision zeigt. Wir sind seit Git 2.13.0 standardmäßig zu einer gehärteten SHA-1-Implementierung übergegangen. SHA-1 ist jedoch immer noch ein schwacher Hashing-Algorithmus und es ist nur eine Frage der Zeit, bis zusätzliche Angriffe seine Sicherheit weiter reduzieren werden.\n\nSHA-256 wurde Ende 2018 als Nachfolger von SHA-1 identifiziert. Git 2.51.0 markiert es als Standard-Hash-Algorithmus für Git 3.0.\n\nDieses Projekt wurde von [brian m. carlson](https://github.com/bk2204) geleitet.\n\n### Entfernung von git-whatchanged(1)\n\nDer git-whatchanged(1)-Befehl zeigt Logs mit Unterschieden, die jeder Commit einführt. Obwohl dies nun von git log --raw abgelöst wurde, wurde der Befehl aus historischen Gründen beibehalten.\n\nGit 2.51.0 erfordert, dass Benutzer des Befehls explizit das --i-still-use-this-Flag verwenden, um alle Benutzer zu erfassen, die noch den veralteten Befehl verwenden, und markiert den Befehl auch für die Entfernung in Git 3.0.\n\nDieses Projekt wurde von [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano) geleitet.\n\n## git switch und git restore sind nicht mehr experimentell\n\nDer git-checkout(1)-Befehl kann für mehrere verschiedene Anwendungsfälle verwendet werden. Er kann zum Wechseln von Referenzen verwendet werden:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git checkout next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nOder zur Wiederherstellung von Dateien:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git checkout git.c\n1 Pfad von Index aktualisiert\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nFür neue Git-Benutzer kann dies zu viel Verwirrung führen. In Git 2.33.0 wurden diese in zwei neue Befehle aufgeteilt: git-switch(1) und git-restore(1).\n\nDer git-switch(1)-Befehl ermöglicht es Benutzern, zu einem bestimmten Branch zu wechseln:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git switch next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nUnd der git-restore(1)-Befehl ermöglicht es Benutzern, Working-Tree-Dateien wiederherzustellen:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nObwohl die beiden Befehle seit 2019 existieren, wurden sie als experimentell markiert. Der Effekt ist, dass das Git-Projekt keine Rückwärtskompatibilität für diese Befehle garantiert: das Verhalten kann sich jederzeit ändern. Obwohl die Absicht ursprünglich war, diese Befehle nach einigen Releases zu stabilisieren, ist das bis zu diesem Punkt nicht geschehen.\n\nDies hat zu mehreren Diskussionen auf der Git-Mailing-Liste geführt, wo Benutzer unsicher sind, ob sie diese neuen Befehle verwenden können oder ob sie eventuell wieder verschwinden. Da jedoch keine bedeutenden Änderungen vorgeschlagen wurden und einige Benutzer diese Befehle bereits verwenden, haben wir beschlossen, sie in Git 2.51 nicht mehr als experimentell zu deklarieren.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## git for-each-ref(1) erhält Paginierungs-Unterstützung\n\nDer git for-each-ref-Befehl wird verwendet, um alle im Repository vorhandenen Referenzen aufzulisten. Als Teil der Plumbing-Schicht von Git wird dieser Befehl häufig beispielsweise von Hosting-Forges verwendet, um Referenzen, die im Repository existieren, in ihrer UI aufzulisten. Aber während Repositories wachsen, wird es weniger realistisch, alle Referenzen auf einmal aufzulisten – schließlich können die größten Repositories Millionen davon enthalten! Stattdessen neigen Forges dazu, die Referenzen zu paginieren.\n\nDies zeigt eine wichtige Lücke auf: git-for-each-ref weiß nicht, Referenzen von vorherigen Seiten zu überspringen, die bereits gezeigt wurden. Folglich muss es möglicherweise eine große Anzahl uninteressanter Referenzen auflisten, bevor es endlich beginnt, die für die aktuelle Seite benötigten Referenzen zu liefern. Dies ist ineffizient und führt zu höherer als notwendiger Latenz oder sogar Timeouts.\n\nGit 2.51.0 unterstützt ein neues --start-after-Flag für git for-each-ref, das die Paginierung der Ausgabe ermöglicht. Dies kann auch mit dem --count-Flag kombiniert werden, um über einen Batch von Referenzen zu iterieren.\n\n```\n$ git for-each-ref --count=10\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Fazit\n\n**Diese Performance-Verbesserungen sind besonders relevant für deutsche Entwicklungsteams, die mit großen Repositories und intensiven CI/CD-Workflows arbeiten.** Die 22-fache Beschleunigung bei git-fetch kann erhebliche Zeitersparnisse in der täglichen Entwicklungsarbeit bedeuten.\n\nBereit, diese Verbeszerungen zu erleben? Aktualisieren Sie auf Git 2.51.0 und beginnen Sie, git switch und git restore in Ihrem täglichen Workflow zu verwenden.\n\nFür GitLab-Benutzer werden diese Performance-Verbesserungen automatisch Ihre Entwicklungserfahrung verbessern, sobald Ihre Git-Version aktualisiert wird.\n\nErfahren Sie mehr in den [offiziellen Git 2.51.0 Release Notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) und erkunden Sie unser [komplettes Archiv der Git-Entwicklungsberichterstattung](https://about.gitlab.com/blog/tags/git/).\n\n---\n\n*Für vollständige technische Details, Benchmarks und Implementierungshinweise lesen Sie den [englischen Originalartikel](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/).*\n",[682,9,270,843],{"featured":6,"template":686,"slug":967},"what-s-new-in-git-2-51-0","content:de-de:blog:what-s-new-in-git-2-51-0.yml","What S New In Git 2 51 0","de-de/blog/what-s-new-in-git-2-51-0.yml","de-de/blog/what-s-new-in-git-2-51-0",{"_path":973,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":974,"content":979,"config":985,"_id":987,"_type":14,"title":988,"_source":16,"_file":989,"_stem":990,"_extension":19},"/de-de/blog/whats-new-in-git-2-46-0",{"title":975,"description":976,"ogTitle":975,"ogDescription":976,"noIndex":6,"ogImage":717,"ogUrl":977,"ogSiteName":673,"ogType":674,"canonicalUrls":977,"schema":978},"Was gibt es Neues in Git 2.46.0?","Hier findest du die Highlights, die das Git-Team von GitLab und die breitere Git-Community zum Release beigetragen haben. Freu dich unter anderem auf Migrationstools für das Referenz-Backend und Unterstützung für symbolische Referenzen in Transaktionen.","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.46.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }\n                  ",{"title":975,"description":976,"authors":980,"heroImage":717,"date":981,"body":982,"category":10,"tags":983,"updatedDate":984},[943],"2024-07-29","Das Git-Projekt hat kürzlich [Git v2.46.0](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Tools zur Migration von Referenz-Backends\n\nIn der vorherigen [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)-Release wurde das Format „reftables“ als neues Backend zum Speichern von Referenzen eingeführt. Dieses neue Referenzformat behebt einige Schwierigkeiten, die Repositories hatten, wenn die Anzahl der Referenzen stieg. Wenn du mit dem reftables-Backend noch nicht vertraut bist, lies dir unseren letzten [Blogbeitrag zur Git-Release](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) durch, in dem das Feature vorgestellt wurde. Auch unsere Anfängerleitfaden ist toll, um [mehr darüber zu erfahren, wie reftables funktionieren](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nDas reftable-Backend hat ein anderes Festplattenformat als das vorhandene files-Backend. Daher ist bei der Verwendung von reftables in einem bestehenden Repository eine Konvertierung zwischen den verschiedenen Formaten erforderlich. Dazu wurden der neue Befehl git-refs(1) und der Unterbefehl `migrate` eingeführt, um Referenz-Backend-Migrationen auszuführen. Hier findest du ein Beispiel dafür, wie dieser Befehl verwendet werden kann.\n\n```shell\n# Initialisiere ein neues \"bare\" Repository, damit es keine Reflogs enthält.\n$ git init --bare .\n$ git commit --allow-empty -m \"init\"\n# Erstelle ein paar Referencen.\n$ git branch foo\n$ git branch bar\n$ tree .git/refs\n.git/refs\n├── heads\n│   ├── bar\n│   ├── foo\n│   ├── main\n└── tags\n# Migriere Referenzen zum reftable Format.\n$ git refs migrate --ref-format=reftable\n# Überprüfe, ob jetzt das reftable Backend benutzt wird.\n$ tree .git/reftable\n.git/reftable\n├── 0x000000000001-0x000000000001-a3451eed.ref\n└── tables.list\n# Überprüfe die Repository Konfiguration um das neue `refstorage` Format zu sehen.\n$ cat config\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\nSobald ein Repository migriert wurde, wird das Festplattenformat geändert, sodass du dann das reftable-Backend nutzen kannst. Git-Abläufe im Repository funktionieren und interagieren wie gewohnt mit Remotes. Die Migration wirkt sich nur darauf aus, wie Referenzen intern für das Repository gespeichert werden. Wenn du zum file-Referenz-Backend zurückkehren möchtest, führe einfach den gleichen Befehl aus und spezifiziere dabei `--ref-format=files`.\n\nDas Migrationstool hat derzeit einige signifikante Einschränkungen. Die Reflogs in einem Repository werden auch über das Referenz-Backend gespeichert und würden ebenfalls eine Migration erfordern. Leider ist das Tool noch nicht in der Lage, Reflogs zwischen den files- und reftables-Backends zu konvertieren. Außerdem hat ein Repository mit Worktrees im Grunde mehrere Ref-Stores, und das Migrationstool kann dieses Szenario derzeit noch nicht bewältigen. Wenn ein Repository also Reflogs oder Worktrees enthält, ist die Migration derzeit nicht verfügbar. Diese Einschränkungen werden voraussichtlich in zukünftigen Versionen behoben.\n\nDa ein “bare” Git-Repository keine Reflogs hat, ist es einfacher zu migrieren. Um ein nicht-”bare” Repository zu migrieren, müssen die Reflogs zuerst gelöscht werden. Es kann also jedes Repository ohne Reflogs oder Worktrees migriert werden. Wenn du diese Einschränkungen im Hinterkopf behältst, kann dieses Tool ein guter Helfer sein, um die Vorteile des reftables-Backends in deinen bestehenden Repositories zu nutzen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Transaktionale symref-Updates\n\nDer Befehl [git-update-ref(1)](https://git-scm.com/docs/git-update-ref)\nerlaubt es, Referenzen in einem Git-Repository zu schreiben. Es können auch mehrere Referenz-Updates atomar mit Transaktionen ausgeführt werden, indem der Befehl `git update-ref --stdin` verwendet wird und die Informationen zum Referenz-Update an stdin übergeben werden. Nachfolgend findest du ein Beispiel dafür, wie dies geschieht.\n\n```shell\n$ git init .\n$ git branch -m main\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n# Lese die Objekt ID für die zwei erstellten Commits.\n$ git rev-parse main~ main\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n# Starte eine Transaktion mit mehreren Updates und committe diese.\n$ git update-ref --stdin \u003C\u003CEOF\n> start\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n> commit\n> EOF\n$ git for-each-ref\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n```\n\nIn diesem Beispiel wird nach dem Commit der Transaktion ein neuer Branch erstellt, der auf den Commit „bar“ zeigt, und der Haupt-Branch wird aktualisiert, um auf den vorherigen Commit „foo“ zu zeigen. Durch das Committen der Transaktion werden die angegebenen Referenz-Updates atomar durchgeführt. Wenn ein einzelnes Referenz-Update fehlschlägt, wird die Transaktion abgebrochen und es werden keine Referenz-Updates durchgeführt.\n\nHier ist bemerkenswert, dass es keine Anweisungen zur Unterstützung von symref-Updates bei diesen Transaktionen gibt. Wenn ein(e) Benutzer(in) ein symref zusammen mit anderen Referenzen atomar in derselben Transaktion aktualisieren möchte, gibt es dazu kein Tool. Die in dieser Release eingeführten Anweisungen `symref-create`, `symref-update`, `symref-delete` und `symref-verify` bieten diese Funktion.\n\n```shell\n# Erstelle eine symbolische Referenz, die wir updaten können.\n$ git symbolic-ref refs/heads/symref refs/heads/main\n# Der --no-deref Parameter wird benötigt, damit die symbolische Referenz selbst geupdated wird.\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n> start\n> symref-create refs/heads/new-symref refs/heads/main\n> symref-update refs/heads/symref refs/heads/new-ref\n> commit\n> EOF\n$ git symbolic-ref refs/heads/symref\nrefs/heads/new-ref\n$ git symbolic-ref refs/heads/new-symref\nrefs/heads/main\n```\n\nIm obigen Beispiel wird eine neue symbolische Referenz erstellt und eine weitere in einer Transaktion aktualisiert. Diese neuen symref-Anweisungen können in Kombination mit den bereits bestehenden Anweisungen verwendet werden, um alle Arten von Referenz-Updates jetzt in einer einzigen Transaktion durchführen zu können. Weitere Informationen zu jeder dieser neuen Anweisungen findest du in der [Dokumentation](https://git-scm.com/docs/git-update-ref).\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## UX-Verbesserungen für git-config(1)\n\nMit dem Befehl git-config(1) können Repository-Optionen und globale Optionen angezeigt und konfiguriert werden. Die Modi, die für die Interaktion mit der Konfiguration verwendet werden, können explizit mit Hilfe von Flags ausgewählt oder implizit basierend auf der Anzahl der dem Befehl bereitgestellten Argumente bestimmt werden. Ein Beispiel:\n\n```shell\n$ git config --list\n# Lese den Nutzernamen im expliziten Modus.\n$ git config --get user.name\n# Lese den Nutzernamen im impliziten Modus.\n$ git config user.name\n# Schreibe den Nutzernamen im expliziten Modus.\n$ git config --set user.name \"Sidney Jones\"\n# Schreibe den Nutzernamen im impliziten Modus.\n$ git config user.name \"Sidney Jones\"\n# Man kann auch ein optionales drittes Argument übergeben. Was denkst du, was der Effekt ist?\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n```\n\nIm Allgemeinen entspricht die Benutzeroberfläche von [git-config(1)](https://git-scm.com/docs/git-config) nicht den anderen, moderneren Git-Befehlen, bei denen man normalerweise Unterbefehle verwendet. Ein Beispiel ist `git remote list`. In diesem Release werden `list`, `get`, `set`, `unset`, `rename-section`, `remove-section` und `edit` als Unterbefehle eingeführt, die mit dem config-Befehl verwendet werden können, während gleichzeitig die alte Syntax erhalten bleibt. Diese Änderung soll das Erlebnis der Benutzer(innen) verbessern, indem der config-Befehl den UI-Gewohnheiten entspricht und sich mehr an andere Befehle in Git angleicht. Zum Beispiel:\n\n```shell\n$ git config list\n$ git config get user.name\n$ git config set user.name \"Sidney Jones\"\n```\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Performance-Regression wurde behoben\n\nGit-Operationen, die Attribute nutzen, lesen die `.gitattributes` Dateien im Worktree des Repositorys. Dies ist für reine Git-Repositories problematisch, da diese per Definition keinen Worktree haben. Um dies zu umgehen, gibt es in Git die Konfiguration `attr.tree`, mit der ein Quellbaum definiert werden kann, von dem Attribute ausgelesen werden.\n\nIn der Git Release 2.43.0 hat Git begonnen, bei “bare” Repositories standardmäßig den Baum von `HEAD` als Quelle für Git-Attribute heranzuziehen. Leider führte diese zusätzliche Belastung durch die Suche nach Git-Attributdateien zu schweren Leistungseinbußen. Das liegt daran, dass bei jeder Attributsuche der komplette Quellbaum durchsucht wird, um nach einer zugeordneten `.gitattributes`-Datei zu suchen, wenn `attr.tree` festgelegt ist. Je größer und tiefer der Quellbaum des Repository ist, desto deutlicher wird die Performance-Regression. Benchmarks im linux.git-Repository zeigten beispielsweise, dass git-pack-objects(1) 1,68-mal länger braucht, um durchzulaufen. Dies kann zu Verzögerungen führen, wenn man beispielsweise git-clone(1) oder git-fetch(1) benutzt.\n\n```\n# attr.tree zeigt auf \"HEAD\", wie es in Git 2.43.0 Standard ist.\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# attr.tree zeigt auf einen leeren Baum, wie es in Versionen vor Git 2.43.0 Standard war.\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904 pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\nEinige der wichtigsten Git-Befehle, die betroffen waren, sind `clone`, `pull`, `fetch` und `diff`, wenn diese wie erwähnt in Repositories mit großen oder tiefen Bäumen ausgeführt wurden. Um diese Performance-Regression zu beheben, wurde also die `attr.tree`-Konfiguration teilweise zurückgesetzt, sodass sie nicht mehr standardmäßig auf `HEAD` gesetzt ist. Weitere Informationen findest du in diesem [Thread](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/) in der Mailingliste.\n\n## Unit-Test-Migration\n\nIn der Vergangenheit wurde das Testen im Git-Projekt über End-to-End-Tests durchgeführt, die als Shell-Skripte implementiert waren. Vor relativ kurzer Zeit hat das Git-Projekt ein Unit-Test-Framework, das in C geschrieben ist, eingeführt. Dieses neue Test-Framework bietet die Möglichkeit für detailliertere Tests von Implementierungsdetails auf niedrigerer Ebene und stellt dadurch eine Ergänzung der bestehenden End-to-End Tests dar. Es gibt einige bestehende End-to-End-Tests, die besser als Unit-Tests und daher gut für die Portierung geeignet sind.\n\nIn diesem Jahr unterstützt GitLab erneut Mitwirkende des [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/), die im Git-Projekt arbeiten. Dank dieser laufenden GSoC-Projekte und auch der großen Git-Community werden einige bestehende Tests überarbeitet und in das Unit-Test-Framework migriert. Während dieses letzten Release-Zyklus gab es mehrere Beiträge zur Verbesserung von Tests im Git-Projekt. Den Entwicklungsfortschritt dieser GSoC-Projekte kannst du auf den Blogs von [Chandra](https://chand-ra.github.io/) und [Ghanshyam](https://spectre10.github.io/posts/) verfolgen.\n\n## Bundle-URI-Fixes\n\nWenn ein Client etwas aus einem Remote-Repository abruft, werden normalerweise alle erforderlichen Objekte in einer vom Remote-Server zusammengestellten Packfile gesendet. Um einen Teil dieser Berechnungen einzusparen, können Server vorgefertigte „Bundles“ anbieten, die separat vom Remote-Server gespeichert werden und eine Reihe von Referenzen und Objekten enthalten, die der Client brauchen könnte. Der Client kann diese Pakete zuerst über einen Mechanismus namens [bundle-uri](https://git-scm.com/docs/bundle-uri) abrufen.\n\nDank [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/) wurde ein Problem identifiziert und behoben, bei dem Git trotz des Herunterladens einiger Bundles immer noch alles vom Remote-Server heruntergeladen hat, als gäbe es keine Bundles. Das Problem war, dass Git nicht alle heruntergeladenen Bundles korrekt erkannte, was dazu führte, dass die aufeinanderfolgenden Bundles vom Remote-Server abgerufen werden mussten. Dank diesem Fix können Remote-Server, die den Mechanismus bundle-uri verwenden, diese redundante Arbeit vermeiden und die Leistung verbessern.\n\n## Weiterlesen\n\nIn diesem Artikel wurden nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses neueste Release vorgestellt. Mehr darüber erfährst du in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) des Git-Projekts. Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.",[682,9,270],"2024-08-14",{"slug":986,"featured":91,"template":686},"whats-new-in-git-2-46-0","content:de-de:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","de-de/blog/whats-new-in-git-2-46-0.yml","de-de/blog/whats-new-in-git-2-46-0",{"_path":992,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":993,"content":999,"config":1005,"_id":1007,"_type":14,"title":1008,"_source":16,"_file":1009,"_stem":1010,"_extension":19},"/de-de/blog/whats-new-in-git-2-47-0",{"title":994,"description":995,"ogTitle":994,"ogDescription":995,"noIndex":6,"ogImage":996,"ogUrl":997,"ogSiteName":673,"ogType":674,"canonicalUrls":997,"schema":998},"Was gibt es Neues in Git 2.47.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter neue globale Variablen zum Konfigurieren von Referenz- und Objekt-Hash-Formaten. Entdecke Beträge des Git-Teams von GitLab und der gesamten Git-Community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.47.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":994,"description":995,"authors":1000,"heroImage":996,"date":1001,"body":1002,"category":10,"tags":1003,"updatedDate":1004},[943],"2024-10-07","Das Git-Projekt hat kürzlich [Git v2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) veröffentlicht.\nWerfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Neue globale Konfigurationsoptionen\n\nWenn du die letzten Git-Releases verfolgt hast, kennst du wahrscheinlich auch das Referenz-Backend „reftable“, das mit der [Git-Version 2.45](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) eingeführt wurde. Weitere Informationen findest du in unserem [Anfängerleitfaden zum reftables-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/). Um ein Repository im reftables-Format zu initialisieren, musste früher die Option `--ref-format` an git-init(1) übergeben werden:\n\n```sh\n$ git init --ref-format reftable\n```\n\nMit Release 2.47 gibt es in Git nun die Konfigurationsoption `init.defaultRefFormat`, die Git sagt, welches Referenz-Backend bei der Initialisierung eines Repositorys verwendet werden soll. Damit kann das Standard-Backend „Files“ überschrieben werden und du kannst beginnen, das reftables-Backend zu nutzen. Die Konfiguration funktioniert folgendermaßen:\n\n```sh\n$ git config set --global init.defaultRefFormat reftable\n```\n\nWie einige vielleicht wissen, ist auch das von Git-Repositories verwendete Objekt-Hash-Format konfigurierbar. Standardmäßig werden Repositories so initialisiert, dass sie das SHA-1-Objektformat verwenden. Eine Alternative ist das SHA-256-Format, das sicherer und zukunftssicherer ist. Weitere Informationen hierzu findest du in einem unserer [früheren Blogbeiträge zum SHA-256-Support in Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F). Ein SHA-256-Repository kann erstellt werden, indem die Option `--object-format' an git-init (1) übergeben wird:\n\n```sh\n$ git init --object-format sha256\n```\n\nIn dieser Git-Version wurde `init.defaultObjectFormat` als weitere Konfigurationsoption hinzugefügt. Diese Option sagt Git, welches Objektformat bei der Initialisierung eines Repositorys standardmäßig verwendet werden soll. Die Konfiguration funktioniert folgendermaßen:\n\n```sh\n$ git config set --global init.defaultObjectFormat sha256\n```\n\nBemerkenswert ist, dass SHA-256-Repositories nicht mit SHA-1 kompatibel sind und nicht alle Forges das Hosting von SHA-256-Repositories unterstützen. GitLab hat kürzlich [experimentelle Unterstützung für SHA-256-Repositories](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) angekündigt, wenn du diese ausprobieren möchtest.\n\nDiese Optionen bieten eine gute Möglichkeit, diese Repository-Funktionen zu nutzen, ohne bei jeder Initialisierung eines neuen Repositorys bewusst daran denken zu müssen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Neuer Unterbefehl für git-refs(1)\n\nIn der vorherigen Git-Version wurde der Befehl [git-refs (1)](https://git-scm.com/docs/git-refs) eingeführt, um einen Low-Level-Zugriff auf Referenzen in einem Repository zu ermöglichen und den Unterbefehl „migrate“ einzuführen, um zwischen den Referenz-Backends zu wechseln. In dieser Version wird der neue Unterbefehl „verify“ eingeführt, mit dem Benutzer(innen) die Referenzdatenbank auf Konsistenz überprüfen können. Um die Konsistenz eines Repositorys zu überprüfen, führen wir oft [git-fsck(1)](https://git-scm.com/docs/git-fsck) aus.\n\nDabei ist bemerkenswert, dass dieser Befehl die Referenzdatenbank des Repositorys jedoch nicht explizit verifiziert. Mit der Einführung des reftables-Referenzformats, das ein Binärformat ist und daher schwerer manuell zu überprüfen ist, ist es jetzt noch wichtiger, dass Werkzeuge zur Verfügung stehen, um diese Lücke zu schließen. Um das zu zeigen, wollen wir ein Repository mit einer ungültigen Referenz einrichten:\n\n```sh\n# Da das Backend \"files\" verwendet wird, können wir einfach eine ungültige Referenz erstellen.\n$ git init --ref-format files\n$ git commit --allow-empty -m \"init\"\n# Ein einzelnes '@' ist kein gültiger Referenzname.\n$ cp .git/refs/heads/main .git/refs/heads/@\n$ git refs verify\nerror: refs/heads/@: badRefName: invalid refname format\n```\n\nWir sehen hier, dass eine ungültige Referenz erkannt wurde und daher eine Fehlernachricht ausgegeben wird. Diese Werkzeuge werden zwar eher nicht von Endbenutzer(innen) ausgeführt, aber trotzdem sind sie insbesondere serverseitig praktisch, um sicherzustellen, dass Repositories konsistent bleiben. Das Ziel ist schlussendlich, diesen Befehl als Teil von git-fsck(1) zu integrieren und dadurch eine vereinheitlichte Möglichkeit zu schaffen, Konsistenzüberprüfungen von Repositories durchzuführen.\n\nDieses Projekt wurde von Jialuo She im Rahmen des Google Summer of Code geleitet. Weitere Informationen findest du im [GSoC-Bericht](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) von Jialuo.\n\n## Laufende reftables-Arbeit\n\nDiese Version enthält auch Korrekturen für einige Fehler, die im reftables-Backend gefunden wurden. Einer dieser Fehler ist besonders interessant, denn er beeinflusst, wie die Tabellenkomprimierung durchgeführt wurde.\n\nDu erinnerst dich vielleicht daran, dass das reftables-Backend aus einer Reihe von Tabellen besteht, die den Status aller Referenzen im Repository enthalten. Jeder atomare Satz an Referenzenänderungen führt dazu, dass eine neue Tabelle geschrieben und in der Datei „tables.list“ erfasst wird. Um die Anzahl der vorhandenen Tabellen zu reduzieren, werden die Tabellen nach jeder Referenzaktualisierung komprimiert und geometrisch nach Dateigröße geordnet. Nachdem die Tabellen komprimiert wurden, wird die Datei „tables.list“ mit dem neuen Status der reftables auf dem Laufwerk aktualisiert.\n\nDas System ist so konzipiert, dass es gleichzeitig möglich ist, Tabellen zu schreiben und zu komprimieren. Die Synchronisation an bestimmten Punkten wird durch Lock-Dateien gesteuert. Wenn beispielsweise eine Komprimierung gestartet wird, wird die Datei „tables.list“ von vorneherein gesperrt, sodass die Datei konsistent gelesen werden kann und auch die Tabellen, die komprimiert werden müssen, gesperrt werden können. Da die eigentliche Tabellenkomprimierung etwas dauern kann, wird die Sperre aufgehoben, sodass gleichzeitige Schreibvorgänge fortgesetzt werden können. Das ist sicher, da gleichzeitige Schreiber(innen) wissen, dass sie die nun gesperrten Tabellen, die komprimiert werden sollen, nicht verändern dürfen. Wenn die neu komprimierten Tabellen fertig geschrieben wurden, wird die Datei „tables.list“ wieder gesperrt und wird dieses Mal aktualisiert, damit der neue Tabellenzustand angezeigt wird.\n\nEs gibt jedoch ein Problem: Was passiert, wenn bei einer gleichzeitigen Referenzaktualisierung eine neue Tabelle in die „tables.list“ geschrieben wird, während eine Tabellenkomprimierung läuft, nachdem die ursprüngliche Sperre aufgehoben wurde, aber bevor die neue Listendatei geschrieben wird? Wenn diese Situation eintreten würde, würde der Komprimierungsprozess nichts von der neuen Tabelle wissen und daher die Datei „tables.list“ ohne die neue Tabelle neu schreiben. Das verhindert in weiterer Folge die gleichzeitige Aktualisierung und könnte dazu führen, dass Referenzen nicht wie erwartet hinzugefügt, aktualisiert oder entfernt werden.\n\nGlücklicherweise ist die Lösung dieses Problems ziemlich einfach. Wenn der Komprimierungsvorgang die Sperre erhält, um in die „tables.list“ zu schreiben, muss er zuerst überprüfen, ob Aktualisierungen an der Datei vorgenommen wurden und dann die Datei neu laden. Auf diese Weise wird sichergestellt, dass alle gleichzeitigen Tabellenaktualisierungen auch entsprechend einbezogen werden. Weitere Informationen zu diesem Fix findest du im entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/).\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Fixes für git-maintenance(1)\n\nWenn ein Repository wächst, ist es wichtig, dass es ordnungsgemäß gewartet wird. Standardmäßig führt Git [git-maintenance(1)](https://git-scm.com/docs/git-maintenance) nach bestimmten Operationen aus, damit der Zustand des Repositorys gesund bleibt. Um unnötige Wartung zu vermeiden, wird die Option `--auto` angegeben. Sie nutzt definierte Heuristiken, um zu bestimmen, ob Wartungsaufgaben ausgeführt werden sollen. Der Befehl kann so konfiguriert werden, dass er verschiedene Wartungsaufgaben durchführt. Standardmäßig führt er aber einfach [git-gc(1)](https://git-scm.com/docs/git-gc) im Hintergrund aus und ermöglicht es den Benutzer(innen), mit ihren Aufgaben fortzufahren.\n\nDies funktioniert wie erwartet, bis die Wartung für nicht standardmäßige Wartungsaufgaben konfiguriert ist. Wenn das passiert, werden die konfigurierten Wartungsaufgaben im Vordergrund ausgeführt und der ursprüngliche Wartungsprozess wird erst beendet, wenn alle Aufgaben abgeschlossen sind. Nur die Aufgabe „gc“ wird wie erwartet in den Hintergrund verschoben. Es hat sich gezeigt, dass sich git-gc(1), wenn es mit `--auto` ausgeführt wird, aus Versehen selbst verschob und andere Wartungsaufgaben keine Möglichkeit dazu hatten. Dies hatte das Potenzial, bestimmte Git-Befehle zu verlangsamen, da die automatische Wartung erst vollständig abgeschlossen werden musste, bevor sie beendet werden konnten.\n\nIn dieser Release wird das Problem behoben, indem git-maintenance(1) nun die Option `--detach` beigebracht wird, mit der der gesamte git-maintenance(1)-Prozess im Hintergrund läuft und nicht mehr nur einzelne Aufgaben. Die von Git durchgeführte automatische Wartung wurde ebenfalls aktualisiert, um diese neue Option zu verwenden. Weitere Informationen zu diesem Fix findest du im entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/).\n\nWeiter oben wurde erwähnt, dass die automatische Wartung eine Reihe von Heuristiken verwendet, um festzustellen, ob bestimmte Wartungsvorgänge durchgeführt werden sollen oder nicht. Leider gibt es für das „files“-Referenz-Backend, wenn [git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs) mit der Option `--auto` durchgeführt wird, keine solche Heuristik und lose Referenzen werden bedingungslos in eine „packed-refs“-Datei verpackt. Bei Repositories mit vielen Referenzen kann das erneute Schreiben der Datei „pack-refs“ ziemlich lange dauern.\n\nIn dieser Version wird daher eine Heuristik eingeführt, die entscheidet, ob lose Referenzen im „files“-Backend verpackt werden sollen. Diese Heuristik berücksichtigt die Größe der bestehenden „packed-refs“-Datei sowie die Anzahl der losen Referenzen im Repository. Je größer die „packed-refs“-Datei wird, umso höher wird die Schwelle für die Anzahl der losen Referenzen, bevor diese verpackt werden. Dadurch wird die Referenzverpackung im „files“-Backend weniger aggressiv und das Repository bleibt trotzdem gewartet. Sieh dir den entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/) an, um mehr darüber zu erfahren.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Code-Refactoring und Verbesserungen der Wartbarkeit\n\nNeben funktionalen Änderungen wird auch an der Refaktorisierung gearbeitet und der Code wird bereinigt. Diese Verbesserungen sind wichtig, da sie dazu beitragen, dem Ziel des Projektes – die Libifizierung der internen Komponenten – näherzukommen. Hier findest du einen aktuellen [Update-Thread](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/) zum Thema Libifizierung.\n\nEin Verbesserungsbereich war, Speicherlecks zu beheben. Das Git-Projekt weist einige Speicherlecks auf. In den meisten Fällen verursachen diese Lecks keine großen Probleme, da ein Git-Prozess normalerweise nur für eine kurze Zeit läuft und das System danach bereinigt wird, aber im Zusammenhang mit der Libifizierung sollte dies behoben werden. Tests im Projekt können mit einem Leck-Erkenner kombiniert werden, um Lecks zu erkennen. Aufgrund bestehender Lecks kann es jedoch schwierig zu validieren und durchzusetzen sein, dass neue Änderungen keine neuen Lecks einführen. Wir arbeiten kontinuierlich daran, alle Speicherlecks, die durch bestehende Tests im Projekt aufgedeckt werden, zu beheben. Leckfreie Tests werden anschließend mit `TEST_PASSES_SANITIZE_LEAK=true` gekennzeichnet, um anzuzeigen, dass sie in Zukunft voraussichtlich leckfrei sind. Vor dieser Release hatte das Projekt 223 Testdateien, die Speicherlecks enthielten. Mit dieser Version wurde die Zahl jetzt auf nur noch 60 gesenkt.\n\nAußerdem arbeiten wir weiterhin daran, die Verwendung globaler Variablen im gesamten Projekt zu reduzieren. Eine solche berüchtigte globale Variable ist `the_repository`, die den Status des Repositorys enthält, auf dem gearbeitet wird, und auf die im gesamten Projekt verwiesen wird. Diese Release enthält eine Reihe von Patches, mit denen `the_repository` entfernt und der Wert bei Bedarf direkt weitergegeben wird. Für Subsysteme im Git-Projekt, die immer noch von `the_repository` abhängig sind, ist `USE_THE_REPOSITORY_VARIABLE` definiert, sodass es global verwendet werden kann. Jetzt sind die Subsysteme refs, config und path nicht mehr auf deren Verwendung angewiesen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) mit Unterstützung von [John Cai](https://gitlab.com/jcaigitlab) und [Jeff King](https://github.com/peff) geleitet.\n\n## Weiterlesen\n\nIn diesem Blogbeitrag werden nur einige der Beiträge von GitLab und der breiteren Git-Community für diese neueste Release vorgestellt. Mehr darüber erfährst du in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/). Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)\n- [Was gibt es Neues in Git 2.45.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/)\n- [Ein Anfängerleitfaden zum reftables-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git pull oder git fetch: Was ist der Unterschied?](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)",[682,9,270],"2024-11-05",{"slug":1006,"featured":91,"template":686},"whats-new-in-git-2-47-0","content:de-de:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","de-de/blog/whats-new-in-git-2-47-0.yml","de-de/blog/whats-new-in-git-2-47-0",{"_path":1012,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1013,"content":1018,"config":1025,"_id":1027,"_type":14,"title":1028,"_source":16,"_file":1029,"_stem":1030,"_extension":19},"/de-de/blog/whats-new-in-git-2-48-0",{"title":1014,"description":1015,"ogTitle":1014,"ogDescription":1015,"noIndex":6,"ogImage":996,"ogUrl":1016,"ogSiteName":673,"ogType":674,"canonicalUrls":1016,"schema":1017},"Was gibt es Neues in Git 2.48.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter ein neues Build-System und eine Optimierung im neuen reftables-Backend. Entdecke Beiträge des Git-Teams von GitLab und der Git-Community.","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.48.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }\n                  ",{"title":1014,"description":1015,"authors":1019,"heroImage":996,"date":1021,"body":1022,"category":10,"tags":1023,"updatedDate":1024},[1020],"Christian Couder","2025-01-10","Das Git-Projekt hat kürzlich [Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/). Werfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Meson-Build-System\n\nLange Zeit konnte Git entweder mit einem auf [Makefile](https://de.wikipedia.org/wiki/Make) oder auf [Autoconf](https://de.wikipedia.org/wiki/GNU_Build_System#GNU_Autoconf) basierenden Build-System erstellt werden. Git-Entwickler(innen) verwendeten bis jetzt hauptsächlich das auf Makefile basierende Build-System, weshalb [das auf Autoconf basierende Build-System hinsichtlich Funktionen und Wartung hinterherhinkte](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/). Ein weiteres Problem war, dass viele Windows-Entwickler(innen) integrierte Entwicklungsumgebungen (IDEs) verwendeten, die auf Makefile und Autoconf basierende Build-Systeme nicht gut unterstützten.\n\nIm Jahr 2020 wurde die Unterstützung für die Entwicklung um Git und [CMake](https://cmake.org/) ergänzt. CMake bot eine bessere Windows-Unterstützung und IDE-Integration, insbesondere für Visual Studio. Einige moderne Build-Systemfunktionen wie Out-of-Source-Builds waren ebenfalls enthalten.\n\nVor kurzem schien es, dass der CMake-Support ebenfalls hinterherhinkte und dass es vielleicht keine gute Idee wäre, die beiden anderen Build-Systeme zu ersetzen. Also implementierte [Patrick Steinhardt](https://gitlab.com/pks-gitlab), GitLab Git Engineering Manager, Unterstützung für das [Meson-Build-System](https://mesonbuild.com/). Ziel dabei war, irgendwann die auf Autoconf, CMake und vielleicht sogar Makefile basierenden Build-Systeme zu ersetzen.\n\nDas neue, auf Meson basierende Build-System hat folgende Vorteile:\n* Benutzer(innen) können die verfügbaren Build-Optionen einfacher finden, was mit Makefiles und CMake schwierig ist.\n* Einfache Syntax im Vergleich zu Autoconf und CMake.\n* Viele verschiedene Betriebssysteme, Compiler und IDEs werden unterstützt.\n* Moderne Build-Systemfunktionen wie Out-of-Source-Builds werden unterstützt.\n\nHier ist ein Beispiel dafür, wie es tatsächlich zum Erstellen von Git verwendet werden kann:\n\n```shell\n$ cd git             \t# go into the root of Git's source code\n$ meson setup build/ \t# setup \"build\" as a build directory\n$ cd build           \t# go into the \"build\" directory\n$ meson compile      \t# actually build Git\n$ meson test         \t# test the new build\n$ meson install      \t# install the new build\n\n```\n\nMit `meson setup \u003Cbuild_dir>` können mehrere Build-Verzeichnisse eingerichtet werden, und die Konfiguration des Builds in einem Build-Verzeichnis kann durch Ausführen von `meson configure` im Build-Verzeichnis angezeigt oder geändert werden.\n\nWeitere Informationen zum Erstellen von Git mit Meson findest du oben in der [Datei `meson.build`](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build) im Git-Code-Repository. Ein [Vergleich der verschiedenen Build-Systeme](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt) für Git ist als Teil der technischen Dokumentation von Git verfügbar.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Git ist hat jetzt keine Speicherlecks mehr (wie von der Testsuite ausgeführt)\n\nIn unserem Git-Release-Blogbeitrag zur vorherigen Release Git 2.47.0 sprachen wir über unsere [laufenden Bemühungen, alle Speicherlecks zu beheben](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements), die durch bestehende Tests im Projekt aufgedeckt wurden. Wir sagten, dass das Projekt vor der Git-Release 2.47.0 223 Testdateien hatte, die Speicherlecks enthielten, und dass dies nun auf 60 reduziert wurde.\n\nWir freuen uns, dass die Speicherlecks jetzt in allen 60 verbleibenden Testdateien behoben wurden. Dadurch hat Git, wie von der Testsuite gezeigt, nun keine Speicherlecks mehr. Dies ist ein wichtiger Schritt in Richtung des langjährigen Ziels, Git-interne Komponenten zu „libifizieren“ (also diese Komponenten in interne Bibliotheken zu konvertieren). Außerdem trägt es dazu bei, Git für die Speichernutzung zu optimieren.\n\nNun darf jeder neu hinzugefügte Test standardmäßig kein Leck enthalten. Es ist immer noch möglich, Tests mit Lecks zu haben, aber die Autor(inn)en müssen dafür eine Notlösung haben und gute Argumente liefern, warum der Test nicht ohne Lecks erstellt werden kann.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Verbesserte Bundle-URI-Checks\n\nIn unserem Git-Release-Blogbeitrag zur Release von Git 2.46.0 sprachen wir über einige [Bundle-URI-Fixes](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes) von [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/).\nNach diesen Korrekturen arbeitete Xing Xin daran, dass [Abrufe mit Bundles](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/) vollständig mit dem [fsck](https://git-scm.com/docs/git-fsck)-Mechanismus wie reguläre Abrufe überprüft werden konnten.\n\nBei der Validierung von regelmäßigen Abrufen ist es möglich, [verschiedene Schweregrade](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt) für [verschiedene fsck-Probleme](https://git-scm.com/docs/git-fsck#_fsck_messages) festzulegen, um feiner steuern zu können, was in einem bestimmten Repository akzeptiert und was abgelehnt wird. Dies war zuvor für Abrufe mit Bundles nicht möglich.\n\nUm den Nutzen und die Sicherheit von [Bundle-URIs](https://git-scm.com/docs/bundle-uri) weiter zu erhöhen, haben wir [dieses Problem](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/) behoben, damit die verschiedenen Schweregrade, die für verschiedene fsck-Probleme festgelegt wurden, jetzt auch bei der Überprüfung von Abrufen mit Bundles verwendet werden können.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## Referenzkonsistenzprüfungen hinzufügen\n\nIn unserem Blogbeitrag zur Release von Git 2.47.0 erwähnten wir die Arbeit von Jialuo She an dem [neuen Unterbefehl „Verify“](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs(1) zu git-refs(1), der Teil des [Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) (GSoC 2024) war.\n\nIn diesem Blogbeitrag erläuterten wir, dass das Ziel schlussendlich darin bestand, diesen neuen Unterbefehl als Teil von git-fsck(1) zu integrieren und dadurch eine vereinheitlichte Möglichkeit zu schaffen, Konsistenzüberprüfungen von Repositories durchzuführen. Jialuo She hat beschlossen, daran zu arbeiten, nachdem sein GSoC vorbei war.\n\nDas Ergebnis [dieser Arbeit](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/) ist, dass git-fsck(1) jetzt eine Reihe von referenzbezogenen Problemen erkennen und beheben kann, z. B. wenn der Inhalt einer Referenz schlecht ist, wenn ein symbolischer Link als symbolische Referenz verwendet wird oder wenn das Ziel einer symbolischen Referenz nicht auf eine gültige Referenz verweist. Wir müssen weiterhin `git refs verify` als Teil von git-fsck(1) aufrufen und erstere alle nicht backendspezifischen Überprüfungen durchführen lassen, die letztere derzeit durchführt, aber wir sind unserem Ziel einer vereinheitlichten Möglichkeit, alle Konsistenzüberprüfungen von Refs durchzuführen, ein Stückchen näher gekommen.\n\nDieses Projekt wurde von Jialuo She geleitet.\n\n## Iterator-Wiederverwendung in reftables\n\nIn der Version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt) wurde das reftables-Format als neues Backend zum Speichern von Referenzen (meist Branches und Tags) eingeführt. Wenn du mit dem reftables-Backend noch nicht vertraut bist, lies dir unseren letzten [Blogbeitrag zur Git-Release](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) durch, in dem das Feature vorgestellt wurde. Auch unsere Anfängerleitfaden ist toll, um [mehr darüber zu erfahren, wie reftables funktionieren](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nSeit dieser Release haben wir dieses Backend weiter verbessert und uns in letzter Zeit darauf konzentriert, seine Leistung zu verbessern, indem wir beim Lesen zufälliger Referenzen [einige interne Iteratoren wiederverwenden](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/). Vor diesen Änderungen musste beim Lesen einer einzelnen Referenz ein ganz neuer Iterator erstellt, an der richtigen Stelle in den jeweiligen Tabellen gesucht und dann der nächste Wert daraus gelesen werden, was beim Lesen vieler Referenzen in schneller Folge ziemlich ineffizient sein kann. Nach der Änderung erstellen wir jetzt nur noch einen einzigen Iterator und verwenden ihn wieder, um mehrere Referenzen zu lesen, wodurch wir etwas Overhead sparen.\n\nDadurch verbessert sich die Leistung in einer Reihe von reftables-bezogenen Anwendungsfällen, so etwa ist das Erstellen vieler Referenzen in einer Transaktion, die viele zufällige Lesevorgänge durchführt, um 7 % schneller. Darüber hinaus schafft dies die Möglichkeit für weitere Optimierungen, da wir weiterhin mehr Zustände in den Iteratoren wiederverwenden können.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Unterstützung für reflogs in `git-refs migrate`\n\nNachdem das reftables-Backend in Git 2.45.0 eingeführt wurde (siehe obigen Abschnitt), haben wir in Git 2.46.0 an Tools zur Migration von Referenz-Backends gearbeitet. Ziel war, einen neuen Unterbefehl `migrate` zu git-refs(1) hinzuzufügen.\n\nIm Artikel über Git 2.46.0 [ging es um diese Arbeit](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends) und einige der Einschränkungen, die noch existierten. In dem Artikel heißt es insbesondere:\n\n„Die reflogs in einem Repository werden auch über das Referenz-Backend gespeichert und würden ebenfalls eine Formatmigration erfordern. Leider ist das Tool noch nicht in der Lage, reflogs zwischen den files- und reftables-Backends zu konvertieren.“\n\nWir freuen uns, dass wir [diese Einschränkung in Git 2.48.0 behoben haben](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/).\nReflogs können jetzt auch mit `git refs migrate` migriert werden. Das Migrationstool ist noch nicht in der Lage, ein Repository mit mehreren Arbeitsbäumen zu verwalten, aber dies ist die einzige verbleibende Einschränkung. Wenn du keine Arbeitsbäume verwendest, kannst du das reftables-Backend bereits in deinen vorhandenen Repositories nutzen.\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Optimierung von „ref-filter“\n\nDas Subsystem „ref-filter“ ist ein Formatierungscode, der von Befehlen wie `git for-each-ref`, `git branch` und `git tag` verwendet wird, um Informationen zu Git-Referenzen zu sortieren, zu filtern, zu formatieren und anzuzeigen.\n\nWenn Repositories wachsen, können sie eine große Anzahl von Referenzen enthalten. Aus diesem Grund arbeiten wir nicht nur daran, Backends zu verbessern, die Referenzen speichern, wie das reftables-Backend (siehe oben), sondern auch den Formatierungscode zu optimieren, wie zum Beispiel das Subsystem „ref-filter“.\n\nWir haben kürzlich [einen Weg gefunden](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/), wie wir vermeiden können, dass Referenzen vorübergehend gepuffert und im ref-Filtercode mehrmals wiederholt werden, wenn sie in der gleichen Sortierreihenfolge verarbeitet werden sollen, wie sie von den Backends bereitgestellt wird. Dies führt zu Speichereinsparungen und macht bestimmte Befehle in einigen Fällen bis zu 770-mal schneller.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Weiterlesen\n\nIn diesem Blogbeitrag werden nur einige der Beiträge von GitLab und der ganzen Git-Community für diese neueste Release vorgestellt. Diese kannst du in der offiziellen Versionsankündigung des Git-Projekts nachlesen. Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n\n- [Was gibt es Neues in Git 2.47.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/)\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)\n- [Was gibt es Neues in Git 2.45.0](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/)\n- [Der Anfängerleitfaden zum „reftables“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n",[682,9,270],"2025-01-20",{"slug":1026,"featured":91,"template":686},"whats-new-in-git-2-48-0","content:de-de:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","de-de/blog/whats-new-in-git-2-48-0.yml","de-de/blog/whats-new-in-git-2-48-0",{"_path":1032,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1033,"content":1038,"config":1045,"_id":1047,"_type":14,"title":1048,"_source":16,"_file":1049,"_stem":1050,"_extension":19},"/de-de/blog/whats-new-in-git-2-49-0",{"title":1034,"description":1035,"ogTitle":1034,"ogDescription":1035,"noIndex":6,"ogImage":944,"ogUrl":1036,"ogSiteName":673,"ogType":674,"canonicalUrls":1036,"schema":1037},"Was gibt es Neues in Git 2.49.0?","Erfahre mehr über die neueste Version von Git, einschließlich verbesserter Leistung dank zlib-ng, einem neuen Algorithmus zum Hashing von Namen und git-backfill(1).","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.49.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }\n                  ",{"title":1034,"description":1035,"authors":1039,"heroImage":944,"date":1041,"body":1042,"category":10,"tags":1043,"updatedDate":1044},[1040],"Toon Claes","2025-03-14","Das Git-Projekt hat kürzlich [Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/) veröffentlicht. Werfen wir einen Blick auf die Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\nDas erwartet dich:\n- [git-backfill(1) und die neue Pfad-API](#git-backfill(1)-and-the-new-path-walk-api)\n- [Einführung von zlib-ng](#introduction-of-zlib-ng)\n- [Weitere Iteration auf Meson](#continued-iteration-on-meson)\n- [Einstellung von .git/branches/ und .git/remotes/](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n- [Rust-Datenbindungen für libgit](#rust-bindings-for-libgit)\n- [Neuer Namenshashing-Algorithmus](#new-name-hashing-algorithm)\n- [Promisor-Remote-Fähigkeit](#promisor-remote-capability)\n- [Flacher Klon mit `--revision`](#thin-clone-using---revision)\n\n## git-backfill(1) und die neue Pfad-API\n\nWenn du ein Git-Repository [mit `git-clone(1)` klonst](https://git-scm.com/docs/git-clone/de), kannst du die Option [`--filter`](https://git-scm.com/docs/git-clone/de#git-clone---filterltFilter-Spezifikationgt) übergeben. Mit dieser Option kannst du einen _partiellen Klon_ erstellen. In einem partiellen Klon sendet der Server nur eine Teilmenge der erreichbaren Objekte gemäß dem angegebenen Objektfilter. Wenn du beispielsweise einen Klon mit `--filter=blob:none` erstellst, werden keine Blobs (Dateiinhalte) vom Server abgerufen und es wird ein _blobless Klon_ erstellt.\n\nBlobless-Klone haben alle erreichbaren Commits und Verzeichnisse, aber keine Blobs. Wenn du einen Vorgang wie [`git-checkout(1)`](https://git-scm.com/docs/git-checkout) durchführst, lädt Git die fehlenden Blobs herunter, um den Vorgang abzuschließen. Bei einigen Operationen wie [`git-blame(1)`](https://git-scm.com/docs/git-blame) kann dies dazu führen, dass Objekte einzeln heruntergeladen werden, wodurch der Befehl deutlich langsamer wird.\nDiese Leistungseinbuße der Performance tritt auf, weil `git-blame(1)` den Commit-Verlauf durchsuchen muss, um herauszufinden, welche spezifischen Blobs benötigt werden. Dann muss es jeden fehlenden Blob einzeln beim Server anfragen.\n\nIn Git 2.49 wird der neue Unterbefehl `git-backfill(1)` eingeführt, der verwendet werden kann, um fehlende Blobs in einem partiellen Blobless-Klon herunterzuladen.\n\nIm Hintergrund nutzt der Befehl `git-backfill(1)` die neue Pfad-API, die sich davon unterscheidet, wie Git normalerweise über Commits iteriert. Anstatt die Commits einzeln durchzugehen und die mit jedem Commit verbundenen Strukturen und Blobs rekursiv zu besuchen, durchläuft die Path-walk API die Daten nach Pfaden. Für jeden Pfad fügt sie eine Liste der assoziierten Strukturobjekte zu einem Verarbeitungsstapel hinzu. Dieser Verarbeitungsstapel wird dann in der Reihenfolge „Depth-First“ verarbeitet. Anstatt also jedes Objekt im Commit `1` zu verarbeiten, bevor sie zu Commit `2` weitergeht, verarbeitet die API alle Versionen von Datei `A` in allen Commits, bevor sie zu Datei `B` weitergeht. Dieser Ansatz verbessert die Leistung in Szenarien, in denen die Gruppierung nach Pfad unerlässlich ist, erheblich.\n\nIch verdeutliche dies in diesem Beispiel, indem ich einen Blobless-Klon von [`gitlab-org/git`](https://gitlab.com/gitlab-org/git) erstelle:\n\n\n```shell\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\nCloning into bare repository 'git.git'...\nremote: Enumerating objects: 245904, done.\nremote: Counting objects: 100% (1736/1736), done.\nremote: Compressing objects: 100% (276/276), done.\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.Resolving deltas: 100% (161482/161482), done.\n```\n\nOben verwenden wir `--bare`, um sicherzustellen, dass Git keine Blobs herunterladen muss, um den initialen Branch zu überprüfen. Wir können verifizieren, dass dieser Klon keine Blobs enthält:\n\n```sh\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nWenn du die Inhalte einer Datei im Repository anzeigen möchtest, muss Git sie herunterladen:\n\n```sh\n$ git cat-file -p HEAD:README.md\nremote: Enumerating objects: 1, done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\nGit - fast, scalable, distributed revision control system\n=========================================================\n\nGit is a fast, scalable, distributed revision control system with an\nunusually rich command set that provides both high-level operations\nand full access to internals.\n\n[snip]\n```\n\nWie du oben sehen kannst, kommuniziert Git zuerst mit dem Remote-Repository, um den Blob herunterzuladen, bevor er angezeigt werden kann.\n\nWenn du `git-blame(1)` für die Datei ausführen möchtest, muss es viel mehr herunterladen:\n\n```sh\n$ git blame HEAD README.md\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\nremote: Counting objects: 100% (1/1), done.\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\nremote: Enumerating objects: 1, done.\n\n[snip]\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n[snip]\n```\n\nWir haben die Ausgabe abgeschnitten, aber du siehst, dass Git für jede Revision dieser Datei separat auf den Server zugreift. Das ist wirklich ineffizient. Mit `git-backfill(1)` können wir Git anweisen, alle Blobs herunterzuladen:\n\n```shell\n$ git backfill\nremote: Enumerating objects: 50711, done.\nremote: Counting objects: 100% (15438/15438), done.\nremote: Compressing objects: 100% (708/708), done.\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\nResolving deltas: 100% (49154/49154), done.\nremote: Enumerating objects: 50017, done.\nremote: Counting objects: 100% (10826/10826), done.\nremote: Compressing objects: 100% (634/634), done.\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\nResolving deltas: 100% (48301/48301), done.\nremote: Enumerating objects: 47303, done.\nremote: Counting objects: 100% (7311/7311), done.\nremote: Compressing objects: 100% (618/618), done.\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\nResolving deltas: 100% (43788/43788), done.\n```\n\nDadurch werden alle Blobs wieder aufgefüllt und der Blobless-Klon wird zu einem vollständigen Klon:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\nDieses [Projekt](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/) wurde von [Derrick Stolee](https://stolee.dev/) geleitet und mit [e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae) zusammengeführt.\n\n## Einführung von zlib-ng\n\nAlle Objekte im Ordner `.git/` werden von Git mit [`zlib`](https://zlib.net/) komprimiert. `zlib` ist die Referenzimplementierung für das [RFC-1950-Format](https://datatracker.ietf.org/doc/html/rfc1950): ZLIB Compressed Data Format. `zlib` wurde 1995 entwickelt, hat eine lange Geschichte und ist unglaublich portabel, denn es unterstützt sogar viele Systeme, die älter als das Internet sind. Dank der breiten Unterstützung von Architekturen und Compilern ist es jedoch in seinen Fähigkeiten eingeschränkt.\n\nDer Fork [`zlib-ng`](https://github.com/zlib-ng/zlib-ng) wurde erstellt, um auf diese Einschränkungen einzugehen, denn `zlib-ng` ist für moderne Systeme optimiert. Dieser Fork verzichtet auf die Unterstützung von Legacy-Systemen und bietet stattdessen Patches für Intel-Optimierungen, einige Cloudflare-Optimierungen sowie mehrere kleinere Patches.\n\nDie Bibliothek `zlib-ng` selbst bietet einen Kompatibilitätslayer für `zlib`. Der Kompatibilitätslayer macht es möglich, dass `zlib-ng` ein Drop-in-Ersatz für `zlib` ist, ist jedoch nicht auf allen Linux-Distributionen verfügbar. In Git 2.49 gibt es folgende Neuerungen:\n\n- Ein Kompatibilitätslayer wurde zum Git-Projekt hinzugefügt.\n- Build-Optionen wurden sowohl zur Datei [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187) als auch zur [Meson-Build-Datei](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811) hinzugefügt.\n\nMit diesen Ergänzungen kann man einfacher von der verbesserten Performance von `zlib-ng` profitieren.\n\nIn lokalen Benchmark konnte die Geschwindigkeit um rund 25 % gesteigert werden, wenn `zlib-ng` anstelle von `zlib` verwendet wurde. Wir sind dabei, diese Änderungen auch für GitLab.com auszurollen.\n\nWenn du von den Vorteilen von `zlib-ng` profitieren möchtest, überprüfe zuerst, ob Git auf deinem Gerät bereits `zlib-ng` verwendet, indem du `git version --build-options` ausführst:\n\n```shell\n$ git version --build-options\ngit version 2.47.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nlibcurl: 8.6.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1.zlib-ng\n```\n\nWenn die letzte Zeile `zlib-ng` enthält, verwendet dein Git bereits die schnellere Variante von `zlib`. Wenn nicht, kannst du folgendermaßen vorgehen:\n\n- Bitte den/die Betreuer(in) des Git-Pakets, das du verwendest, die Unterstützung für `zlib-ng` hinzuzufügen; oder\n- Erstelle Git selbst aus der Quelle.\n\nDiese [Änderungen](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0) wurden von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) [eingeführt](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/).\n\n## Weitere Iteration auf Meson\n\nIn unserem Artikel über die Git-Version 2.48 haben wir über [die Einführung des Meson-Build-Systems](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/#meson-build-system) gesprochen. [Meson](https://de.wikipedia.org/wiki/Meson_(Build-System)) ist ein Tool für die Build-Automatisierung, das vom Git-Projekt genutzt wird und irgendwann [Autoconf](https://de.wikipedia.org/wiki/GNU_Build_System#GNU_Autoconf),\n[CMake](https://de.wikipedia.org/wiki/CMake) und sogar [Make](https://de.wikipedia.org/wiki/Make) ersetzen könnte.\n\nIn diesem Release-Zyklus wurde weiter an der Nutzung von Meson gearbeitet und es wurden verschiedene fehlende Funktionen und Fixes zur Stabilisierung eingeführt:\n\n- Die [verbesserte Testabdeckung für CI](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/) wurde in [72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709) zusammengeführt.\n  - [Einzelne Elemente für die Nutzung von Meson in `contrib/`](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/) wurden in [2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace) zusammengeführt.\n  - [Verschiedene Fixes und Verbesserungen für das Build-Verfahren basierend auf Meson](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/) wurden in [ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f) zusammengeführt.\n  - [Meson wurde auf die Erstellung von `git-subtree(1)` aufmerksam gemacht](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/), was in [3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7) zusammengeführt wurde.\n  - [Die Dokumentationsseite für die Einführung in Meson, um HTML zu erzeugen](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/) wurde in [1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694) zusammengeführt.\n\nAll diese Bemühungen wurden von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) durchgeführt.\n\n## Einstellung von .git/branches/ und .git/remotes/\n\nDu weißt wahrscheinlich, dass das Verzeichnis `.git` existiert und was es enthält. Hast du aber schon einmal von den Unterverzeichnissen `.git/branches/` und `.git/remotes/` gehört? Wie du vielleicht weißt, werden Referenzen auf Branches in `.git/refs/heads/` gespeichert. Wozu dienen also `.git/branches/` und `.git/remotes/`?\n\nBereits 2005 wurde [`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches) eingeführt, um Kurznamen für ein Remote zu speichern. Wenige Monate später wurden diese zu [`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes) verschoben.\nIm Jahr [2006](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/) lernte [`git-config(1)`](https://git-scm.com/docs/git-config), [Remotes](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl) zu speichern.\nDies wurde zur Standardmethode, um Remotes zu konfigurieren. 2011 wurden die Verzeichnisse `.git/branches/` and `.git/remotes/` als veraltet [dokumentiert](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124) und nicht mehr in modernen Repositories verwendet.\n\nIm Jahr 2024 wurde das Dokument [BreakingChanges](https://git-scm.com/docs/BreakingChanges) angelegt, um grundlegende Änderungen für die nächste große Git-Version (v3.0) darzulegen. Diese Release ist zwar in nächster Zeit nicht geplant, doch in diesem Dokument werden Änderungen dokumentiert, die wahrscheinlich Teil dieser kommenden Release sind.\nIn [8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674) wurde die Verwendung der Verzeichnisse `.git/branches/` und `.git/remotes/` zu diesem Dokument hinzugefügt, wodurch sie offiziell als veraltet gelten und in Version Git 3.0 nicht mehr enthalten sein werden.\n\nVielen Dank an [Patrick Steinhardt](https://gitlab.com/pks-gitlab), der [diese Einstellung formalisiert hat](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/).\n\n## Rust-Datenbindungen für libgit\n\nBeim Kompilieren von Git wird die interne Bibliothek `libgit.a` erstellt. Diese Bibliothek enthält einige Kernfunktionen von Git.\n\nDiese Bibliothek ist (wie der Großteil von Git) zwar in C geschrieben, in Git 2.49 wurden jedoch Datenbindungen hinzugefügt, damit einige dieser Funktionen auch in Rust zur Verfügung stehen. Dazu wurden zwei neue Cargo-Pakete erstellt: `libgit-sys` und `libgit-rs`. Diese Pakete befinden sich im Unterverzeichnis [`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib) im Git-Quellbaum.\n\nEs ist [üblich](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages), eine Bibliothek in zwei Pakete zu unterteilen, wenn ein [Foreign Function Interface](https://en.wikipedia.org/wiki/Foreign_function_interface) verwendet wird.\nDas Paket `libgit-sys` bietet die reine Schnittstelle zu C-Funktionen und verknüpft zur nativen Bibliothek `libgit.a`. Das Paket `libgit-rs` bietet eine Schnittstelle zu den Funktionen in `libgit-sys` mit einem für Rust typischen Gefühl.\n\nBisher ist die Funktionalität in diesen Rust-Paketen sehr begrenzt. Es wird nur eine Schnittstelle zur Interaktion mit `git-config(1)` geboten.\n\nDiese Initiative wurde von [Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/) geleitet und mit [a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd) zusammengeführt.\n\n## Neuer Namenshashing-Algorithmus\n\nDie Git-Objektdatenbank in `.git/` speichert die meisten ihrer Daten in Paketierungsdateien. Packfiles wurden verwendet, um Objekte über Kabel zwischen dem Git-Server und dem Client zu übertragen.\n\nAlles über das Format erfährst du unter [`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack). Ein wichtiger Aspekt der Paketierungsdateien ist die Delta-Komprimierung. Bei der Delta-Komprimierung wird nicht jedes Objekt so gespeichert, wie es ist, sondern manche Objekte werden als _delta_ einer anderen _base_ gespeichert. Anstatt also den gesamten Inhalt der Objekte zu speichern, werden die Änderungen im Vergleich zu einem anderen Objekt gespeichert.\n\nOhne auf die Details einzugehen, wie diese Deltas berechnet oder gespeichert werden, kannst du dir vorstellen, dass es wichtig ist, sehr ähnliche Dateien zu gruppieren. In v2.48 und früheren Versionen verglich Git die letzten 16 Zeichen der Pfadnamen, um festzustellen, ob Blobs ähnlich sind. Dieser Algorithmus wird Version `1` genannt.\n\nAb Git 2.49 ist Version `2` verfügbar. Dies ist eine Iteration von Version `1`, jedoch so verändert, dass die Auswirkungen des übergeordneten Verzeichnisses reduziert werden. Du kannst die Version des Namenshashing-Algorithmus, die du verwenden möchtest, mit der Option `--name-hash-version` von [`git-repack(1)`](https://git-scm.com/docs/git-repack) festlegen.\n\n[Derrick Stolee](https://stolee.dev/), der dieses Projekt vorangetrieben hat, verglich die resultierende Größe der Paketierungsdateien, nachdem er `git repack -adf--name-hash-version=\u003Cn>` ausgeführt hatte:\n\n| Repository                                          \t| Größe Version 1   | Größe Version 2 |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n| Repository B                                        \t| 6.248 MB   | 856 MB   |\n| Repository C                                        \t| 37.278 MB  | 6.921 MB |\n| Repository D                                        \t| 131.204 MB | 7.463 MB |\n\nWeitere Details findest du im [Patch-Set](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/), das in [aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51) zusammengeführt wurde.\n\n## Promisor-Remote-Fähigkeit\n\nEs ist bekannt, dass Git nicht gut mit großen Dateien umgehen kann. Es gibt einige Lösungen für dieses Problem wie [Git LFS](https://git-lfs.com/), die jedoch immer noch Mängel aufweisen. Einige davon sind Folgende:\n\n- Mit Git LFS muss der/die Benutzer(in) konfigurieren, welche Dateien in den LFS kommen sollen. Der Server hat keine Kontrolle darüber und muss alle Dateien bereitstellen.\n- Wenn eine Datei ins Repository committet wird, gibt es keine Möglichkeit, sie wieder herauszuholen, ohne den Verlauf neu zu schreiben. Das ist vor allem bei großen Dateien ärgerlich, da sie dadurch für immer dort festhängen.\n- Benutzer(innen) können nicht ändern, welche Dateien im Git LFS abgelegt werden sollen.\n- Es ist schwierig, ein Tool wie Git LFS richtig einzurichten, den Umgang damit zu erlernen und es zu nutzen.\n\nSeit einiger Zeit verfügt Git über das Konzept der Promisor Remotes. Diese Funktion kann für große Dateien genutzt werden und wurde in Git 2.49 noch einen Schritt weiterentwickelt.\n\nDie Idee hinter der neuen Promisor-Remote-Fähigkeit ist relativ einfach: Anstatt alle Objekte selbst zu senden, kann ein Git-Server dem Git-Client sagen: „Lade diese Objekte von _XYZ_ herunter.“ _XYZ_ ist der Promisor Remote.\n\nGit 2.49 ermöglicht es dem Server, die Informationen des Promisor Remote an den Client weiterzugeben. Diese Änderung ist eine Erweiterung von [`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2). Während der Server und der Client Daten hin und her übertragen, kann der Server Namen und URLs der Promisor Remotes senden, die er kennt.\n\nDerzeit verwendet der Client die Promisor-Remote-Infos, die er vom Server während des Klonens erhält, nicht, sodass weiterhin alle Objekte vom Remote zu dem Klon übermittelt werden, von dem aus der Vorgang initiiert wurde. Wir planen, diese Funktion weiter zu verbessern, sodass die Promisor-Remote-Info vom Server genutzt werden kann und die Funktion benutzerfreundlicher wird.\n\nDieses [Patch-Set](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/) wurde von [Christian Couder](https://gitlab.com/chriscool) eingereicht und mit [2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c) zusammengeführt.\n\n## Flacher Klon mit `--revision`\n\nDie neue Option `--revision` wurde zu [`git-clone(1)`](https://git-scm.com/docs/git-clone/de) hinzugefügt. Auf diese Weise kannst du einen flachen Klon eines Repository erstellen, der nur den Verlauf der jeweiligen Revision enthält. Die Option ist ähnlich wie `--branch`, akzeptiert aber einen ref-Namen (wie `refs/heads/main`, `refs/tags/v1.0` und `refs/merge-requests/123`) oder eine hexadezimale Commit-Objekt-ID. Der Unterschied zu `--branch` ist, dass kein Tracking-Branch erstellt und `HEAD` abgetrennt wird. Diese Option ist also nicht geeignet, wenn du wieder zu diesem Branch beitragen möchtest.\n\nDu kannst `--revision` in Kombination mit `--depth` verwenden, um einen minimalen Klon zu erstellen. Ein vorgeschlagener Anwendungsfall ist das automatisierte Testen. Wenn du ein CI-System hast, bei dem ein Branch (oder eine beliebige Referenz) ausgecheckt werden muss, um autonome Tests am Quellcode durchzuführen, brauchst du nur einen minimalen Klon.\n\nDiese [Änderung](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a) wurde von [Toon Claes](https://gitlab.com/toon) [vorangetrieben](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/).\n\n# Mehr erfahren\n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n- [Was gibt es Neues neu in Git 2.47.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/)\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)",[270,9,682],"2025-04-08",{"slug":1046,"featured":91,"template":686},"whats-new-in-git-2-49-0","content:de-de:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","de-de/blog/whats-new-in-git-2-49-0.yml","de-de/blog/whats-new-in-git-2-49-0",{"_path":1052,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1053,"content":1057,"config":1068,"_id":1070,"_type":14,"title":1071,"_source":16,"_file":1072,"_stem":1073,"_extension":19},"/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":1054,"title":1055,"description":1056},{"noIndex":6},"Warum Unabhängigkeit in DevSecOps wichtiger ist denn je","Führungskräfte hinterfragen die Kontrolle ihrer Entwicklungsinfrastruktur. GitLabs Unabhängigkeit ist relevanter denn je.\n",{"title":1055,"description":1058,"authors":1059,"date":1061,"body":1062,"category":1063,"tags":1064,"heroImage":1067},"Unternehmen hinterfragen, wer ihre Entwicklungsinfrastruktur wirklich kontrolliert. Deshalb gilt: GitLabs Unabhängigkeit ist relevanter denn je.\n",[1060],"Robin Schulman","2025-09-02","Seit über einem Jahrzehnt setzt sich GitLab für Transparenz, Unabhängigkeit und die Priorisierung von Entwickler(inne)n ein. Heute ist das wichtiger denn je, während sich die Branche weiterentwickelt. Unternehmensführungen stellen kritische Fragen: Wer kontrolliert letztendlich die Entwicklungsinfrastruktur? Wie wird der Code in KI-Systemen verwendet? Was passiert, wenn sich Anbieter-Prioritäten von kritischen Anforderungen wegbewegen?\n\nLetzten Monat [kündigten wir GitLab 18.3 an](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/), die neueste Version unserer KI-nativen DevSecOps-Plattform. Agent Insights, Teil der GitLab Duo Agent Platform, bietet Einblicke in die Entscheidungsprozesse der Agenten. Erweiterte KI-Modellunterstützung bedeutet keine Anbieterabhängigkeit. Verbesserte Governance-Kontrollen ermöglichen Compliance über mehrere Rechtsräume hinweg.\n\nDas sind nicht nur Funktionen. Es sind Beispiele für Transparenz, Unabhängigkeit und den entwicklerorientierten Ansatz, der GitLab definiert. So setzt sich diese Strategie in der Praxis um.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1115249475?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Who is GitLab_Robin_090225_FINAL\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## KI-Transparenz über den gesamten DevSecOps-Lebenszyklus\n\n**Bei GitLab adressiert unser jahrzehntelanges Engagement für Transparenz diese Bedenken direkt.** Da künstliche Intelligenz zunehmend in Entwicklungs-Workflows integriert wird, sind Organisationen zu Recht besorgt darüber, wie Code und Daten für KI-Training verwendet werden.\n\nDas GitLab [KI-Transparenzzentrum](https://about.gitlab.com/de-de/ai-transparency-center/), im April 2024 gestartet, bietet eine klare Dokumentation unserer Datenverarbeitungspraktiken, Datenschutzmaßnahmen und ethischen KI-Prinzipien. Im Gegensatz zu Plattformen, die KI-Funktionen mit unklaren Datennutzungsrichtlinien betreiben, priorisiert GitLab Transparenz, damit Kund(inn)en [genau verstehen, wie Daten verarbeitet werden](https://docs.gitlab.com/user/gitlab_duo/data_usage/), gespeichert und geschützt werden – ohne Training mit diesen Daten.\n\nUnser Ansatz erstreckt sich auf Modellflexibilität und Anbieterunabhängigkeit. Während einige Plattformen Kund(inn)en an einzelne Large Language Model (LLM)-Anbieter binden und damit zusätzliche Anbieterabhängigkeiten und potenzielle Single Points of Failure schaffen, werden GitLabs KI-Funktionen von verschiedenen Modellen unterstützt. Dieser Ansatz ermöglicht es uns, eine breite Palette von Anwendungsfällen zu unterstützen und bietet Kund(inn)en die Flexibilität, sich an strategischen Prioritäten auszurichten.\n\nBei der Weiterentwicklung der GitLab Duo Agent Platform bleiben wir auf Datenkontrolle fokussiert und behalten umfassende Human-in-the-Loop-Kontrollen bei. Und GitLab Duo Self-Hosted bietet vollständige Datensouveränität mit luftdichten Bereitstellungsoptionen, Zero-Day-Datenaufbewahrungsrichtlinien und der Möglichkeit, alle KI-Anfragen innerhalb der eigenen Infrastruktur zu verarbeiten.\n\nSeit Mai 2024 pflegen wir auch einen [KI-Kontinuitätsplan](https://handbook.gitlab.com/de-de/handbook/product/ai/continuity-plan/) mit einem branchenführenden Versprechen: die Fähigkeit, innerhalb von 30 Tagen ein neues Modell zu evaluieren und zu wechseln, falls ein Anbieter seine Praktiken bezüglich Kundendaten ändert. Dieser proaktive Ansatz zum KI-Anbieter-Risikomanagement spiegelt unser Engagement für Kundenkontrolle wider.\n\n## Wahlfreiheit bei Bereitstellung und Cloud-Anbieter\n\n**Organisationen sollten wählen können, wie und wo die DevSecOps-Umgebung bereitgestellt wird.** GitLab bietet echte Bereitstellungsflexibilität. Organisationen können zwischen On-Premises-Installationen, Multi-Tenant-SaaS oder GitLab Dedicated wählen, unserer vollständig verwalteten Single-Tenant-SaaS-Lösung, ohne auf Funktionalität zu verzichten oder künstlichen Einschränkungen ausgesetzt zu sein, die auf Ökosystem-Lock-in abzielen. GitLab ist auch Cloud-neutral, sodass Kund(inn)en den Cloud-Anbieter nutzen können, der am besten zu Geschäftsanforderungen und Umgebung passt.\n\nDiese Flexibilität erweist sich als unschätzbar wertvoll bei der Navigation durch komplexe rechtliche Anforderungen und regulatorische Herausforderungen. Wenn neue Datenlokalisierungsgesetze entstehen – wie wir es in der Europäischen Union und anderen Regionen gesehen haben – können Organisationen, die GitLab nutzen, ihre Bereitstellungsstrategien schnell anpassen, ohne durch Ökosystemabhängigkeiten eingeschränkt zu sein.\n\nAus Beschaffungs- und Risikomanagement-Perspektive bietet Plattformunabhängigkeit auch entscheidende Verhandlungsmacht bei Vertragsverhandlungen. Organisationen werden nicht in restriktive Lizenzvereinbarungen gezwungen, die Anbieterinteressen über Kundenbedürfnisse stellen. Diese Unabhängigkeit wird besonders kritisch, da Unternehmen wachsamer werden, wer ihren KI-Stack kontrolliert.\n\n## Sicherheit und Compliance: Eingebaut und immer Priorität\n\n**Sicherheit und Compliance sind jetzt genauso wichtig wie Entwicklungsfunktionen und sollten in die Plattform eingebaut sein, nicht nachträglich hinzugefügt.** GitLabs Single-Platform-Ansatz bietet erhebliche Vorteile gegenüber fragmentierten Plattformen, die auf Drittanbieter-Add-Ins angewiesen sind, um grundlegende Sicherheits- und Governance-Funktionen zu erreichen. Dieser architektonische Unterschied hat erhebliche Auswirkungen auf mögliche rechtliche Risiken, operative Effizienz und regulatorische Compliance. Jedes zusätzliche Tool in der Kette stellt einen weiteren potenziellen Fehlerquellen dar, weitere Geschäftsbedingungen, die verhandelt werden müssen, und eine weitere Risikoquelle.\n\nGitLab bietet umfassende eingebaute Sicherheits- und Compliance-Funktionen, einschließlich kundenspezifischer Compliance-Frameworks, dynamischem Application Security Testing (DAST), API-Fuzz-Testing, Coverage-Guided Fuzzing und Infrastructure-as-Code-Testing. Diese Funktionen sind nativ in die Plattform integriert und bieten konsistente Richtliniendurchsetzung und reduzieren die Compliance-Komplexität und zusätzlichen Kosten, die mit der Verwaltung mehrerer Drittanbieter-Tools verbunden sind.\n\nUnser [Compliance-Center](https://docs.gitlab.com/user/compliance/compliance_center/) bietet einen zentralen Ort für Teams, um ihre Compliance-Standards, Compliance-Berichte, Verstöße und Compliance-Frameworks für ihre Gruppe zu verwalten. Dieser einheitliche Ansatz für das Compliance-Management ist besonders wertvoll für Organisationen in stark regulierten Branchen, in denen Audit-Trails und Compliance-Dokumentation kritisch sind.\n\n## Nähe zur Open-Source-Community\n\n**Die besten Tools werden von den Menschen geprägt, die sie nutzen.** Unser Engagement für Open Source und die Zusammenarbeit mit unserer Community ist seit unserer Gründung Kern von GitLab. Beispielsweise ist unser [Co-Create-Programm](https://about.gitlab.com/community/co-create/) eine kollaborative Initiative, die es Kund(inn)en ermöglicht, direkt mit GitLab-Ingenieur(inn)en zusammenzuarbeiten, um Funktionen, Fixes und Verbesserungen zur GitLab-Plattform beizutragen.\n\nUnser Transparenzwert bleibt grundlegend für unser Geschäft. Ein Beispiel dafür ist unser [offener Issue-Tracker](https://gitlab.com/groups/gitlab-org/-/issues), in dem Kund(inn)en unseren Fortschritt verfolgen und direkt mit dem GitLab-Team in Diskussionen über Verbesserungsmöglichkeiten unseres Produkts eintreten können. Wir haben kürzlich unsere [Healthy Backlog Initiative](https://about.gitlab.com/de-de/blog/inside-gitlabs-healthy-backlog-initiative/) gestartet, um Kund(inn)en noch größere Einblicke in unsere Planung zu geben und ihr Feedback an Stellen mit der größten Wirkung zu lenken.\n\nUnser Ansatz ermöglicht es Organisationen, zu Open-Source-Innovation beizutragen und davon zu profitieren, während sie die Governance, Audit-Trails und Sicherheitskontrollen beibehalten, die für regulierte Umgebungen erforderlich sind.\n\n## Daten-Governance: Die Daten, die Kontrolle\n\n**Vollständige Kontrolle über Daten und deren Verarbeitung bleibt erhalten.** Daten-Governance ist zu einem immer kritischeren Faktor bei Unternehmensentscheidungen geworden, angetrieben durch ein komplexes Netz nationaler und regionaler Datenschutzgesetze und wachsende Bedenken über die Kontrolle sensibler geistiger Eigentumsrechte – wie Quellcode, Kundeneinblicke, strategische Initiativen und Wettbewerbsinformationen.\n\nMit GitLab kann verwaltet werden, wer Zugang zu KI-gestützten Funktionen innerhalb der Plattform hat, was über einfache Zugriffskontrollen hinausgeht und Verschlüsselungsstandards und Audit-Funktionen umfasst, die auf regulatorische Frameworks ausgerichtet sind. Außerdem werden Code und Daten von Kund(inn)en niemals zum Training von KI-Modellen verwendet.\n\n## Die Wahl ist klar\n\nGitLab führt weiterhin bei KI-nativer DevSecOps-Plattform-Innovation – unsere jüngste [18.3-Version](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/) zeigt dies – während wir den Unabhängigkeits- und Transparenzverpflichtungen treu bleiben, die uns immer geleitet haben.\n\nKund(inn)en haben eine Wahl und sie ist klar: Kontrolle behalten vs. Anbieterabhängigkeit; Transparenz vs. Unsicherheit; Engagement für Innovation vs. Launen des größeren Ökosystems.\n\nGitLab bietet die Grundlage für nachhaltige digitale Transformation, die Innovation mit Unabhängigkeit ausbalanciert und dabei hilft, Geschäftswert für Kund(inn)en zu erzielen.\n\n[GitLab Ultimate mit GitLab Duo heute kostenlos testen.](https://about.gitlab.com/de-de/free-trial/)","ai-ml",[1065,842,703,1066,9],"AI/ML","features","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756500636/wmey6kqzzuhirk88w2de.png",{"featured":91,"template":686,"slug":1069},"why-enterprise-independence-matters-more-than-ever-in-devsecops","content:de-de:blog:why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","Why Enterprise Independence Matters More Than Ever In Devsecops","de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"_path":1075,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1076,"content":1082,"config":1087,"_id":1089,"_type":14,"title":1090,"_source":16,"_file":1091,"_stem":1092,"_extension":19},"/de-de/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1077,"description":1078,"ogTitle":1077,"ogDescription":1078,"noIndex":6,"ogImage":1079,"ogUrl":1080,"ogSiteName":673,"ogType":674,"canonicalUrls":1080,"schema":1081},"Der Anfängerleitfaden zum „reftable“-Format von Git","In Git 2.45.0 hat GitLab das reftable Backend in Git eingeführt – dies verändert die Art und Weise, wie Referenzen gespeichert werden, von Grund auf. Erhalte detaillierte Einblicke, wie dieses neue Format funktioniert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der Anfängerleitfaden zum „reftable“-Format von Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":1077,"description":1078,"authors":1083,"heroImage":1079,"date":1084,"body":1085,"category":10,"tags":1086,"updatedDate":981},[678],"2024-05-30","Bis vor Kurzem war das „files“-Format die einzige Möglichkeit in Git, Referenzen zu speichern. Mit der [Version Git 2.45.0](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) kann Git nun Referenzen im „reftable“-Format speichern. Dieses neue Format ist ein Binärformat, das deutlich komplexer als das alte “files” Format ist. Diese Komplexität ermöglicht es jedoch, einige Mängel des „files“-Formats zu beheben. Die Entwicklungsziele des „reftable“-Formats sind unter anderem folgende:\n\n- Die Suche nach einzelnen Referenzen und die Iterationen über zahlreichen Referenzen soll so effizient und schnell wie möglich sein.\n- Das konsistente Lesen von Referenzen soll unterstützt werden, sodass Git nie einen Zwischenzustand liest, wenn ein Update an mehreren Referenzen nur teilweise angewendet wurde.\n- Atomares Schreiben soll unterstützt werden, sodass die Aktualisierung von mehreren Referenzen nur entweder vollständig oder gar nicht möglich ist.\n- Effiziente Speicherung von Referenzen und Reflog-Einträgen.\n\nIn diesem Artikel kommen wir allen Feinheiten des „reftable“-Formats auf die Schliche und sehen uns genau an, wie es funktioniert.\n\n## So speichert Git Referenzen\n\nBevor wir uns die Details des „reftable“-Formats ansehen, fassen wir nochmals kurz zusammen, wie Git in der Vergangenheit Referenzen gespeichert hat. Wenn du damit bereits vertraut bist, kannst du gleich zum nächsten Abschnitt springen.\n\nEin Git-Repository enthält zwei wesentliche Datenstrukturen:\n\n- [Objekte](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects), die die eigentlichen Daten deines Repositorys enthalten. Dazu gehören Commits, die Verzeichnisstruktur und die Blobs, die deinen Quellcode enthalten. Objekte verweisen aufeinander und bilden so einen Objektgraphen. Außerdem hat jedes Objekt eine Objekt-ID, durch die es eindeutig identifiziert wird.\n\n- Referenzen wie Branches und Tags sind Wegweiser im Objektgraphen, sodass du Objekten Namen geben kannst, die einfacher zu merken sind, und verschiedene Wege deines Entwicklungsverlaufs nachverfolgen kannst. Ein Repository kann zum Beispiel einen `main`-Branch enthalten, der eine Referenz mit dem Namen `refs/heads/main` ist und auf einen bestimmten Commit zeigt.\n\nReferenzen werden in der Referenzdatenbank gespeichert. Bis Git 2.45.0 gab es nur das Datenbankformat „files“. In diesem Format wird jede Referenz als einfache Datei gespeichert, die eines der folgenden Elemente enthält:\n\n- Eine normale Referenz, die die Objekt-ID des Commits enthält, auf den sie zeigt.\n- Eine symbolische Referenz, die den Namen einer anderen Referenz enthält. Dies ist ähnlich wie ein symbolischer Link, der auf eine andere Datei zeigt.\n\nIn regelmäßigen Abständen werden diese Referenzen in eine einzige `packed-refs`-Datei komprimiert, damit Referenzen effizienter durchsucht werden können.\n\nDie folgenden Beispiele sollen eine Vorstellung davon geben, wie das „files“-Format funktioniert:\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD ist eine symbolische Referenz, die auf refs/heads/main zeigt.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main ist eine normal Referenz, die auf einen Commit zeigt.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) komprimiert diese Referenzen in eine packed-refs Datei.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Hochrangige Struktur von reftables\n\nWenn du nun Git 2.45.0 oder eine neuere Version installiert hast, kannst du ein Repository mit dem „reftable“-Format erstellen, indem du den Switch `--ref-format=reftable` verwendest:\n\n```shell\n$ git init --ref-format=reftable .Initialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevante Dateien wurden für ein einfacheres Verständnis entfernt.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nSieh dir zunächst die Repository-Konfiguration an. Du wirst feststellen, dass sie den Schlüssel `extension.refstorage` enthält:\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nDiese Konfiguration teilt Git mit, dass das Repository mit dem „reftable“-Format initialisiert wurde und gibt an, dass Git das „reftable“-Backend nutzen muss, um darauf zuzugreifen.\n\nSeltsamerweise enthält das Repository immer noch einige Dateien, die aussehen, als würde das „files“-Backend verwendet werden:\n\n- `HEAD` würde normalerweise eine symbolische Referenz sein, die auf deinen derzeit ausgecheckten Branch zeigt. Obwohl es nicht vom „reftable“-Backend verwendet wird, ist es für Git-Clients erforderlich, um das Verzeichnis als Git-Verzeichnis zu erkennen. Wenn du also das „reftable“-Format verwendest, ist `HEAD` ein Stub mit dem Inhalt `ref: refs/heads/.invalid`.\n\n- `refs/heads` ist eine Datei mit dem Inhalt `this repository uses the reftable format`. Git-Clients, die das Format „reftable“ nicht kennen, würden normalerweise erwarten, dass dieser Pfad ein Verzeichnis ist. Wenn du also diesen Pfad bewusst als Datei erstellst, führt dies dazu, dass ältere Git-Clients fehlschlagen, wenn sie versuchen, mit dem „files“-Backend auf das Repository zuzugreifen.\n\nDie tatsächlichen Referenzen werden im Verzeichnis `reftable/` gespeichert:\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├──0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nEs gibt hier zwei Dateien:\n\n- `0x000000000001-0x000000000001-794bd722.ref` ist eine Tabelle mit Referenzen und den Reflog-Einträgen in einem Binärformat.\n\n- `tables.list` ist eine Liste von Tabellen. Im aktuellen Status des Repositorys enthält die Datei eine Zeile, die der Name der Tabelle ist. Diese Datei verfolgt den aktuellen Satz aktiver Tabellen in der „reftable“-Datenbank und wird aktualisiert, wenn neue Tabellen zum Repository hinzugefügt werden.\n\nWenn du eine Referenz aktualisierst, wird eine neue Tabelle erstellt:\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├──0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nWie du sehen kannst, wurde die vorherige Tabelle durch eine neue ersetzt. Darüber hinaus wurde die Datei `tables.list` aktualisiert und enthält nun die neue Tabelle.\n\n## Die Struktur einer Tabelle\n\nWie bereits erwähnt, sind die eigentlichen Daten der Referenzdatenbank in Tabellen enthalten. Grob gesagt ist eine Tabelle in mehrere Abschnitte unterteilt:\n\n- Der „Header“ enthält Metadaten zur Tabelle. Dazu gehören unter anderem die Version des Formats, die Blockgröße und die vom Repository verwendete Hash-Funktion (z. B. SHA1 oder SHA256).\n- Der Abschnitt „Ref“ enthält deine Referenzen. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht und entweder auf eine Objekt-ID für reguläre Referenzen oder auf eine andere Referenz für symbolische Referenzen zeigt.\n- Der Abschnitt „Obj“ enthält die umgekehrte Zuordnung von Objekt-IDs zu den Referenzen, die auf diese Objekt-IDs zeigen. Diese ermöglichen es Git, effizient zu suchen, welche Referenzen auf eine bestimmte Objekt-ID zeigen.\n- Der Abschnitt „Log“ enthält deine Reflog-Einträge. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht, sowie einen Index, der die Nummer des Reflog-Eintrags darstellt. Außerdem enthalten sie die alten und neuen Objekt-IDs sowie die Nachricht für diesen Reflog-Eintrag.\n- Der „Footer“ enthält Zeiger zu den verschiedenen Abschnitten.\n\n![Lange Tabelle mit allen reftable-Abschnitten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nDie Abschnittstypen sind alle ähnlich strukturiert. Abschnitte enthalten eine Reihe von Datensätzen, die nach den Schlüsseln der einzelnen Datensätze sortiert sind. Wenn du zum Beispiel zwei Ref-Datensätze `refs/heads/aaaaa` und `refs/heads/bbb` hast, hast du zwei Ref-Datensätze mit diesen Referenznamen als jeweiligen Schlüssel, weshalb `refs/heads/aaaaa` vor `refs/heads/bbb` kommt.\n\nDarüber hinaus ist jeder Abschnitt in Blöcke mit einer festen Länge unterteilt. Diese Blocklänge ist im Header codiert und dient zwei Zwecken:\n\n- Da sie den Anfang des Abschnitts markieren und die Blockgröße angeben, weiß der bzw. die Leser(in) implizit, wo jeder der Blöcke beginnt. Dadurch kann Git gleich in die Mitte des Abschnitts springen, ohne vorherige Blocks lesen zu müssen. So kann die binäre Suche in Blöcken das Durchsuchen von Datensätzen beschleunigen.\n- Sie stellt sicher, dass Git weiß, wie viele Daten gleichzeitig von der Festplatte gelesen werden sollen. Folglich ist die Blockgröße standardmäßig auf 4 KiB eingestellt, was die häufigste Sektorgröße für Festplatten ist. Die maximale Blockgröße beträgt 16 MB.\n\nWenn wir zum Beispiel in einen „ref“-Abschnitt schauen, sieht er ungefähr wie die folgende Grafik aus. Achte darauf, wie die Datensätze lexikografisch in den Blocks, aber auch blockübergreifend sortiert sind.\n\n![Referenzblock, nicht komprimiert](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMit diesem Wissen können wir nun einen Datensatz finden, indem wir die folgenden Schritte befolgen:\n\n1. Führe eine Binärsuche über die Blocks durch, indem du dir die Schlüssel der jeweiligen ersten Datensätze ansiehst und den Block identifizierst, der unseren Datensatz enthalten muss.\n\n2. Führe eine lineare Suche in den Datensätzen dieses Blocks durch.\n\nBeide Schritte sind immer noch recht ineffizient. Wenn wir viele Blöcke haben, müssen wir logarithmisch viele davon in unserer Binärsuche lesen, um den gewünschten Block zu finden. Und wenn Blöcke viele Datensätze enthalten, müssen wir vielleicht bei der linearen Suche alle davon lesen.\n\nDas „reftable“-Format verfügt über zusätzliche integrierte Mechanismen, um diese Leistungsbedenken auszuräumen. Wir gehen in den nächsten Abschnitten darauf ein.\n\n### Präfix-Komprimierung\n\nWie du vielleicht bemerkt hast, haben alle Datensatzschlüssel das gleiche Präfix `refs/`. Dies ist häufig so in Git:\n\n- Alle Branches beginnen mit `refs/heads/`.\n- Alle Tags beginnen mit `refs/tags/`.\n\nDaher gehen wir davon aus, dass nachfolgende Datensätze höchstwahrscheinlich einen signifikanten Anteil ihres Schlüssels gemeinsam haben. Dies ist eine gute Gelegenheit, um wertvollen Speicherplatz zu sparen. Da wir wissen, dass die meisten Schlüssel ein gemeinsames Präfix haben, ist es sinnvoll, dies zu optimieren.\n\nDie Optimierung verwendet Präfix-Komprimierung. Jeder Datensatz kodiert eine Präfixlänge, die den Leser(innen) mitteilt, wie viele Bytes des Schlüssels des vorhergehenden Datensatzes wiederverwendet werden sollen. Wenn wir zwei Datensätze haben, `refs/heads/a` und `refs/heads/b`, kann letzterer kodiert werden, indem man eine Präfixlänge von 11 angibt und dann nur das Suffix `b` speichert. Die Leser(innen) nehmen dann die ersten 11 Bytes von `refs/heads/a`, was `refs/heads/` ist, und fügen das Suffix `b` hinzu.\n\n![Präfix-Komprimierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### Neustart-Punkte\n\nWie bereits erklärt, ist eine lineare Suche der beste Weg, mit unserem derzeitigen Wissen über das „reftable“-Format in einem Block nach einer Referenz zu suchen. Der Grund dafür ist, dass die Datensätze keine fixe Länge haben. Daher können wir nicht feststellen, wo Datensätze beginnen, ohne von Anfang an den Block zu durchsuchen. Auch wenn Datensätze eine fixe Länge hätten, könnten wir nicht in der Mitte eines Blocks suchen, da die Präfix-Kompression erfordert, dass wir auch die vorhergehenden Datensätze lesen.\n\nEine lineare Suche wäre ziemlich ineffizient, da Blöcke Hunderte oder sogar Tausende von Datensätzen enthalten können. Um dieses Problem zu beheben, codiert das „reftable“-Format sogenannte Neustart-Punkte in jeden Block. Neustart-Punkte sind unkomprimierte Datensätze, bei denen keine Präfix-Komprimierung verwendet wird. Folglich enthalten Datensätze an Neustart-Punkten immer ihren vollständigen Schlüssel, und es wird möglich, den Datensatz direkt zu suchen und zu lesen, ohne die vorhergehenden Datensätze lesen zu müssen. Diese Neustart-Punkte sind in der Fußzeile jedes Blocks aufgeführt.\n\nMit diesen Informationen können wir eine lineare Suche über den Block vermeiden. Stattdessen können wir jetzt eine Binärsuche über die Neustart-Punkte durchführen, bei der wir nach dem ersten Neustart-Punkt mit einem Schlüssel suchen, der lexikographisch größer ist als der gesuchte Schlüssel. Daraus folgt, dass sich der gewünschte Datensatz in dem Abschnitt befinden muss, der sich vom _vorhergehenden_ Neustart-Punkt bis zum identifizierten Neustart-Punkt erstreckt.\n\nDaher ist unser erstes Vorgehen bei der Suche nach einem Datensatz (Binärsuche nach dem Block, Linearsuche nach dem Datensatz) nun wie folgt:\n\n1. Führe eine Binärsuche über die Blocks durch und finde den Block, der unseren Datensatz enthalten muss.\n\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts. \n\n![Lineare Suche nach einem Datensatz](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Indizes\n\nDie Suche nach Datensätzen in einem Block wäre nun einigermaßen effizient. Es ist aber weiterhin ineffizient, den Block selbst zu finden. Eine Binärsuche kann bei ein paar Blöcken funktionieren, aber Repositories mit Millionen von Referenzen können Hunderte oder sogar Tausende von Blöcken haben. Ohne zusätzliche Datenstruktur würde dies durchschnittlich logarithmisch viele Festplattenzugriffe verursachen.\nUm dies zu vermeiden, kann auf jeden Abschnitt ein Indexabschnitt folgen, der eine effiziente Möglichkeit bietet, einen Block nachzuschlagen. Jeder Indexdatensatz enthält die folgenden Informationen:\n\n- Die Position des Blocks, den er indiziert.\n- Der Schlüssel des letzten Datensatzes des Blocks, den er indiziert.\n\nBei drei oder weniger Blöcken erfordert eine Binärsuche immer höchstens zwei Festplattenlesevorgänge, um den gewünschten Zielblock zu finden. Dies ist die gleiche Anzahl von Lesevorgängen, die wir mit einem Index hätten: einen, um den Index selbst zu lesen, und einen, um den gewünschten Block zu lesen. Folglich werden Indizes nur geschrieben, wenn sie tatsächlich einige Lesevorgänge einsparen würden, was ab vier indizierten Blöcken der Fall ist.\n\nNun stellt sich die Frage: Was passiert, wenn der Index selbst so groß wird, dass er sich über mehrere Blöcke erstreckt? Du hast es vielleicht erraten: Wir schreiben einen weiteren Index, der den Index indiziert. Diese mehrstufigen Indizes werden erst dann wirklich notwendig, wenn du Repositories mit hunderttausenden von Referenzen hast.\n\nMit diesen Indizes können wir jetzt das Verfahren zum Nachschlagen von Datensätzen noch effizienter machen:\n1. Finde heraus, ob es einen Index gibt, indem du dir die Fußzeile der Tabelle ansiehst.\n\t- Wenn es einen gibt, führe eine Binärsuche über den Index durch, um den gewünschten Block zu finden. Dieser Block kann selbst auf einen Indexblock verweisen. In diesem Fall müssen wir diesen Schritt wiederholen, bis wir einen Datensatz des gewünschten Typs finden.\n\t- Ansonsten führe eine Binärsuche über die Blöcke durch, wie wir es zuvor getan haben.\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts durch.\n\n## Mehrere Tabellen\n\nBis jetzt haben wir nur besprochen, wie man eine _einzelne_ Tabelle liest. Aber wie der Name `tables.list` schon sagt, kannst du tatsächlich eine Liste von Tabellen in deiner „reftable“-Datenbank haben.\n\nJedes Mal, wenn du eine Referenz in deinem Repository aktualisierst, wird eine neue Tabelle geschrieben und an `tables.list` angehängt. So hast du schließlich mehrere Tabellen:\n\n```Shell\n$ tree .git/reftable/\n.git/reftable/\n├──0x0000000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\n\nUm den tatsächlichen Status eines Repositorys zu lesen, müssen wir diese mehreren Tabellen zu einer einzigen virtuellen Tabelle zusammenführen.\n\nDu fragst dich vielleicht: Wenn für jede Referenzaktualisierung eine Tabelle geschrieben wird und dieselbe Referenz mehrmals aktualisiert wird, woher kennt das „reftable“-Format den aktuellsten Wert einer bestimmten Referenz? Intuitiv könnte man davon ausgehen, dass der Wert derjenige aus der neuesten Tabelle ist, die die Referenz enthält.\n\nTatsächlich hat jeder einzelne Datensatz einen sogenannten Aktualisierungsindex, der die „Priorität“ eines Datensatzes kodiert. Wenn beispielsweise zwei Ref-Datensätze mit demselben Namen existieren, überschreibt derjenige mit dem höheren Aktualisierungsindex denjenigen mit dem niedrigeren Aktualisierungsindex.\n\nDiese Aktualisierungsindizes sind in der obigen Dateistruktur sichtbar. Die langen Hex-Zeichenfolgen (z. B. `0x000000000001`) sind die Aktualisierungsindizes, wobei die linke Seite des Tabellennamens der minimale Aktualisierungsindex ist, der in der Tabelle enthalten ist, und die rechte Seite der maximale Aktualisierungsindex ist.\n\nDas Zusammenführen der Tabellen erfolgt dann über eine [Vorrangwarteschlange](https://de.wikipedia.org/wiki/Vorrangwarteschlange), die nach dem Schlüssel des Ref-Datensatzes sowie dem Aktualisierungsindex geordnet ist. Angenommen, wir möchten alle Ref-Datensätze durchsuchen, würden wir wie folgt vorgehen:\n\n1. Füge für jede Tabelle ihren ersten Datensatz zur Vorrangwarteschlange hinzu.\n\n![Ersten Datensatz zur Vorrangwarteschlange hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Liefere den Kopf der Vorrangwarteschlange. Da die Warteschlange nach Aktualisierungsindex geordnet ist, muss sie die aktuellste Version sein. Füge das nächste Element aus dessen Tabelle zur Vorrangwarteschlange hinzu.\n\n![Head der Vorrangwarteschlange angeben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Ziehe alle Datensätze aus der Warteschlange, die den gleichen Namen haben. Diese Datensätze werden verschattet, was bedeutet, dass sie nicht angezeigt werden. Füge für jede Tabelle, für die wir Datensätze ablegen, den nächsten Datensatz zur Vorrangwarteschlange hinzu.\n\n![Alle Datensätze aus der Warteschlange ablegen, die den gleichen Namen haben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\nJetzt können wir bereinigen und den Vorgang wiederholen, um Datensätze für andere Schlüssel zu lesen.\n\nTabellen können spezielle „tombstone“-Datensätze enthalten, die einen Datensatz als gelöscht markieren. So können wir Datensätze löschen, ohne den jeweiligen Datensatz aus allen Tabellen löschen zu müssen.\n\n### Autokomprimierung\n\nWährend die Idee hinter der Vorrangwarteschlange zwar einfach ist, wäre es allerdings eher ineffizient, Hunderte oder sogar nur Dutzende von Tabellen auf diese Weise zusammenzuführen. Es stimmt, dass jede Aktualisierung an deinen Referenzen eine neue Tabelle an deine `tables.list`-Datei anhängt. Das ist jedoch nur ein Teil der Wahrheit.\n\nDer andere Teil ist die Autokomprimierung: Nachdem eine neue Tabelle an die Liste der Tabellen angehängt wurde, überprüft das „reftable“-Backend, ob manche der Tabellen zusammengeführt werden sollen. Dies erfolgt durch eine einfache Heuristik. Wir überprüfen, ob die Liste der Tabellen eine [geometrische Folge](https://de.wikipedia.org/wiki/Geometrische_Folge) der Dateigrößen bildet. Jede Tabelle `n` muss mindestens doppelt so groß sein wie die nächstletzte Tabelle `n + 1`. Wenn gegen diese geometrische Folge verstoßen wird, komprimiert das Backend die Tabellen, sodass die geometrische Folge wiederhergestellt wird.\n\nIm Laufe der Zeit führt dies zu Strukturen, die wie folgt aussehen:\n\n```Shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nBeachte, wie für jede einzelne Tabelle die Eigenschaft `size(n) > size(n+1) * 2` gilt.\n\nEine der Folgen der Autokomprimierung ist, dass sich das „reftable“-Backend selbst erhält. Wir müssen somit nicht mehr den Befehl `git pack-refs` zum Optimieren der Referenzen ausführen.\n\n## Möchtest du mehr erfahren?\n\nDu solltest jetzt ein gutes Verständnis dafür haben, wie das neue „reftable“-Format im Detail funktioniert. Wenn du noch tiefer in das Format eintauchen möchtest, kannst du dir dessen [technische Dokumentation](https://git-scm.com/docs/reftable) des Git-Projekts ansehen.\n\n> Lies dir unsere [Zusammenfassung von Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) durch, um herauszufinden, was sonst noch in dieser Version von Git auf dich wartet.",[682,705,9,843],{"slug":1088,"featured":91,"template":686},"a-beginners-guide-to-the-git-reftable-format","content:de-de:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","de-de/blog/a-beginners-guide-to-the-git-reftable-format.yml","de-de/blog/a-beginners-guide-to-the-git-reftable-format",3,[666,691,712,736,758,781,801,826,851],1758326309709]