[{"data":1,"prerenderedAt":1030},["ShallowReactive",2],{"/de-de/blog/categories/open-source/":3,"navigation-de-de":21,"banner-de-de":442,"footer-de-de":454,"open-source-category-page-de-de":664},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":9,"_source":17,"_file":18,"_stem":19,"_extension":20},"/de-de/blog/categories/open-source","categories",false,"",{"title":9,"description":10},"Open Source","Browse articles related to Open Source on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","open-source","content:de-de:blog:categories:open-source.yml","yaml","content","de-de/blog/categories/open-source.yml","de-de/blog/categories/open-source","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":438,"_type":16,"title":439,"_source":17,"_file":440,"_stem":441,"_extension":20},"/shared/de-de/main-navigation","de-de",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":379,"minimal":415,"duo":429},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/de-de/","gitlab logo","header",{"text":31,"config":32},"Kostenlose Testversion anfordern",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Vertrieb kontaktieren",{"href":38,"dataGaName":39,"dataGaLocation":29},"/de-de/sales/","sales",{"text":41,"config":42},"Anmelden",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,189,194,300,360],{"text":47,"config":48,"cards":50,"footer":73},"Plattform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":54,"config":55},"Erkunde unsere Plattform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/de-de/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":61,"config":62},"Lerne GitLab Duo kennen",{"href":63,"dataGaName":64,"dataGaLocation":29},"/de-de/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":69,"config":70},"Mehr erfahren",{"href":71,"dataGaName":72,"dataGaLocation":29},"/de-de/why-gitlab/","why gitlab",{"title":74,"items":75},"Erste Schritte mit",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/de-de/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Entwicklererfahrung",{"href":84,"dataGaName":85,"dataGaLocation":29},"/de-de/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":171},"Produkt",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":29},"/de-de/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":114,"config":115},"KI-unterstützte Entwicklung",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":29,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":29,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":29,"icon":133},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Sicherheit und Compliance",{"href":131,"dataGaLocation":29,"dataGaName":138},"Security & Compliance",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":29,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Compliance und Governance",{"href":147,"dataGaLocation":29,"dataGaName":148},"/de-de/solutions/continuous-software-compliance/","Compliance and governance",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":29},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":29,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":29,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":29,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":29,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":29,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":29,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":29,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":287},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":29},"/de-de/resources/",[203,236,259],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":29},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":29},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":29,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":29},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":29},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249,254],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":29},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":29},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":255,"config":256},"TeamOps",{"href":257,"dataGaName":258,"dataGaLocation":29},"/de-de/teamops/","teamops",{"title":260,"items":261},"Vernetzen",[262,267,272,277,282],{"text":263,"config":264},"GitLab-Services",{"href":265,"dataGaName":266,"dataGaLocation":29},"/de-de/services/","services",{"text":268,"config":269},"Community",{"href":270,"dataGaName":271,"dataGaLocation":29},"/community/","community",{"text":273,"config":274},"Forum",{"href":275,"dataGaName":276,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":278,"config":279},"Veranstaltungen",{"href":280,"dataGaName":281,"dataGaLocation":29},"/events/","events",{"text":283,"config":284},"Partner",{"href":285,"dataGaName":286,"dataGaLocation":29},"/de-de/partners/","partners",{"backgroundColor":288,"textColor":289,"text":290,"image":291,"link":295},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":292,"config":293},"the source promo card",{"src":294},"/images/navigation/the-source-promo-card.svg",{"text":296,"config":297},"Lies die News",{"href":298,"dataGaName":299,"dataGaLocation":29},"/de-de/the-source/","the source",{"text":301,"config":302,"lists":304},"Unternehmen",{"dataNavLevelOne":303},"company",[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"Über",{"href":310,"dataGaName":311,"dataGaLocation":29},"/de-de/company/","about",{"text":313,"config":314,"footerGa":317},"Karriere",{"href":315,"dataGaName":316,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":316},{"text":278,"config":319},{"href":280,"dataGaName":281,"dataGaLocation":29},{"text":321,"config":322},"Geschäftsführung",{"href":323,"dataGaName":324,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":326,"config":327},"Team",{"href":328,"dataGaName":329,"dataGaLocation":29},"/company/team/","team",{"text":331,"config":332},"Handbuch",{"href":333,"dataGaName":334,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"Investor Relations",{"href":338,"dataGaName":339,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"Trust Center",{"href":343,"dataGaName":344,"dataGaLocation":29},"/de-de/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":29},"/de-de/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"Newsletter",{"href":353,"dataGaName":354,"dataGaLocation":29},"/company/contact/","newsletter",{"text":356,"config":357},"Presse",{"href":358,"dataGaName":359,"dataGaLocation":29},"/press/","press",{"text":361,"config":362,"lists":363},"Kontakt",{"dataNavLevelOne":303},[364],{"items":365},[366,369,374],{"text":36,"config":367},{"href":38,"dataGaName":368,"dataGaLocation":29},"talk to sales",{"text":370,"config":371},"Support",{"href":372,"dataGaName":373,"dataGaLocation":29},"/support/","get help",{"text":375,"config":376},"Kundenportal",{"href":377,"dataGaName":378,"dataGaLocation":29},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"Schließen",{"text":382,"link":383},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":384,"config":385},"gitlab.com",{"href":43,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"Vorschläge",[391,394,399,401,406,411],{"text":58,"config":392},{"href":63,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"Code Suggestions (KI)",{"href":397,"dataGaName":398,"dataGaLocation":387},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":400},{"href":112,"dataGaName":110,"dataGaLocation":387},{"text":402,"config":403},"GitLab auf AWS",{"href":404,"dataGaName":405,"dataGaLocation":387},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":407,"config":408},"GitLab auf Google Cloud",{"href":409,"dataGaName":410,"dataGaLocation":387},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":412,"config":413},"Warum GitLab?",{"href":71,"dataGaName":414,"dataGaLocation":387},"Why GitLab?",{"freeTrial":416,"mobileIcon":421,"desktopIcon":426},{"text":417,"config":418},"Kostenlos testen",{"href":419,"dataGaName":34,"dataGaLocation":420},"https://gitlab.com/-/trials/new/","nav",{"altText":422,"config":423},"GitLab-Symbol",{"src":424,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":422,"config":427},{"src":428,"dataGaName":425,"dataGaLocation":420},"/images/brand/gitlab-logo-type.svg",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"Erfahre mehr über GitLab Duo",{"href":63,"dataGaName":433,"dataGaLocation":420},"gitlab duo",{"altText":422,"config":435},{"src":424,"dataGaName":425,"dataGaLocation":420},{"altText":422,"config":437},{"src":428,"dataGaName":425,"dataGaLocation":420},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":443,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"title":444,"button":445,"config":449,"_id":451,"_type":16,"_source":17,"_file":452,"_stem":453,"_extension":20},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":69,"config":446},{"href":447,"dataGaName":448,"dataGaLocation":29},"/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":23,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":660,"_type":16,"title":661,"_source":17,"_file":662,"_stem":663,"_extension":20},"/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":47,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":56,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":190,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":192,"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":136,"config":512},{"href":131,"dataGaName":513,"dataGaLocation":463},"security & compliance",{"text":123,"config":515},{"href":106,"dataGaName":107,"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":120,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":110,"config":531},{"href":112,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":162,"config":534},{"href":164,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":175,"config":542},{"href":177,"dataGaName":178,"dataGaLocation":463},{"text":180,"config":544},{"href":182,"dataGaName":183,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"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":195,"links":559},[560,562,564,566,569,571,574,576,578,580,582,584,586],{"text":207,"config":561},{"href":209,"dataGaName":210,"dataGaLocation":463},{"text":212,"config":563},{"href":214,"dataGaName":215,"dataGaLocation":463},{"text":217,"config":565},{"href":219,"dataGaName":220,"dataGaLocation":463},{"text":222,"config":567},{"href":224,"dataGaName":568,"dataGaLocation":463},"docs",{"text":245,"config":570},{"href":247,"dataGaName":248,"dataGaLocation":463},{"text":240,"config":572},{"href":573,"dataGaName":243,"dataGaLocation":463},"/customers/",{"text":250,"config":575},{"href":252,"dataGaName":253,"dataGaLocation":463},{"text":263,"config":577},{"href":265,"dataGaName":266,"dataGaLocation":463},{"text":255,"config":579},{"href":257,"dataGaName":258,"dataGaLocation":463},{"text":268,"config":581},{"href":270,"dataGaName":271,"dataGaLocation":463},{"text":273,"config":583},{"href":275,"dataGaName":276,"dataGaLocation":463},{"text":278,"config":585},{"href":280,"dataGaName":281,"dataGaLocation":463},{"text":283,"config":587},{"href":285,"dataGaName":286,"dataGaLocation":463},{"title":301,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":308,"config":591},{"href":310,"dataGaName":303,"dataGaLocation":463},{"text":313,"config":593},{"href":315,"dataGaName":316,"dataGaLocation":463},{"text":321,"config":595},{"href":323,"dataGaName":324,"dataGaLocation":463},{"text":326,"config":597},{"href":328,"dataGaName":329,"dataGaLocation":463},{"text":331,"config":599},{"href":333,"dataGaName":334,"dataGaLocation":463},{"text":336,"config":601},{"href":338,"dataGaName":339,"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":341,"config":612},{"href":343,"dataGaName":344,"dataGaLocation":463},{"text":351,"config":614},{"href":353,"dataGaName":354,"dataGaLocation":463},{"text":356,"config":616},{"href":358,"dataGaName":359,"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":38,"dataGaName":39,"dataGaLocation":463},{"text":370,"config":629},{"href":372,"dataGaName":373,"dataGaLocation":463},{"text":375,"config":631},{"href":377,"dataGaName":378,"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":92},"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":92},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":665,"allPosts":691,"totalPages":1028,"initialPosts":1029},{"_path":666,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":671,"config":684,"_id":687,"_type":16,"title":688,"_source":17,"_file":689,"_stem":690,"_extension":20},"/de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":668,"description":669,"ogTitle":668,"ogDescription":669,"config":670},"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":672,"body":673,"authors":674,"updatedDate":677,"date":678,"title":679,"tags":680,"description":683,"category":14},"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.\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/),\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\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\nund übertrafen damit erstmals unser Teamziel von 170.\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\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## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\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\nDie Teilnehmenden sagten uns:\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n* Der Einstieg fühlte sich überwältigend an\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\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\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\n„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'\"\n\n## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\nUnsere Lösung begann mit Engagement.\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\nMitwirkenden mit einem Community-Maintainer verbindet.\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\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\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![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\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## Wir standardisierten Antworten mit Kommentar-Templates\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\ndie wir mit dem Repository über die GraphQL-API und ein\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n```yaml\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![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\nUnsere erste Iteration war etwas langsam.\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.\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\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\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\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```json\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![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n## Wir automatisierten Nachfassaktionen\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n## Wir organisierten die Issue-Verfolgung mit GLQL\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\nEs war so erfolgreich, dass wir diese Strategie auch bei den Programmen [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n## Wir machten die README auffindbar\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\nist das Zuhause für Mitwirkende auf GitLab.com.\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\nbefand sich in unserem Meta-Projekt.\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\nOnboarding-Issues unter einem anderen Projekt waren.\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n## Die Ergebnisse sprechen für sich selbst\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\nund transformierten die GitLab-Mitwirkenden-Journey.\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\num unsere Antwortzeiten zu verfolgen.\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\nErfolge und Belohnungen bietet.\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n## Was wir gelernt haben teilen\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\nWir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.\n\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n## Das Gespräch beginnen\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\nSende eine E-Mail an `contributors@gitlab.com` oder [öffne ein Issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues),\num eine Diskussion zu beginnen.\nWir sind hier, um beim Aufbau von Communities zu helfen.",[675,676],"Lee Tickett","Daniel Murphy","2025-07-23","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[681,271,682],"open source","product","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":685,"slug":686},"BlogPost","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",[692,712,735,755,775,795,815,838,859,882,906,925,947,970,989,1009],{"_path":693,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":697,"config":706,"_id":708,"_type":16,"title":709,"_source":17,"_file":710,"_stem":711,"_extension":20},"/de-de/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":695,"description":696},"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":698,"description":696,"authors":699,"heroImage":701,"body":702,"date":703,"category":14,"tags":704},"Was gibt es Neues in Git 2.50.0?",[700],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Das Git-Projekt hat kürzlich [Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf die Highlights dieser Veröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Neuer Befehl git-diff-pairs(1)\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\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n```shell\n$ git diff HEAD~1 HEAD\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\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\nEine Möglichkeit dafür ist die Verwendung von\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\nüber alle geänderten Dateien abzurufen:\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\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).\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\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\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\ndirekt angeben:\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\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\nseparaten Git-Prozess zu starten.\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\ndie entsprechende Patch-Ausgabe zu generieren.\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\nakzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl\nverwendet werden kann:\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n## Gesammelte Referenz-Updates\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\nangegeben werden, die auf stdin durchgeführt werden soll.\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n```shell\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n\n# Gib die Commit-IDs aus\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# Die Referenz „bar“ wurde nicht erstellt.\n$ git switch bar\nfatal: invalid reference: bar\n```\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\nMassenaktualisierungen nutzen möchten.\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\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```shell\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n$ git switch bar\nSwitched to branch 'bar'\n```\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n## Neue Filteroption für git-cat-file(1)\n\nMit [`git-cat-file(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-cat-file) ist es möglich,\nInformationen für alle im Repository enthaltenen Objekte über die Option\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n```shell\n# Richte ein einfaches Repository ein.\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n\n# Erstelle ein nicht erreichbares Objekt.\n$ git commit --amend --no-edit\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n`grep(1)` verwenden:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\nihrem Typ gefiltert werden:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\nnachschlagen und so das Durchsuchen der\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n```text\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\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\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\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\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\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\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\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n## Verbesserte Leistung beim Generieren von Bundles\n\nGit bietet die Möglichkeit, über den Befehl\n[`git-bundle(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-bundle) ein Archiv eines Repositories zu generieren, das einen\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n100 000 Referenzen enthält:\n\n```text\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\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\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nWeitere Informationen findest du in unserem Blogbeitrag\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/).\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\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*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n## Bessere Auflösung von URI-Bundles\n\nDurch den [Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus in Git können den Clients\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\nunter `refs/heads/*` zusammen mit\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\ndie Bundle-URI beim Klonen verwendet wird.\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\ndemonstriert den Unterschied beim Klonen von\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\nBeschleunigung um 25 %.\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n*TDiese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n## Weiterlesen\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.","2025-06-16",[705,681,271],"git",{"featured":92,"template":685,"slug":707},"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":713,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":722,"config":729,"_id":731,"_type":16,"title":732,"_source":17,"_file":733,"_stem":734,"_extension":20},"/de-de/blog/journey-through-gits-20-year-history",{"title":715,"description":716,"ogTitle":715,"ogDescription":716,"noIndex":6,"ogImage":717,"ogUrl":718,"ogSiteName":719,"ogType":720,"canonicalUrls":718,"schema":721},"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","https://about.gitlab.com","article","\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":715,"description":716,"authors":723,"heroImage":717,"date":725,"body":726,"category":14,"tags":727,"updatedDate":728},[724],"Patrick Steinhardt","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/)",[681,705],"2025-05-20",{"slug":730,"featured":92,"template":685},"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":736,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":743,"config":749,"_id":751,"_type":16,"title":752,"_source":17,"_file":753,"_stem":754,"_extension":20},"/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":738,"description":739,"ogTitle":738,"ogDescription":739,"noIndex":6,"ogImage":740,"ogUrl":741,"ogSiteName":719,"ogType":720,"canonicalUrls":741,"schema":742},"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","\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":738,"description":739,"authors":744,"heroImage":740,"date":745,"body":746,"category":14,"tags":747,"updatedDate":748},[724],"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/)",[681,705],"2025-04-28",{"slug":750,"featured":92,"template":685},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","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":756,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":757,"content":763,"config":769,"_id":771,"_type":16,"title":772,"_source":17,"_file":773,"_stem":774,"_extension":20},"/de-de/blog/what-is-open-source-software",{"title":758,"description":759,"ogTitle":758,"ogDescription":759,"noIndex":6,"ogImage":760,"ogUrl":761,"ogSiteName":719,"ogType":720,"canonicalUrls":761,"schema":762},"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":758,"description":759,"authors":764,"heroImage":760,"date":766,"body":767,"category":14,"tags":768},[765],"GitLab Germany Team","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 [30-Tage-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,681],{"slug":770,"featured":6,"template":685},"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":776,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":777,"content":782,"config":789,"_id":791,"_type":16,"title":792,"_source":17,"_file":793,"_stem":794,"_extension":20},"/de-de/blog/whats-new-in-git-2-49-0",{"title":778,"description":779,"ogTitle":778,"ogDescription":779,"noIndex":6,"ogImage":701,"ogUrl":780,"ogSiteName":719,"ogType":720,"canonicalUrls":780,"schema":781},"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":778,"description":779,"authors":783,"heroImage":701,"date":785,"body":786,"category":14,"tags":787,"updatedDate":788},[784],"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/)",[271,681,705],"2025-04-08",{"slug":790,"featured":92,"template":685},"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":796,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":797,"content":803,"config":809,"_id":811,"_type":16,"title":812,"_source":17,"_file":813,"_stem":814,"_extension":20},"/de-de/blog/what-is-docker",{"title":798,"description":799,"ogTitle":798,"ogDescription":799,"noIndex":6,"ogImage":800,"ogUrl":801,"ogSiteName":719,"ogType":720,"canonicalUrls":801,"schema":802},"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":798,"description":799,"authors":804,"heroImage":800,"date":805,"body":806,"category":14,"tags":807},[765],"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",[808,681],"DevOps",{"slug":810,"featured":6,"template":685},"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":816,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":817,"content":823,"config":832,"_id":834,"_type":16,"title":835,"_source":17,"_file":836,"_stem":837,"_extension":20},"/de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":818,"description":819,"ogTitle":818,"ogDescription":819,"noIndex":6,"ogImage":820,"ogUrl":821,"ogSiteName":719,"ogType":720,"canonicalUrls":821,"schema":822},"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":818,"description":819,"authors":824,"heroImage":820,"date":826,"body":827,"category":14,"tags":828,"updatedDate":831},[825],"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 60-Tage-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",[110,681,829,537,705,830],"kubernetes","tutorial","2025-05-12",{"slug":833,"featured":6,"template":685},"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":839,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":840,"content":846,"config":853,"_id":855,"_type":16,"title":856,"_source":17,"_file":857,"_stem":858,"_extension":20},"/de-de/blog/whats-new-in-git-2-48-0",{"title":841,"description":842,"ogTitle":841,"ogDescription":842,"noIndex":6,"ogImage":843,"ogUrl":844,"ogSiteName":719,"ogType":720,"canonicalUrls":844,"schema":845},"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://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-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":841,"description":842,"authors":847,"heroImage":843,"date":849,"body":850,"category":14,"tags":851,"updatedDate":852},[848],"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",[705,681,271],"2025-01-20",{"slug":854,"featured":92,"template":685},"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":860,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":861,"content":867,"config":876,"_id":878,"_type":16,"title":879,"_source":17,"_file":880,"_stem":881,"_extension":20},"/de-de/blog/how-gitlab-empowers-translators-with-more-context",{"title":862,"description":863,"ogTitle":862,"ogDescription":863,"noIndex":6,"ogImage":864,"ogUrl":865,"ogSiteName":719,"ogType":720,"canonicalUrls":865,"schema":866},"Wie GitLab Übersetzer(innen) den nötigen Kontext verschafft","Erfahre mehr über die neue Funktion zur Erweiterung des Übersetzungskontexts in GitLab. Werde Mitglied unserer Community aus Übersetzer(inne)n und hilf mit, GitLab in deine Sprache zu übersetzen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie GitLab Übersetzer(innen) den nötigen Kontext verschafft\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":862,"description":863,"authors":868,"heroImage":864,"date":870,"body":871,"category":14,"tags":872,"updatedDate":875},[869],"Oleksandr Pysaryuk","2024-12-09","GitLab wird ständig von unserer globalen Community von Übersetzer(inne)n und Korrekturleser(inne)n übersetzt. Über [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html) helfen sie dabei, unser Produkt für die Welt zugänglicher zu machen, indem sie es in 78 Sprachen übersetzen. Die Community-Mitglieder sind freiwillige Übersetzer(innen), Berufstätige, die GitLab nutzen, und sogar [Studierende, die im Rahmen ihrer Unterrichtsprojekte als Übersetzer(inne)n beitragen](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### So unterstützt das Open-Core-Modell von GitLab Übersetzer(innen)\n\nAuch wenn diese Zusammenarbeit in der Community sehr effektiv ist, stehen Übersetzer(innen) oft vor einer entscheidenden Herausforderung: Sie müssen den gesamten Kontext des Textes, den sie übersetzen, verstehen.\n\nBei einer guten Übersetzung geht es nicht nur darum, Wörter zu übersetzen, sondern auch darum, den Sinn, die Absicht und die Benutzerfreundlichkeit in der Zielsprache zu erhalten. Die Übersetzung von Software erfordert eine einzigartige Mischung von Fähigkeiten. Gute Übersetzer(innen) sind in der Regel auf mehrere Sprachgebiete sowie auf das technische Fachgebiet des Produkts selbst spezialisiert. Sie führen unzählige Aufgaben aus, die mit der Übersetzung zusammenhängen, wie zum Beispiel:\n\n* Sicherstellen der Genauigkeit und Konsistenz der Fachbegriffe  \n* Erstellen neuer Glossarbegriffe für neue Konzepte  \n* Einhalten des Stils und des Tonfalls  \n* Beherrschen der Komplexität von [CLDR-Pluralisierungsregeln](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)  \n* Aufbauen eines Verständnisses für die Übersetzbarkeit zusammengesetzter Nachrichten und die Bereitstellung von Feedback zur Verbesserung des Quelltextes durch Lokalisierung\n\nÜbersetzer(innen) verbringen viel Zeit mit der Recherche von Zusammenhängen, dem Stellen von Fragen und dem Lesen der [GitLab-Produktdokumentation](https://docs.gitlab.com/). Ohne den richtigen Kontext werden selbst einfache Sätze falsch übersetzt, was Benutzer(innen) verwirren oder ihre Arbeitsabläufe stören kann. Was [GitLab von anderen unterscheidet, ist sein Open-Core-Modell](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/), das den Übersetzer(inne)n den Zugang zum größten Teil des Produktentwicklungskontextes direkt an der Quelle ermöglicht. Diese Transparenz ermöglicht es ihnen, einen [aktiven Beitrag zum globalen GitLab-Produkt zu leisten](https://handbook.gitlab.com/handbook/company/mission/#mission).\n\n### Unsere neue Funktion zur Kontextverbesserung\n\nUm diese Anforderungen zu erfüllen und den Übersetzer(inne)n mehr Kontext zu bieten, hat GitLab eine neue Funktion entwickelt: Wir betten jetzt in jeden übersetzbaren String einen [kontextbezogenen Link](https://docs.gitlab.com/ee/development/i18n/translation.html#context) ein (genauer gesagt einen Link zu unserer globalen produktinternen Suche), mit dem die Übersetzer(innen) alle Instanzen dieses Strings in der Codebase finden können. Mit diesen Links können die Übersetzer(innen) sich auf [Git Blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) verlassen, um den Verlauf jedes Strings nachzuverfolgen – vom aktuellen Ort im Code über Commits in Merge Requests bis hin zu den ursprünglichen Planungsgesprächen.\n\nWenn du zum Beispiel **Rotate** übersetzt, deutet der [Namensraum](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) **AccessTokens|** darauf hin, dass der Kontext *Zugriffstoken* ist. Es gibt jedoch keinen zusätzlichen visuellen Kontext für die Bedeutung von **Rotate**, und die Übersetzer(innen) müssen raten und die bestmögliche Vermutung für die Zielsprache anstellen.\n\nMit der neuen Kontextverbesserung kannst du als Übersetzer(in) jetzt Folgendes tun:\n\n1. Klicke auf die URL im Abschnitt **See where this string is used in code** (Sieh dir an, wo im Code der String verwendet wird).\n\n![Abschnitt „Sieh dir an, wo im Code der String verwendet wird“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Sieh dir das [Ergebnis der Codesuche an](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true) und klicke auf das Symbol **View blame** (Blame anzeigen):\n\n![Bildschirm mit dem Symbol „View blame“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Folge dem Link zum entsprechenden Merge Request ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954); Einführung der Rotation persönlicher Token in UI):\n\n![Link mit relevantem Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. Folge auf der Seite **Commits** dem Link zum eigentlichen Merge Request:\n\n![Commits-Seite mit Link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Sieh dir die Bildschirmaufnahme an, die der Softwareentwickler dem Merge Request hinzugefügt hat:\n\n![Bildschirmaufnahme im Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Tauche noch tiefer ein:  \n   a. Gehe zum verknüpften Ticket [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) (Erneuerungsfunktion für abgelaufene Token in der UI einführen) oder zum übergeordneten Epic [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563) (Token über die UI rotieren):\n\n![Verknüpftes Ticket und übergeordnetes Epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. Gehe zum [zugehörigen Merge Request, der die GitLab-Produktdokumentation aktualisiert](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916):\n\n![Zugehöriger Merge Request zur Aktualisierung der GitLab-Produktdokumentation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nAll diese Rechercheschritte führen dazu, dass die Übersetzer(innen) das technische Konzept der *Rotation von Zugriffstoken* besser verstehen und wissen, warum die Funktion der Rotation von Token hinzugefügt wurde, wie sie funktioniert und welches Problem sie für die Nutzer löst.\n\nMit diesem umfangreichen Recherchepfad erhalten die Übersetzer(innen) ein Höchstmaß an Kontext, der ihnen hilft, das scheinbar einfache Wort **Rotate** technisch und sprachlich korrekt zu übersetzen.\n\nDieser Ansatz geht weit über herkömmliche Übersetzungshilfen wie das Bereitstellen von Screenshots oder die Erkundung der Benutzeroberfläche eines Produkts hinaus. Übersetzer(innen) können jetzt den Kontext vollständig verstehen.\n\n* Sie können den Kontext aus Pfaden und Benennungskonventionen ableiten, die im Code verwendet werden.  \n* Sie können Screenshots oder Videoaufnahmen anzeigen, die zu ursprünglichen Merge Requests hinzugefügt wurden.  \n* Sie können sich die ersten Planungs- und Entwicklungsgespräche durchlesen.  \n* Sie können den Entscheidungsprozess in den Bereichen Engineering, Copywriting und Produktmanagement nachvollziehen, der zu einer bestimmten Formulierung geführt hat.\n\n### Weitere KI-gestützte Kontextfunktionen sind in Kürze verfügbar\n\nHier macht das Lokalisierungsteam von GitLab noch nicht halt. Wir arbeiten an [weiteren kontextbezogenen Funktionen](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), einschließlich KI-basierter Tools, die Übersetzer(inne)n helfen, die Verwendung und Platzierung von Strings zu verstehen. Stell dir vor, Übersetzer(innen) könnten mit einem Tool interagieren, das ihnen Fragen beantwortet oder proaktiv sofortige codebasierte Antworten darüber gibt, wo und wie Strings in der Produktoberfläche verwendet werden.\n\n> ### Tritt unserer [Community auf Crowdin](https://docs.gitlab.com/ee/development/i18n/) als Übersetzer(in) oder [Korrekturleser(in)](https://docs.gitlab.com/ee/development/i18n/#proofreading) bei, probiere diese neuen Kontextfunktionen aus und lass uns wissen, wie wir das [Übersetzungserlebnis und unser Produkt noch besser machen können](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[271,873,682,874],"collaboration","contributors","2025-02-10",{"slug":877,"featured":6,"template":685},"how-gitlab-empowers-translators-with-more-context","content:de-de:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","de-de/blog/how-gitlab-empowers-translators-with-more-context.yml","de-de/blog/how-gitlab-empowers-translators-with-more-context",{"_path":883,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":884,"content":890,"config":900,"_id":902,"_type":16,"title":903,"_source":17,"_file":904,"_stem":905,"_extension":20},"/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"ogTitle":885,"schema":886,"ogImage":887,"ogDescription":888,"ogSiteName":719,"noIndex":6,"ogType":720,"ogUrl":889,"title":885,"canonicalUrls":889,"description":888},"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":887,"body":891,"authors":892,"updatedDate":894,"date":895,"title":896,"tags":897,"description":899,"category":14},"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.",[893],"GitLab","2025-07-10","2024-11-14","Was ist Git? Der ultimative Leitfaden",[705,898,681],"DevSecOps","Möchtest du deine Projekte mit Git umsetzen? Entdecke alle Vorteile und Funktionen von Git in unserem umfassenden Guide.",{"slug":901,"featured":6,"template":685},"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":907,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":913,"config":919,"_id":921,"_type":16,"title":922,"_source":17,"_file":923,"_stem":924,"_extension":20},"/de-de/blog/whats-new-in-git-2-47-0",{"title":909,"description":910,"ogTitle":909,"ogDescription":910,"noIndex":6,"ogImage":843,"ogUrl":911,"ogSiteName":719,"ogType":720,"canonicalUrls":911,"schema":912},"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://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":909,"description":910,"authors":914,"heroImage":843,"date":915,"body":916,"category":14,"tags":917,"updatedDate":918},[700],"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/)",[705,681,271],"2024-11-05",{"slug":920,"featured":92,"template":685},"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":926,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":927,"content":933,"config":941,"_id":943,"_type":16,"title":944,"_source":17,"_file":945,"_stem":946,"_extension":20},"/de-de/blog/what-is-gitflow",{"ogTitle":928,"schema":929,"ogImage":930,"ogDescription":931,"ogSiteName":719,"noIndex":6,"ogType":720,"ogUrl":932,"title":928,"canonicalUrls":932,"description":931},"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":930,"body":934,"authors":935,"updatedDate":937,"date":938,"title":928,"tags":939,"description":940,"category":14},"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",[936],"GitLab Team","2025-05-29","2024-09-27",[705,681],"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":942,"featured":6,"template":685},"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":948,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":949,"content":956,"config":964,"_id":966,"_type":16,"title":967,"_source":17,"_file":968,"_stem":969,"_extension":20},"/de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"ogTitle":950,"schema":951,"ogImage":952,"ogDescription":953,"ogSiteName":954,"noIndex":6,"ogType":720,"ogUrl":955,"title":950,"canonicalUrls":955,"description":953},"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":952,"body":957,"authors":958,"updatedDate":959,"date":960,"title":961,"tags":962,"description":963,"category":14},"Der Git-Befehl ist als [verteiltes Versionskontrollsystem](https://about.gitlab.com/de-de/topics/version-control/benefits-distributed-version-control-system/) sehr beliebt und wird verwendet, wenn eine Synchronisation mit einem Remote-Repository erforderlich ist. \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**In diesem Artikel lernst du:**\n\n* Wann du `git pull` vs. `git fetch` verwendest\n* Wie du Konflikte vermeidest (und löst, wenn sie auftreten)  \n* Welche Fallstricke es gibt und wie du sie umgehst\n\n## Inhaltsverzeichnis - git fetch vs. git pull: Das ist der Unterschied!\n\n* [Worum geht es bei git pull?](#worum-geht-es-bei-git-pull)\n* [Was ist git fetch?](#was-ist-git-fetch)\n* [git pull - Daten aktualisieren](#git-pull---daten-aktualisieren)\n* [git pull - Mehr als nur ein Befehl](#git-pull---mehr-als-nur-ein-befehl)\n* [git pull vs git fetch - Wann benutze ich welchen Befehl?](#git-pull-vs-git-fetch---wann-benutze-ich-welchen-befehl)\n* [git pull - Die Basis für kollaboratives Arbeiten](#git-pull---die-basis-für-kollaboratives-arbeiten)\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\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\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\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\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## Was ist git fetch?\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## git pull - Daten aktualisieren\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\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\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. \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„Den Pull-Befehl benötigen Sie im täglichen git-Workflow, um das lokale Repository mit den neuesten Änderungen zu aktualisieren.”\n\n## git pull - Mehr als nur ein Befehl\n\ngit pull ist mehr als nur ein Befehl. Und diese Aussage kannst du wörtlich nehmen. \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\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\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\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## git pull vs git fetch - Wann benutze ich welchen Befehl?\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\ngit pull ist die schnellste Methode, dieses Ziel umzusetzen. Hier ein praktisches Beispiel:\n\n```bash\n# Aktuelle Änderungen vom main-Branch holen und direkt anwenden\ngit pull origin main\n\n# Was im Hintergrund passiert:\ngit fetch origin main  # Änderungen herunterladen\ngit merge origin/main  # Änderungen in deinen Branch einarbeiten\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\nZwar ist eine Fehlerkontrolle auch mit git pull noch möglich, doch jegliche Korrekturen inhaltlicher Natur können von dir nicht mehr hinterfragt werden.\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## git pull - Die Basis für kollaboratives Arbeiten\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\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\nAlleine schon deswegen verdient der Command seine Einschätzung als einer der wichtigsten Befehle in git überhaupt. \n\n## git fetch und git pull FAQs\n\n### Wie oft sollte ich den Pull-Befehl ausführen?\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\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\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### Was ist mit Autofetch oder Autopull?\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\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. \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### Was passiert bei Problemen mit git pull?\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\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### Ist git pull riskant?\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\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\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\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## Mehr erfahren\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* [Git lernen](https://docs.gitlab.com/ee/topics/git/)\n* [Mehr über GitLab Gitaly erfahren](https://docs.gitlab.com/ee/administration/gitaly/)",[893],"2025-07-28","2024-09-24","git pull vs. git fetch: Die Unterschiede erklärt",[705,681],"Ein Befehl, zwei Aktionen: Was git pull wirklich macht und wann git fetch die bessere Wahl ist.",{"slug":965,"featured":6,"template":685},"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":971,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":972,"content":977,"config":983,"_id":985,"_type":16,"title":986,"_source":17,"_file":987,"_stem":988,"_extension":20},"/de-de/blog/whats-new-in-git-2-46-0",{"title":973,"description":974,"ogTitle":973,"ogDescription":974,"noIndex":6,"ogImage":952,"ogUrl":975,"ogSiteName":719,"ogType":720,"canonicalUrls":975,"schema":976},"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":973,"description":974,"authors":978,"heroImage":952,"date":979,"body":980,"category":14,"tags":981,"updatedDate":982},[700],"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.",[705,681,271],"2024-08-14",{"slug":984,"featured":92,"template":685},"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":990,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":991,"content":997,"config":1003,"_id":1005,"_type":16,"title":1006,"_source":17,"_file":1007,"_stem":1008,"_extension":20},"/de-de/blog/a-beginners-guide-to-the-git-reftable-format",{"title":992,"description":993,"ogTitle":992,"ogDescription":993,"noIndex":6,"ogImage":994,"ogUrl":995,"ogSiteName":719,"ogType":720,"canonicalUrls":995,"schema":996},"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":992,"description":993,"authors":998,"heroImage":994,"date":999,"body":1000,"category":14,"tags":1001,"updatedDate":979},[724],"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.",[705,830,681,1002],"performance",{"slug":1004,"featured":92,"template":685},"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",{"_path":1010,"_dir":248,"_draft":6,"_partial":6,"_locale":7,"seo":1011,"content":1017,"config":1022,"_id":1024,"_type":16,"title":1025,"_source":17,"_file":1026,"_stem":1027,"_extension":20},"/de-de/blog/whats-new-in-git-2-45-0",{"title":1012,"description":1013,"ogTitle":1012,"ogDescription":1013,"noIndex":6,"ogImage":1014,"ogUrl":1015,"ogSiteName":719,"ogType":720,"canonicalUrls":1015,"schema":1016},"Was ist neu in Git 2.45.0?","Hier sind einige Highlights der Beiträge des Git-Teams von GitLab und der breiteren Git-Community zur neuesten Git-Version, darunter reftables und bessere Tools für Referenzen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist neu in Git 2.45.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":1012,"description":1013,"authors":1018,"heroImage":1014,"date":1019,"body":1020,"category":14,"tags":1021},[724],"2024-04-30","Das Git-Projekt hat kürzlich [Git-Version 2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Git Version 2.45.0\") 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\n## Reftables: Ein neues Backend zum Speichern von Referenzen\n\nJedes Git-Repository muss zwei grundlegende Datenstrukturen erfassen:\n\n- Den Objektgraphen, der die Daten deiner Dateien, die Verzeichnisstruktur, Commit-Nachrichten und Tags speichert.\n- Referenzen, die auf diesen Objektgraphen verweisen, um bestimmte Objekte mit einem leichter verständlichen Namen zu verknüpfen. Ein Branch ist zum Beispiel eine Referenz, deren Name mit dem Präfix `refs/heads/` beginnt.\n\nDas Format, in dem Referenzen in einem Repository auf der Festplatte gespeichert werden, ist seit der Einführung von Git weitgehend unverändert geblieben und wird als „files“-Format bezeichnet. Jedes Mal, wenn du eine Referenz erstellst, legt Git eine sogenannte „lose Referenz“ an. Das ist eine einfache Datei in deinem Git-Repository, deren Pfad mit dem Namen der Referenz übereinstimmt. Zum Beispiel:\n\n```shell\n$ git init .\nInitialized empty Git repository in /tmp/repo/.git/\n\n# Das Updaten einer Referenz veranlasst Git dazu, eine “lose Referenz”\n# zu erstellen. Diese lose Referenz ist eine einfache Datei, welche die\n# Objekt-ID des Commits enthält.\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) c70f266] Initial commit\n$ cat .git/refs/heads/main\nc70f26689975782739ef9666af079535b12b5946\n\n# Wenn man eine zweite Referenz erstellt, wird diese als zweite lose\n# Referenz gespeichert.\n$ git branch feature\n$ cat .git/refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946\n$ tree .git/refs\n.git/refs/\n├── heads\n│   ├── feature\n│   └── main\n└── tags\n\n3 directories, 2 files\n```\nVon Zeit zu Zeit packt Git diese Referenzen in ein „gepacktes“ Dateiformat, damit es effizienter wird, Referenzen nachzuschlagen. Zum Beispiel:\n\n```shell\n# Wenn man Referenzen packt, erstellt Git eine “packed-refs” Datei.\n# Diese Datei enthält die sortierte Liste von vorher losen Referenzen.\n# Die losen Referenzen existieren nicht mehr.\n$ git pack-refs --all\n$ cat .git/refs/heads/main\ncat: .git/refs/heads/main: No such file or directory\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n```\nDieses Format ist zwar ziemlich simpel, hat aber Einschränkungen:\n\n- In großen Mono-Repos mit vielen Referenzen stießen wir auf Probleme mit der Skalierbarkeit. Das Löschen von Referenzen ist besonders ineffizient, da die gesamte „packed-refs“-Datei neu geschrieben werden muss, um die gelöschte Referenz zu entfernen. In unseren größten Repositorys kann dies dazu führen, dass bei jedem Löschen einer Referenz mehrere Gigabyte an Daten neu geschrieben werden müssen.\n- Da mehrere Dateien gelesen werden müssen, um alle Referenzen des Repos zu ermitteln, ist dies atomar nicht möglich. Sobald andere Prozesse existieren, die in das Repo schreiben wollen, kann es dadurch zu Inkonsistenzen kommen.\n- Es ist unmöglich, atomar mehrere Referenzen gleichzeitig zu schreiben, weil dafür mehrere Dateien erstellt oder aktualisiert werden müssen.\n- Das Packen von Referenzen lässt sich nicht gut skalieren, weil die gesamte „packed-refs“-Datei neu geschrieben werden muss.\n- Da lose Referenzen den Dateisystempfad als Namen verwenden, unterliegen sie dem dateisystemspezifischen Verhalten. So können z. B. Dateisysteme, die Groß- und Kleinschreibung nicht unterscheiden, keine Referenzen speichern, bei denen nur die Groß- und Kleinschreibung unterschiedlich ist.\n\nUm diese Probleme zu lösen, wurde mit Git v2.45.0 ein neues „reftable“-Backend eingeführt, das ein neues Binärformat zum Speichern von Referenzen verwendet. Dieses neue Backend wird schon sehr lange entwickelt: es wurde ursprünglich von [Shawn Pearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/ \"Shawn Pearce\") im Juli 2017 vorgeschlagen und zunächst in [JGit](https://www.eclipse.org/jgit/ \"JGit\") implementiert. Das [Gerrit-Projekt](https://www.gerritcodereview.com/ \"Gerrit Projekt\") nutzt es bereits ausgiebig. Im Jahr 2021 hat [Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/ \"Han-Wen Nienhuys\") die Bibliothek in Git hochgeladen, die es ermöglicht, das reftable-Format zu lesen und zu schreiben.\n\nDas neue „reftable“-Backend, das wir in Git v2.45.0 hochgeladen haben, bringt nun endlich die reftable-Bibliothek und Git zusammen, so dass du das neue Format als Speicher-Backend in deinen Git-Repositorys verwenden kannst.\n\nWenn du mindestens Git v2.45.0 verwendest, kannst du neue Repositorys mit dem „reftable“-Format erstellen, indem du den Schalter `--ref-format=reftable` entweder an `git-init(1)` oder an `git-clone(1)` übergibst. Zum Beispiel:\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/tables.list\n\n$ git commit --allow-empty --message \"Initial commit\"\n$ find -type f .git/reftable/\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n.git/reftable/tables.list\n```\nWie du siehst, werden die Referenzen jetzt im Verzeichnis `.git/reftable` statt in `.git/refs` gespeichert. Die Referenzen und die Reflogs werden in „tables“ gespeichert. Das sind die Dateien, die auf `.ref` enden. Die Datei `tables.list` enthält die Liste aller derzeit aktiven Tabellen. Die technischen Details rund um die Funktionsweise werden wir in einem separaten Blogbeitrag erklären. Bleib dran!\n\nDas „reftable“-Backend ist als vollwertiger Ersatz für das „files“-Backend gedacht. Aus der Sicht der Benutzer(innen) sollte also alles gleich funktionieren.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab \"Patrick Steinhardt\") geleitet. Dank gebührt auch Shawn Pearce, dem Erfinder des Formats, und Han-Wen Nienhuys, dem Autor der reftable-Bibliothek.\n\n## Bessere Tools für Referenzen \n\nDas Format „reftable“ löst zwar viele der Probleme, die wir haben, es bringt allerdings auch einige neue Probleme mit sich. Eines der wichtigsten Probleme ist die Zugänglichkeit der darin enthaltenen Daten.\n\nMit dem „files“-Backend kannst du im schlimmsten Fall deine normalen Unix-Tools verwenden, um den Zustand der Referenzen zu überprüfen. Sowohl die „gepackten“ als auch die „losen“ Referenzen enthalten menschenlesbare Daten, die man leicht verstehen kann. Das ist beim „reftable“-Format anders, da es sich um ein Binärformat handelt. Daher muss Git alle notwendigen Tools bereitstellen, um Daten aus dem neuen „reftable“-Format zu extrahieren.\n\n### Auflisten aller Referenzen\n\nDas erste Problem bestand darin, dass es im Grunde unmöglich ist, alle Referenzen zu ermitteln, die ein Repository kennt. Das ist zunächst etwas rätselhaft: Du kannst über Git Referenzen erstellen und ändern, aber es kann nicht alle Referenzen auflisten, die es kennt?\n\nWährend es problemlos alle „normalen“ Referenzen auflisten kann, die mit dem Präfix `refs/` beginnen, verwendet Git auch sogenannte Pseudo-Referenzen. Diese Dateien befinden sich direkt im Stammverzeichnis des Git-Verzeichnisses und wären zum Beispiel Dateien wie `.git/MERGE_HEAD`. Das Problem dabei ist, dass diese Pseudo-Referenzen neben anderen Dateien liegen, die Git speichert, wie z. B. `.git/config`.\n\nWährend einige Pseudo-Referenzen bekannt und daher leicht zu identifizieren sind, gibt es theoretisch keine Grenzen dafür, welche Referenzen Git schreiben kann. Nichts hält dich davon ab, eine Referenz mit dem Namen „foobar“ zu erstellen.\n\nZum Beispiel:\n\n```shell\n$ git update-ref foobar HEAD\n$ cat .git/foobar\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n```\nDas Problem des „files“-Backends ist, dass es Referenzen nur aufzählen kann, indem es Verzeichnisse durchsucht. Um herauszufinden, dass es sich bei `.git/foobar` tatsächlich um eine Referenz handelt, müsste Git die Datei öffnen und prüfen, ob sie wie eine Referenz formatiert ist oder nicht.\n\nDas „reftable“-Backend hingegen kennt sämtliche Referenzen, die es enthält: Sie sind in seinen Datenstrukturen kodiert, so dass es lediglich diese Referenzen dekodieren und zurückgeben muss. Aufgrund der Einschränkungen des „files“-Backends gibt es jedoch kein Tool, mit dem du alle vorhandenen Referenzen ermitteln kannst.\n\nUm dieses Problem zu lösen, haben wir `git-for-each-ref(1)` mit dem neuen Flag `--include-root-refs` ausgestattet, das auch alle Referenzen auflistet, die im Stammverzeichnis der Referenznamen-Hierarchie existieren. Zum Beispiel:\n\n```shell\n$ git for-each-ref --include-root-refs\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n```\nFür das „files“-Backend wird dieses neue Flag nach dem Best-Effort-Prinzip behandelt, d.h. es werden alle Referenzen aufgenommen, die mit einem bekannten Pseudo-Referenznamen übereinstimmen. Für das „reftable“-Backend können wir einfach alle bekannten Referenzen auflisten.\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl \"Karthik Nayak\") geleitet.\n\n### Auflisten aller reflogs\n\nJedes Mal, wenn du einen Branch aktualisierst, zeichnet Git diese Branch-Aktualisierung standardmäßig in einem sogenannten reflog auf. Dieses reflog ermöglicht es dir, Änderungen an diesem Branch rückgängig zu machen, falls du eine unbeabsichtigte Änderung vorgenommen hast, und kann daher sehr hilfreich sein.\n\nMit dem „files“-Backend werden diese Protokolle in deinem `.git/logs`-Verzeichnis gespeichert:\n\n```shell\n$ find -type f .git/logs/\n.git/logs/HEAD\n.git/logs/refs/heads/main\n```\nTatsächlich ist die Auflistung der Dateien in diesem Verzeichnis die einzige Möglichkeit, um herauszufinden, welche Referenzen überhaupt ein reflog haben. Dies ist ein Problem für das „reftable“-Backend, das diese Logs zusammen mit den Referenzen speichert. Folglich gibt es keine Möglichkeit mehr, herauszufinden, welche reflogs im Repository überhaupt existieren, wenn du das „reftable“ Format verwendest.\n\nDies ist jedoch nicht wirklich die Schuld des „reftable“-Formats, sondern eine Lücke in den von Git bereitgestellten Tools. Um diese Lücke zu schließen, haben wir einen neuen Unterbefehl `list` für `git-reflog(1)` eingeführt, mit dem du alle vorhandenen reflogs auflisten kannst:\n\n```shell\n$ git reflog list\nHEAD\nrefs/heads/main\n```\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab \"Patrick Steinhardt\") geleitet.\n\n### Effizienteres Packen von Referenzen\n\nUm effizient zu bleiben, müssen Git-Repositorys regelmäßig gewartet werden. Normalerweise wird diese Wartung durch verschiedene Git-Befehle ausgelöst, die Daten in die Git-Repositorys schreiben, indem sie den Befehl `git maintenance run --auto` ausführen. Dieser Befehl optimiert nur die Datenstrukturen, die tatsächlich optimiert werden müssen, damit Git keine Computeressourcen verschwendet.\n\nEine Datenstruktur, die von der Git-Wartung optimiert wird, ist die Referenzdatenbank, die mit dem Befehl `git pack-refs --all` optimiert wird. Für das „files“-Backend bedeutet dies, dass alle Referenzen in die „packed-refs“-Datei gepackt und die losen Referenzen gelöscht werden, während für das „reftable“-Backend alle Tabellen in einer einzigen Tabelle zusammengefasst werden.\n\nIm Hinblick auf das „files“-Backend können wir nicht viel besser vorgehen. Da die gesamte „packed-refs“-Datei ohnehin neu geschrieben werden muss, ist es sinnvoll, alle losen Referenzen zu packen.\n\nFür das „reftable“-Backend ist dies jedoch suboptimal, da sich das „reftable“-Backend selbst optimiert. Jedes Mal, wenn Git eine neue Tabelle an das „reftable“-Backend anhängt, führt es eine automatische Komprimierung durch und führt die Tabellen nach Bedarf zusammen. Deshalb sollte sich die Referenzdatenbank immer in einem gut optimierten Zustand befinden, sodass das Zusammenführen aller Tabellen vergebliche Mühe wäre.\n\nIn Git v2.45.0 haben wir daher einen neuen Modus `git pack-refs --auto` eingeführt, der das Referenz-Backend auffordert, nach Bedarf zu optimieren. Während das „files“-Backend auch bei gesetztem `--auto`-Flag weiterhin gleich funktioniert, verwendet das „reftable“-Backend die gleichen Heuristiken, die es bereits für seine automatische Komprimierung verwendet. In der Praxis sollte dies in den meisten Fällen kein Problem darstellen.\n\nAußerdem wurde `git maintenance run --auto` so angepasst, dass das Flag `--auto` an `git-pack-refs(1)` übergeben wird, um diesen neuen Modus standardmäßig zu verwenden.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab \"Patrick Steinhardt\") geleitet. \n\n## Weiterlesen\n\nIn diesem Blogbeitrag ging es vor allem um das neue „reftable“-Backend, das es uns ermöglicht, in großen Repositorys mit vielen Referenzen besser zu skalieren, sowie um die zugehörigen Tools, die wir parallel dazu eingeführt haben, damit es gut funktioniert. Natürlich hat die Git-Community mit dieser Version auch verschiedene Leistungsverbesserungen, Fehlerbehebungen und kleinere Funktionen eingeführt. Diese kannst du in der [offiziellen Versionsankündigung](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"offiziellen Versionsankündigung\") des Git-Projekts nachlesen.\n",[705,271],{"slug":1023,"featured":6,"template":685},"whats-new-in-git-2-45-0","content:de-de:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","de-de/blog/whats-new-in-git-2-45-0.yml","de-de/blog/whats-new-in-git-2-45-0",2,[692,712,735,755,775,795,815,838,859],1754079018276]