[{"data":1,"prerenderedAt":938},["ShallowReactive",2],{"/en-us/blog/tags/community/":3,"navigation-de-de":19,"banner-de-de":438,"footer-de-de":451,"community-tag-page-de-de":661},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/community","tags",false,"",{"tag":9,"tagSlug":9},"community",{"template":11},"BlogTag","content:en-us:blog:tags:community.yml","yaml","Community","content","en-us/blog/tags/community.yml","en-us/blog/tags/community","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":434,"_type":13,"title":435,"_source":15,"_file":436,"_stem":437,"_extension":18},"/shared/de-de/main-navigation","de-de",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":375,"minimal":411,"duo":425},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/de-de/","gitlab logo","header",{"text":29,"config":30},"Kostenlose Testversion anfordern",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Vertrieb kontaktieren",{"href":36,"dataGaName":37,"dataGaLocation":27},"/de-de/sales/","sales",{"text":39,"config":40},"Anmelden",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,187,192,296,356],{"text":45,"config":46,"cards":48,"footer":71},"Plattform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":52,"config":53},"Erkunde unsere Plattform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/de-de/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":59,"config":60},"Lerne GitLab Duo kennen",{"href":61,"dataGaName":62,"dataGaLocation":27},"/de-de/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":67,"config":68},"Mehr erfahren",{"href":69,"dataGaName":70,"dataGaLocation":27},"/de-de/why-gitlab/","why gitlab",{"title":72,"items":73},"Erste Schritte mit",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/de-de/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Entwicklererfahrung",{"href":82,"dataGaName":83,"dataGaLocation":27},"/de-de/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":169},"Produkt",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":27},"/de-de/solutions/",[98,124,147],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,115,120],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":112,"config":113},"KI-unterstützte Entwicklung",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Quellcodeverwaltung",{"href":118,"dataGaLocation":27,"dataGaName":119},"/de-de/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Automatisierte Softwarebereitstellung",{"href":104,"dataGaLocation":27,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":27,"icon":131},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Schutz der Software-Lieferkette",{"href":141,"dataGaLocation":27,"dataGaName":142},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":27},"/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Bewertung",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Sichtbarkeit und Bewertung",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Wertstrommanagement",{"href":162,"dataGaLocation":27,"dataGaName":163},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Analysen und Einblicke",{"href":167,"dataGaLocation":27,"dataGaName":168},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab für",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":27,"dataGaName":176},"/de-de/enterprise/","enterprise",{"text":178,"config":179},"Kleinunternehmen",{"href":180,"dataGaLocation":27,"dataGaName":181},"/de-de/small-business/","small business",{"text":183,"config":184},"den öffentlichen Sektor",{"href":185,"dataGaLocation":27,"dataGaName":186},"/de-de/solutions/public-sector/","public sector",{"text":188,"config":189},"Preise",{"href":190,"dataGaName":191,"dataGaLocation":27,"dataNavLevelOne":191},"/de-de/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":283},"Ressourcen",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Alle Ressourcen anzeigen",{"href":199,"dataGaName":195,"dataGaLocation":27},"/de-de/resources/",[201,234,257],{"title":202,"items":203},"Erste Schritte",[204,209,214,219,224,229],{"text":205,"config":206},"Installieren",{"href":207,"dataGaName":208,"dataGaLocation":27},"/de-de/install/","install",{"text":210,"config":211},"Kurzanleitungen",{"href":212,"dataGaName":213,"dataGaLocation":27},"/de-de/get-started/","quick setup checklists",{"text":215,"config":216},"Lernen",{"href":217,"dataGaLocation":27,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Produktdokumentation",{"href":222,"dataGaName":223,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best-Practice-Videos",{"href":227,"dataGaName":228,"dataGaLocation":27},"/de-de/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrationen",{"href":232,"dataGaName":233,"dataGaLocation":27},"/de-de/integrations/","integrations",{"title":235,"items":236},"Entdecken",[237,242,247,252],{"text":238,"config":239},"Kundenerfolge",{"href":240,"dataGaName":241,"dataGaLocation":27},"/de-de/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":27},"/de-de/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":27},"/de-de/teamops/","teamops",{"title":258,"items":259},"Vernetzen",[260,265,268,273,278],{"text":261,"config":262},"GitLab-Services",{"href":263,"dataGaName":264,"dataGaLocation":27},"/de-de/services/","services",{"text":14,"config":266},{"href":267,"dataGaName":9,"dataGaLocation":27},"/community/",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Veranstaltungen",{"href":276,"dataGaName":277,"dataGaLocation":27},"/events/","events",{"text":279,"config":280},"Partner",{"href":281,"dataGaName":282,"dataGaLocation":27},"/de-de/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":288,"config":289},"the source promo card",{"src":290},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":292,"config":293},"Lies die News",{"href":294,"dataGaName":295,"dataGaLocation":27},"/de-de/the-source/","the source",{"text":297,"config":298,"lists":300},"Unternehmen",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"Über",{"href":306,"dataGaName":307,"dataGaLocation":27},"/de-de/company/","about",{"text":309,"config":310,"footerGa":313},"Karriere",{"href":311,"dataGaName":312,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":27},{"text":317,"config":318},"Geschäftsführung",{"href":319,"dataGaName":320,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":27},"/company/team/","team",{"text":327,"config":328},"Handbuch",{"href":329,"dataGaName":330,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor Relations",{"href":334,"dataGaName":335,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":27},"/de-de/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":27},"/de-de/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":27},"/company/contact/","newsletter",{"text":352,"config":353},"Presse",{"href":354,"dataGaName":355,"dataGaLocation":27},"/press/","press",{"text":357,"config":358,"lists":359},"Kontakt",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":34,"config":363},{"href":36,"dataGaName":364,"dataGaLocation":27},"talk to sales",{"text":366,"config":367},"Support",{"href":368,"dataGaName":369,"dataGaLocation":27},"/support/","get help",{"text":371,"config":372},"Kundenportal",{"href":373,"dataGaName":374,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Schließen",{"text":378,"link":379},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":380,"config":381},"gitlab.com",{"href":41,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Vorschläge",[387,390,395,397,402,407],{"text":56,"config":388},{"href":61,"dataGaName":389,"dataGaLocation":383},"GitLab Duo (AI)",{"text":391,"config":392},"Code Suggestions (KI)",{"href":393,"dataGaName":394,"dataGaLocation":383},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":396},{"href":110,"dataGaName":108,"dataGaLocation":383},{"text":398,"config":399},"GitLab auf AWS",{"href":400,"dataGaName":401,"dataGaLocation":383},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":403,"config":404},"GitLab auf Google Cloud",{"href":405,"dataGaName":406,"dataGaLocation":383},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":408,"config":409},"Warum GitLab?",{"href":69,"dataGaName":410,"dataGaLocation":383},"Why GitLab?",{"freeTrial":412,"mobileIcon":417,"desktopIcon":422},{"text":413,"config":414},"Kostenlos testen",{"href":415,"dataGaName":32,"dataGaLocation":416},"https://gitlab.com/-/trials/new/","nav",{"altText":418,"config":419},"GitLab-Symbol",{"src":420,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":418,"config":423},{"src":424,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Erfahre mehr über GitLab Duo",{"href":61,"dataGaName":429,"dataGaLocation":416},"gitlab duo",{"altText":418,"config":431},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":433},{"src":424,"dataGaName":421,"dataGaLocation":416},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":439,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":440,"button":441,"config":446,"_id":448,"_type":13,"_source":15,"_file":449,"_stem":450,"_extension":18},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":442,"config":443},"Beta testen",{"href":444,"dataGaName":445,"dataGaLocation":27},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":447},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":452,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":453,"_id":657,"_type":13,"title":658,"_source":15,"_file":659,"_stem":660,"_extension":18},"/shared/de-de/main-footer",{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":649},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":456,"config":457},"Quelltext der Seite anzeigen",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"Diese Seite bearbeiten",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"Beteilige dich",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,555,585,619],{"title":45,"links":478,"subMenu":483},[479],{"text":480,"config":481},"DevSecOps-Plattform",{"href":54,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":188,"links":485},[486,490,495],{"text":487,"config":488},"Tarife anzeigen",{"href":190,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Vorteile von Premium",{"href":493,"dataGaName":494,"dataGaLocation":460},"/de-de/pricing/premium/","why premium",{"text":496,"config":497},"Vorteile von Ultimate",{"href":498,"dataGaName":499,"dataGaLocation":460},"/de-de/pricing/ultimate/","why ultimate",{"title":501,"links":502},"Lösungen",[503,508,511,513,518,523,527,530,533,538,540,542,545,550],{"text":504,"config":505},"Digitale Transformation",{"href":506,"dataGaName":507,"dataGaLocation":460},"/de-de/topics/digital-transformation/","digital transformation",{"text":509,"config":510},"Sicherheit und Compliance",{"href":136,"dataGaName":137,"dataGaLocation":460},{"text":121,"config":512},{"href":104,"dataGaName":105,"dataGaLocation":460},{"text":514,"config":515},"Agile Entwicklung",{"href":516,"dataGaName":517,"dataGaLocation":460},"/de-de/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"Cloud-Transformation",{"href":521,"dataGaName":522,"dataGaLocation":460},"/de-de/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":118,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":108,"config":528},{"href":110,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":160,"config":531},{"href":162,"dataGaName":532,"dataGaLocation":460},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":460},"/de-de/solutions/gitops/","gitops",{"text":173,"config":539},{"href":175,"dataGaName":176,"dataGaLocation":460},{"text":178,"config":541},{"href":180,"dataGaName":181,"dataGaLocation":460},{"text":543,"config":544},"Öffentlicher Sektor",{"href":185,"dataGaName":186,"dataGaLocation":460},{"text":546,"config":547},"Bildungswesen",{"href":548,"dataGaName":549,"dataGaLocation":460},"/de-de/solutions/education/","education",{"text":551,"config":552},"Finanzdienstleistungen",{"href":553,"dataGaName":554,"dataGaLocation":460},"/de-de/solutions/finance/","financial services",{"title":193,"links":556},[557,559,561,563,566,568,571,573,575,577,579,581,583],{"text":205,"config":558},{"href":207,"dataGaName":208,"dataGaLocation":460},{"text":210,"config":560},{"href":212,"dataGaName":213,"dataGaLocation":460},{"text":215,"config":562},{"href":217,"dataGaName":218,"dataGaLocation":460},{"text":220,"config":564},{"href":222,"dataGaName":565,"dataGaLocation":460},"docs",{"text":243,"config":567},{"href":245,"dataGaName":246,"dataGaLocation":460},{"text":238,"config":569},{"href":570,"dataGaName":241,"dataGaLocation":460},"/customers/",{"text":248,"config":572},{"href":250,"dataGaName":251,"dataGaLocation":460},{"text":261,"config":574},{"href":263,"dataGaName":264,"dataGaLocation":460},{"text":253,"config":576},{"href":255,"dataGaName":256,"dataGaLocation":460},{"text":14,"config":578},{"href":267,"dataGaName":9,"dataGaLocation":460},{"text":269,"config":580},{"href":271,"dataGaName":272,"dataGaLocation":460},{"text":274,"config":582},{"href":276,"dataGaName":277,"dataGaLocation":460},{"text":279,"config":584},{"href":281,"dataGaName":282,"dataGaLocation":460},{"title":297,"links":586},[587,589,591,593,595,597,599,603,608,610,612,614],{"text":304,"config":588},{"href":306,"dataGaName":299,"dataGaLocation":460},{"text":309,"config":590},{"href":311,"dataGaName":312,"dataGaLocation":460},{"text":317,"config":592},{"href":319,"dataGaName":320,"dataGaLocation":460},{"text":322,"config":594},{"href":324,"dataGaName":325,"dataGaLocation":460},{"text":327,"config":596},{"href":329,"dataGaName":330,"dataGaLocation":460},{"text":332,"config":598},{"href":334,"dataGaName":335,"dataGaLocation":460},{"text":600,"config":601},"Sustainability",{"href":602,"dataGaName":600,"dataGaLocation":460},"/sustainability/",{"text":604,"config":605},"Vielfalt, Inklusion und Zugehörigkeit",{"href":606,"dataGaName":607,"dataGaLocation":460},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":609},{"href":339,"dataGaName":340,"dataGaLocation":460},{"text":347,"config":611},{"href":349,"dataGaName":350,"dataGaLocation":460},{"text":352,"config":613},{"href":354,"dataGaName":355,"dataGaLocation":460},{"text":615,"config":616},"Transparenzerklärung zu moderner Sklaverei",{"href":617,"dataGaName":618,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":620,"links":621},"Nimm Kontakt auf",[622,625,627,629,634,639,644],{"text":623,"config":624},"Sprich mit einem Experten/einer Expertin",{"href":36,"dataGaName":37,"dataGaLocation":460},{"text":366,"config":626},{"href":368,"dataGaName":369,"dataGaLocation":460},{"text":371,"config":628},{"href":373,"dataGaName":374,"dataGaLocation":460},{"text":630,"config":631},"Status",{"href":632,"dataGaName":633,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":635,"config":636},"Nutzungsbedingungen",{"href":637,"dataGaName":638,"dataGaLocation":460},"/terms/","terms of use",{"text":640,"config":641},"Datenschutzerklärung",{"href":642,"dataGaName":643,"dataGaLocation":460},"/de-de/privacy/","privacy statement",{"text":645,"config":646},"Cookie-Einstellungen",{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":460},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":460},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":460,"id":648,"isOneTrustButton":90},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":662,"featuredPost":916,"totalPagesCount":936,"initialPosts":937},[663,684,711,735,755,778,798,817,836,856,876,896],{"_path":664,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":668,"config":677,"_id":680,"_type":13,"title":681,"_source":15,"_file":682,"_stem":683,"_extension":18},"/de-de/blog/fine-grained-job-tokens-ga",{"title":666,"description":667},"Granulare Job Token Berechtigungen sind jetzt verfügbar","GitLab ermöglicht granulare Berechtigungen für CI/CD Job Tokens und erhöht die Sicherheit der Software-Supply-Chain.",{"title":666,"description":667,"authors":669,"heroImage":672,"date":673,"category":674,"tags":675,"body":676},[670,671],"Alex Mark","Joe Randazzo","blog/hero%20images/workflow_1800x945.png","2025-08-26","engineering",[9],"[CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/) Pipelines erben oft überprivilegierte Berechtigungen von Benutzerkonten, was erhebliche Sicherheitsrisiken birgt, wenn Pipelines kompromittiert oder Tokens geleakt werden. [GitLab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/) führt granulare Berechtigungen für Job Tokens ein, um dieses Problem zu lösen, und überführt diese Sicherheitsverbesserung von Beta zu allgemeiner Verfügbarkeit.\n\nDiese Funktion ermöglicht es Maintainern, granulare Berechtigungen zu implementieren, die den Job-Token-Zugriff auf API-Ressourcen kontrollieren. Gemäß dem [Principle of Least Privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) haben diese Job Tokens keinerlei Zugriffsmöglichkeit auf API-Ressourcen, bis explizit Berechtigungen erteilt werden.\n\nDiese erste Version umfasst granulare Berechtigungen für die folgenden Ressourcen:\n\n* Repositories\n* Deployments\n* Environments\n* Jobs\n* Packages\n* Pipelines\n* Releases\n* Secure Files\n* Terraform State\n\nZusätzliche API-Endpunkte sind für zukünftige Releases geplant. Weitere Informationen finden sich im [zugehörigen Epic](https://gitlab.com/groups/gitlab-org/-/epics/6310).\n\n![Beispiel für granulare Berechtigungen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755633419/izgwpj45oxoof0frvhap.png)\n\n## Das Gesamtbild\n\nDiese Version stellt einen wichtigen Schritt in GitLabs übergeordneter Mission dar, die Sicherheit der Software-Supply-Chain zu verbessern. Historisch waren Job Tokens an den oder die Benutzer(in) gebunden, der oder die die Pipeline ausführt, wodurch bestehende Privilegien weitergegeben wurden und Sicherheitsrisiken entstanden, wenn Pipelines kompromittiert wurden.\n\nGranulare Berechtigungen für Job Tokens bieten eine Grundlage für ein sichereres CI/CD-Ökosystem, das:\n\n* **Die Angriffsfläche reduziert**: Implementiert das Principle of Least Privilege durch Beschränkung des Zugriffs auf nur notwendige Ressourcen\n* **Die Abhängigkeit von langlebigen Tokens eliminiert**: Bietet eine sichere Alternative, die den Bedarf an persönlichen Zugriffstokens und anderen persistenten Anmeldedaten reduziert\n* **Auf maschinenbasierte Identität vorbereitet**: Dieser Opt-in-Ansatz legt den Grundstein dafür, Job Tokens perspektivisch vollständig von Benutzeridentitäten zu entkoppeln und sich in Richtung echter Machine-to-Machine-Authentifizierung zu bewegen\n* **Sichere Automatisierung im großen Maßstab ermöglicht**: Unterstützt komplexe Deployment-Workflows und CI/CD-Komponenten ohne Kompromisse bei der Sicherheit\n\n## Erste Schritte\n\nSecurity-Teams und DevOps-Ingenieure sollten diese Funktion für alle Projekte evaluieren, die automatisierte Deployments, Package-Veröffentlichungen oder Infrastructure Management durchführen. Da es sich um eine Opt-in-Funktion handelt, kann die Migration schrittweise erfolgen, um Störungen bestehender Pipelines zu minimieren.\n\nBeginne damit, die kritischsten Pipelines zu identifizieren und deren aktuelle Berechtigungsanforderungen zu prüfen. Aktiviere dann granulare Berechtigungen und konfiguriere den minimalen Zugriff, der für jedes Projekt benötigt wird. Weitere Informationen finden sich in der [Dokumentation zu granularen Berechtigungen für CI/CD Job Tokens](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/).",{"slug":678,"featured":6,"template":679},"fine-grained-job-tokens-ga","BlogPost","content:de-de:blog:fine-grained-job-tokens-ga.yml","Fine Grained Job Tokens Ga","de-de/blog/fine-grained-job-tokens-ga.yml","de-de/blog/fine-grained-job-tokens-ga",{"_path":685,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":686,"content":694,"config":705,"_id":707,"_type":13,"title":708,"_source":15,"_file":709,"_stem":710,"_extension":18},"/de-de/blog/how-gitlab-empowers-translators-with-more-context",{"title":687,"description":688,"ogTitle":687,"ogDescription":688,"noIndex":6,"ogImage":689,"ogUrl":690,"ogSiteName":691,"ogType":692,"canonicalUrls":690,"schema":693},"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","https://about.gitlab.com","article","\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":687,"description":688,"authors":695,"heroImage":689,"date":697,"body":698,"category":699,"tags":700,"updatedDate":704},[696],"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","open-source",[9,701,702,703],"collaboration","product","contributors","2025-02-10",{"slug":706,"featured":6,"template":679},"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":712,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":713,"content":717,"config":729,"_id":731,"_type":13,"title":732,"_source":15,"_file":733,"_stem":734,"_extension":18},"/de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":714,"description":715,"ogTitle":714,"ogDescription":715,"config":716},"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":718,"body":719,"authors":720,"updatedDate":723,"date":724,"title":725,"tags":726,"description":728,"category":699},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png","GitLabs Contributor Success Team stand vor einer Herausforderung.\n\nWährend unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von [GitLabs Mission](https://handbook.gitlab.com/handbook/company/mission/),\n\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\n\n\nWir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat\n\nund übertrafen damit erstmals unser Teamziel von 170.\n\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\n\n\nSo haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.\n\n\n## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\n\nWir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.\n\n\nDie Teilnehmenden sagten uns:\n\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n\n* Der Einstieg fühlte sich überwältigend an\n\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\n\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\n\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\n\n\n2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100 %. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der\n\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\n\n„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'\"\n\n\n## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\n\nUnsere Lösung begann mit Engagement.\n\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\n\nMitwirkenden mit einem Community-Maintainer verbindet.\n\n\nWir erstellten ein [Issue-Template](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md) mit einer klaren Checkliste von Aufgaben.\n\n\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\n\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\n\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\n\n\nMit [Scoped Labels](https://docs.gitlab.com/user/project/labels/#scoped-labels) zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.\n\n\n![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\n\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\n\n\nVon hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.\n\n\n## Wir standardisierten Antworten mit Kommentar-Templates\n\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\n\ndie wir mit dem Repository über die GraphQL-API und ein\n\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\n\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n\n```yaml\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\n\nUnsere erste Iteration war etwas langsam.\n\nNach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen.\n\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\n\n\n[Niklas](https://gitlab.com/Taucher2003), ein Mitglied unseres [Core Teams](https://about.gitlab.com/community/core-team/), entwickelte eine Lösung. Er fügte [Webhook-Events für Zugangsanfragen ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094)und [benutzerdefinierte Payload-Templates für Webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738) hinzu.\n\n\nDiese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.\n\n\nWir richteten ein [Pipeline-Trigger-Token](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:\n\n\n```json\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n```\n\n\n![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Wir automatisierten Nachfassaktionen\n\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\n\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\n\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\n\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\n\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## Wir organisierten die Issue-Verfolgung mit GLQL\n\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\n\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\n\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nEs war so erfolgreich, dass wir diese Strategie auch bei den Programmen [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\n\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\n\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n\n## Wir machten die README auffindbar\n\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\n\nist das Zuhause für Mitwirkende auf GitLab.com.\n\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\n\nbefand sich in unserem Meta-Projekt.\n\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\n\nOnboarding-Issues unter einem anderen Projekt waren.\n\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\n\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\n\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Die Ergebnisse sprechen für sich selbst\n\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\n\nund transformierten die GitLab-Mitwirkenden-Journey.\n\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\n\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\n\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\n\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\n\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\n\num unsere Antwortzeiten zu verfolgen.\n\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\n\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\n\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\n\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\n\nErfolge und Belohnungen bietet.\n\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n\n## Was wir gelernt haben teilen\n\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\n\nWir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.\n\n\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\n\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\n\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n\n## Das Gespräch beginnen\n\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\n\nSende eine E-Mail an `contributors@gitlab.com` oder [öffne ein Issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues),\n\num eine Diskussion zu beginnen.\n\nWir sind hier, um beim Aufbau von Communities zu helfen.\n",[721,722],"Lee Tickett","Daniel Murphy","2025-07-23","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[727,9,702],"open source","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":679,"slug":730},"how-we-use-gitlab-to-grow-open-source-communities","content:de-de:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"_path":736,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":740,"config":749,"_id":751,"_type":13,"title":752,"_source":15,"_file":753,"_stem":754,"_extension":18},"/de-de/blog/inside-gitlabs-healthy-backlog-initiative",{"noIndex":6,"title":738,"description":739,"ogTitle":738,"ogDescription":739},"So optimiert GitLab das Issue-Management für mehr Innovation","GitLab reduziert 65.000 Issues auf das Wesentliche. Erfahre, wie die Healthy Backlog Initiative schnellere Entwicklung und klarere Roadmaps ermöglicht.",{"title":741,"description":742,"authors":743,"heroImage":745,"date":723,"body":746,"category":674,"tags":747},"Hinter den Kulissen von GitLabs Healthy Backlog Initiative","Wie GitLab 65.000 Issues in strategische Features, schnelle Entwicklung und direkte Community-Kommunikation verwandelt.",[744],"Stan Hu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","Bei GitLab pflegen wir eine starke Partnerschaft mit unserer Community und ermutigen jeden zur aktiven Mitarbeit. Diese Beiträge haben die GitLab-Plattform über Jahre hinweg gestärkt. Doch mit unserem Wachstum stieg auch die Anzahl der Community-Issues - bis hin zu einem schwer handhabbaren Backlog von über 65.000 Einträgen.\n\nDie Produkt- und Engineering-Teams von GitLab haben kürzlich die [Healthy Backlog Initiative](https://gitlab.com/groups/gitlab-org/-/epics/18639) gestartet, um dieses Backlog anzugehen und unseren Ansatz für die Verwaltung beigetragener Issues in Zukunft zu verfeinern.\n\nIssues mit laufendem Community-Engagement, aktueller Aktivität oder klarer strategischer Ausrichtung bleiben offen. Wir werden Issues schließen, die nicht mehr relevant sind, kein Community-Interesse haben oder nicht mehr zu unserer aktuellen Produktausrichtung passen.\n\nDieser Fokus wird zu mehr Innovation, besserer Erwartungshaltung und schnelleren Entwicklungs- und Bereitstellungszyklen von der Community beigetragenen Funktionen führen.\n\n## Die Healthy Backlog Initiative: 65.000 Issues strategisch reduzieren\n\nIm Laufe der Zeit hat die GitLab-Community zahlreiche Issues eingereicht, darunter Bugs, Feature-Anfragen und Feedback-Elemente. Derzeit enthält der zentrale [GitLab-Issue-Tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) über 65.000 Issues, von denen einige heute nicht mehr relevant sind, andere hingegen schon.\n\nUnsere Healthy Backlog Initiative wird das Backlog bereinigen und einen Arbeitsstrom für unsere Produkt- und Engineering-Teams etablieren, um einen fokussierteren Ansatz zur Backlog-Verwaltung umzusetzen. Sie werden wöchentliche Bewertungen des Backlogs durchführen, um sicherzustellen, dass wir Issues priorisieren, die mit unserer Produktstrategie und Roadmap übereinstimmen.\n\n**Hinweis:** Wenn du der Meinung bist, dass ein geschlossenes Issue mit GitLabs Produktstrategie und Roadmap übereinstimmt, oder wenn du aktiv an der Anfrage arbeitest, ermutigen wir dich, das Issue mit aktualisiertem Kontext und aktuellen Details zu kommentieren. Wir verpflichten uns, diese aktualisierten Issues im Rahmen unserer regelmäßigen Bewertungen zu überprüfen.\n\n## Die Vorteile: Fokussierte Entwicklung und klarere Roadmaps\n\nDieser optimierte Ansatz bedeutet direkte, greifbare Verbesserungen für alle GitLab-Nutzer:\n\n* **Schärferer Fokus und schnellere Bereitstellung:** Durch die Eingrenzung unseres Backlogs auf strategisch ausgerichtete Funktionen können wir Entwicklungskapazitäten gezielter nutzen. Das bedeutet, dass du kürzere Entwicklungszyklen und spürbare Verbesserungen in GitLab erwarten kannst.\n* **Klarere Erwartungen:** Wir verpflichten uns zu transparenter Kommunikation darüber, was auf unserer Roadmap steht und was nicht, damit du fundierte Entscheidungen über deine Workflows treffen kannst.\n* **Beschleunigte Feedback-Schleifen:** Mit einem sauberen Backlog werden neue Feedbacks und Feature-Anfragen effizienter überprüft und priorisiert. Das verkürzt die Triage-Zeit und stellt sicher, dass zeitkritische Issues die notwendige Aufmerksamkeit erhalten. Dies schafft schnelleres Feedback für alle.\n\nDiese Initiative mindert nicht die Bedeutung von Community-Feedback und -Beiträgen. Wir ergreifen diese Maßnahme, um Klarheit darüber zu schaffen, was GitLab-Teammitglieder realistisch liefern können, und um sicherzustellen, dass alle Rückmeldungen angemessen berücksichtigt werden.\n\n## GitLabs Commitment: Transparente Prioritäten für die Community\n\nDie GitLab Healthy Backlog Initiative spiegelt unseren Anspruch wider, transparente und effektive Verwalter der GitLab-Plattform zu sein. Indem wir unsere Prioritäten klar kommunizieren und unsere Bemühungen auf das konzentrieren, was wir realistisch im nächsten Jahr erreichen können, sind wir besser positioniert, deine Erwartungen zu erfüllen und zu übertreffen.\n\nDeine kontinuierliche Teilnahme und dein Feedback helfen dabei, GitLab stärker zu machen. Jeder Kommentar, jede Merge Request, jeder Bug-Report und jeder Feature-Vorschlag trägt zu unserer gemeinsamen Vision bei. Und wir belohnen dich auch weiterhin dafür, mit Initiativen wie unserem monatlichen Notable Contributor-Programm, Swag-Belohnungen für Level-Ups, Hackathon-Gewinnern und mehr, alles verfügbar über unser [Contributor-Portal](https://contributors.gitlab.com).\n\n> Um mehr darüber zu erfahren, wie du zu GitLab beitragen kannst, [besuche unsere Community-Seite](https://about.gitlab.com/community/). Um Feedback zu diesem Projekt zu teilen, füge bitte deine Kommentare zum [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/556865) in diesem [Epic](https://gitlab.com/groups/gitlab-org/-/epics/18639) hinzu.",[9,702,748],"news",{"featured":90,"template":679,"slug":750},"inside-gitlabs-healthy-backlog-initiative","content:de-de:blog:inside-gitlabs-healthy-backlog-initiative.yml","Inside Gitlabs Healthy Backlog Initiative","de-de/blog/inside-gitlabs-healthy-backlog-initiative.yml","de-de/blog/inside-gitlabs-healthy-backlog-initiative",{"_path":756,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":757,"content":763,"config":772,"_id":774,"_type":13,"title":775,"_source":15,"_file":776,"_stem":777,"_extension":18},"/de-de/blog/we-need-to-talk-no-proxy",{"title":758,"description":759,"ogTitle":758,"ogDescription":759,"noIndex":6,"ogImage":760,"ogUrl":761,"ogSiteName":691,"ogType":692,"canonicalUrls":761,"schema":762},"Kann NO_PROXY standardisiert werden?","Erfahre, wie GitLab ein Problem gelöst hat, das durch die Unterschiede der\nVariablen, die nicht von allen Webclients unterstützt werden, entstanden\nist.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/we-need-to-talk-no-proxy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kann NO_PROXY standardisiert werden?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2021-01-27\",\n      }",{"title":758,"description":759,"authors":764,"heroImage":760,"date":765,"body":766,"category":674,"tags":767,"updatedDate":771},[744],"2021-01-27","Wenn du schon einmal einen Web-Proxyserver verwendet hast, bist du wahrscheinlich mit den Umgebungsvariablen `http_proxy` oder `HTTP_PROXY` vertraut. Weniger bekannt ist möglicherweise die Variable `no_proxy`, mit der du bestimmten Datenverkehr für bestimmte Hosts von der Verwendung des Proxys ausschließen kannst. Obwohl HTTP ein gut definierter Standard ist, existiert kein einheitlicher Standard dafür, wie Clients diese Variablen behandeln sollten. Dies führt dazu, dass Webclients diese Variablen auf sehr unterschiedliche Weise unterstützen. Bei einem GitLab-Kunden führten eben diese Unterschiede zu einer wochenlangen Fehlersuche, um herauszufinden, warum bestimmte Dienste nicht mehr kommunizierten.\n\nIn diesem Artikel erfährst du, wie wir die Probleme analysiert und gelöst haben.\n\n## Verwendung des Proxyservers: Konflikte und Ausnahmen\n\nDie meisten Webclients unterstützen heutzutage die Verbindung zu Proxy-Servern über Umgebungsvariablen (Environment variables):\n\n- `http_proxy / HTTP_PROXY`\n- `https_proxy / HTTPS_PROXY`\n- `no_proxy / NO_PROXY`\n\nDiese Variablen sagen dem Client, welche URL genutzt werden sollte, um Zugang zu Proxyservern zu erhalten und welche Ausnahmen gemacht werden sollten. Wenn du zum Beispiel einen Proxyserver hast, der auf `http://alice.example.com:8080` überwacht wird, könntest du ihn verwenden via:\n\n```sh\nexport http_proxy=http://alice.example.com:8080\n```\n\nWelcher Proxyserver wird verwendet, wenn Bob die Version in Großbuchstaben, `HTTP_PROXY`, ebenfalls definiert?\n\n```sh\nexport HTTP_PROXY=http://bob.example.com:8080\n```\n\nDie Antwort ist uneindeutig: Es hängt vom jeweiligen Kontext ab. In einigen Fällen gewinnt der Proxy von Alice, in anderen Fällen gewinnt Bob. \n\n### Ausnahmen definieren\n\nWas passiert, wenn du Ausnahmen machen willst? Nehmen wir etwa an, du willst einen Proxyserver für alles außer `internal.example.com` und `internal2.example.com` verwenden. In diesem Fall kommt die Variable `no_proxy` ins Spiel. Dann würdest du `no_proxy` wie folgt definieren:\n\n```sh\nexport no_proxy=internal.example.com,internal2.example.com\n```\n\nWas ist, wenn du IP-Adressen ausschließen willst? Kann man Sternchen oder eine `no_proxy`-Wildcard verwenden? Kann man CIDR-Blöcke verwenden (z. B. `192.168.1.1/32`)? Auch hier gilt wieder: Es kommt darauf an.\n\n## Geschichte der Webclients,wget no_proxy und cURLno_proxy\n\n1994 haben die meisten Webclients CERN's `libwww` genutzt, welche `http_proxy` und die `no_proxy` Umgebungsvariable unterstützt haben. `libwww` hat nur die kleingeschriebene Variante von `http_proxy` verwendet. Somit war die `no_proxy`-[Syntax](https://github.com/w3c/libwww/blob/8678b3dcb4191065ca39caea54bb1beba809a617/Library/src/HTAccess.c#L234-L239 \"Syntax\") sehr einfach:\n\n```\nno_proxy ist eine mithilfe von Kommas oder Leerzeichen  getrennte Liste von Rechner-\noder Domain-Namen mit optionalem :port part. Wenn kein :port\npart vorhanden ist, wird sie für alle Ports auf der Domain angewendet.\n\nBeispiel:\n\t\tno_proxy=\"cern.ch,some.domain:8001\"\n```\n\nEs entstanden neue Clients, die ihre eigenen HTTP-Implementierungen hinzufügten, ohne auf `libwww` zu verlinken. Im Januar 1996 veröffentlichte Hrvoje Niksic `geturl`, den Vorgänger des heutigen `wget`. Einen Monat später fügte `geturl` in v1.1 Unterstützung für `http_proxy` hinzu. Im Mai 1996 wurde mit `geturl` v1.3 die Unterstützung für `no_proxy` hinzugefügt. Genau wie `libwww` unterstützte `geturl` nur die Kleinbuchstabenform.\n\nIm Januar 1998 veröffentlichte Daniel Stenberg `curl` v5.1, das die Variablen `http_proxy` und `no_proxy` unterstützte. Darüber hinaus erlaubte `curl` die Großbuchstaben HTTP_PROXY und NO_PROXY. Eine plötzliche Wendung: Im März 2009 wurde mit `curl` v7.19.4 die Unterstützung für die Großbuchstabenvariante von HTTP_PROXY aufgrund von Sicherheitsbedenken eingestellt. Während curl HTTP_PROXY ignoriert, funktioniert HTTPS_PROXY jedoch auch heute noch.\n\nHeutzutage werden diese Proxyserver-Variablen je nach verwendeter Sprache oder Tool unterschiedlich gehandhabt.\n\n## http_proxy und https_proxy\n\nIn der folgenden Tabelle steht jede Zeile für ein unterstütztes Verfahren, während jede Spalte das Werkzeug (z.B. curl) oder die Sprache (z.B. Ruby) enthält, für die es gilt:\n\n|                 | curl      | wget           | Ruby          | Python    | Go        |\n|-----------------|-----------|----------------|---------------|-----------|-----------|\n| `http_proxy`    | Ja       | Ja            | Ja           | Ja       | Ja       |\n| `HTTP_PROXY`    | Nein       | Nein             |Ja ([warning](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1519)) | Ja (wenn `REQUEST_METHOD` nicht in env)       | Ja       |\n| `https_proxy`   | Ja       | Ja            | Ja           | Ja       | Ja       |\n| `HTTPS_PROXY`   | Ja       | Nein             | Ja           | Ja       | Ja       |\n| Präzedenzfall | Kleinschreibung | Kleinschreibung | Kleinschreibung     | Kleinschreibung | Großschreibung |\n| Referenz      | [Quelle](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2266) | [Quelle](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1222-L1239) | [Quelle](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1474-L1543) | [Quelle](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2488-L2517) | [Quelle](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L82-L97) |\n\n### Proxy-Variablen in Python und Go: Der Unterschied zwischen Groß- und Kleinschreibung\n\nBeachte, dass `http_proxy` und `https_proxy` immer durchgängig unterstützt werden, während `HTTP_PROXY` nicht immer unterstützt wird. Python (über urllib) verkompliziert das Bild noch mehr: `HTTP_PROXY` kann so lange verwendet werden, wie `REQUEST_METHOD` nicht in der Umgebung definiert ist.\n\nWährend man erwarten könnte, dass Umgebungsvariablen in Großbuchstaben geschrieben werden, war `http_proxy` zuerst da und ist damit also der De-facto-Standard. Im Zweifelsfall sollte man sich für die Kleinschreibung entscheiden, da diese universell unterstützt wird.\n\nIm Gegensatz zu den meisten Implementierungen versucht Go es mit Großbuchstaben, bevor es auf die Kleinschreibung zurückgreift. Wir werden später noch sehen, warum genau diese Vorgehensweise bei einem GitLab-Kunden zu Problemen führte.\n\n### no_proxy im gleichen Issue\n\nEinige Benutzer(innen) haben das Fehlen der `no_proxy`-Spezifikation in diesem Issue diskutiert. Da `no_proxy` eine Ausschlussliste spezifiziert, stellen sich viele Fragen zu ihrem Verhalten. Nehmen wir zum Beispiel an, deine `no_proxy`-Konfiguration ist definiert:\n\n```sh\nexport no_proxy=example.com\n```\n\nBedeutet dies, dass die Domain ein exaktes Match sein muss oder wird `subdomain.example.com` auch mit dieser Konfiguration übereinstimmen? Die folgende Tabelle zeigt den Status der verschiedenen Implementierungen. Es stellt sich heraus, dass alle Implementierungen Suffixe korrekt abgleichen, wie in der Zeile “Stimmt mit Suffixen überein” zu sehen ist:\n\n|                       | curl      | wget           | Ruby      | Python    | Go        |\n|-----------------------|-----------|----------------|-----------|-----------|-----------|\n| `no_proxy`            | Ja       | Ja             | Ja        | Ja        | Ja        |\n| `NO_PROXY`            | Ja        | Nein            | Ja        | Ja        | Ja        |\n| Präzedenzfall       | Kleinschreibung | Kleinschreibung | Kleinschreibung | Kleinschreibung | Großschreibung |\n| Stimmt mit Suffixen überein?     | Ja       | Ja            | Ja        | Ja        | Ja        |\n| Strips leading `.`?   | Ja       | Nein            | Ja       | Ja       | Nein        |\n| `*` Stimmt mit allen Hosts überein?| Ja       | Nein             | Nein        | Ja       | Ja       |\n| Unterstützt Regexe?     | Nein        | Nein             | Nein        | Nein        | Nein        |\n| Unterstützt CIDR-Blöcke? | Nein        | Nein            | Ja       | Nein        | Ja       |\n| Erkennt Loopback-IPs? | Nein        | Nein          | Nein       | Nein       | Ja       |\n| Referenz            | [Quelle](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2152-L2206) | [Quelle](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1266-L1274) | [Quelle](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1545-L1554) | [Quelle](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2519-L2551)| [Quelle](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L170-L206) |\n\nWenn jedoch ein vorangestellter. in der `no_proxy`-Einstellung vorhanden ist, variiert das Verhalten. Zum Beispiel verhalten sich `curl` und  `wget` unterschiedlich. `curl` entfernt immer den vorangestellten . und nimmt den Vergleich mit einem Domain-Suffix vor. Dieser Aufruf umgeht den Proxy:\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com curl https://gitlab.com\n\u003Chtml>\u003Cbody>You are being \u003Ca href=\"https://about.gitlab.com/\">redirected\u003C/a>.\u003C/body>\u003C/html>\n```\n\nAllerdings entfernt  `wget` den vorangestellten`.` nicht und führt eine exakte String-Übereinstimmung mit einem Hostnamen durch. Infolgedessen versucht  `wget`, einen Proxy zu verwenden, wenn eine Top-Level-Domain verwendet wird:\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com wget https://gitlab.com\nResolving non.existent (non.existent)... failed: Name or service not known.\nwget: unable to resolve host address 'non.existent'\n```\n\nIn keiner der Implementierungen werden reguläre Ausdrücke unterstützt. Die Verwendung von Regexes würde die Angelegenheit zusätzlich verkomplizieren, da es verschiedene Varianten gibt (z. B. PCRE, POSIX usw.). Darüber hinaus führen Regexes zu potenziellen Leistungs- und Sicherheitsproblemen.\n\nIn einigen Fällen können Proxys durch das Setzen der `no_proxy`-Variable auf * vollständig deaktiviert werden, aber dies ist keine allgemeingültige Regel. Keine Implementierung führt einen DNS-Lookup durch, um einen Hostnamen in eine IP-Adresse aufzulösen, wenn entschieden wird, ob ein Proxy verwendet werden soll. Daher sollten keine IP-Adressen in der `no_proxy`-Variable angegeben werden, es sei denn, es wird erwartet, dass die IPs explizit vom Client verwendet werden.\n\nDasselbe gilt für CIDR-Blöcke wie z. B. 18.240.0.1/24. CIDR-Blöcke funktionieren nur, wenn die Anfrage direkt an eine IP-Adresse gestellt wird. Nur Go und Ruby erlauben die Verwendung von CIDR-Blöcken. Im Gegensatz zu anderen Implementierungen deaktiviert Go sogar automatisch die Verwendung eines Proxys, wenn eine Loopback-IP-Adresse erkannt wird.\n\n## Fehlerbehebung bei Proxy-Konfigurationen: Wie unterschiedliche no_proxy-Einstellungen GitLab-Prozesse beeinträchtigen\n\nWenn die Anwendung in mehreren Sprachen geschrieben ist und hinter einer Unternehmensfirewall mit einem Proxyserver arbeiten muss, solltest du auf diese Unterschiede achten. GitLab besteht zum Beispiel aus einigen in Ruby und Go geschriebenen Diensten. Ein Kunde hat seine Proxy-Konfiguration in etwa wie folgt eingestellt:\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\n```\n\nDer Kunde meldete das folgende Problem mit GitLab:\n\n1. Ein `git push` über die Befehlszeile funktionierte\n2. Über die Web-UI vorgenommene Git-Änderungen schlugen fehl\n\nUnsere Support-Techniker stellten fest, dass aufgrund eines Konfigurationsproblems bei [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/ \"Kubernetes\") einige veraltete Werte zurückblieben. Der Pod hatte eine Umgebung, die in etwa so aussah:\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\nno_proxy: .wrong-company.com\n```\n\nDie inkonsistenten Definitionen in `no_proxy` und `NO_PROXY` waren ein Warnsignal, und wir hätten das Problem lösen können, indem wir sie konsistent gemacht oder den falschen Eintrag entfernt hätten. Aber sehen wir uns an, was passiert ist:\n\n1. Ruby versucht es zuerst mit der kleingeschriebenen Variante\n2. Go versucht es zuerst mit der Variante in Großbuchstaben\n\nInfolgedessen hatten in Go geschriebene Dienste wie GitLab Workhorse die richtige Proxy-Konfiguration. Ein `git push` von der Befehlszeile aus funktionierte problemlos, da die Go-Dienste diesen Vorgang primär abwickelten:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant W as Workhorse\n    participant G as Gitaly\n    C->>W: git push\n    W->>G: gRPC: PostReceivePack\n    G->>W: OK\n    W->>C: OK\n```\n\nDer gRPC-Aufruf in Schritt 2 hat nie versucht, den Proxy zu verwenden, da `no_proxy` richtig konfiguriert wurde, um eine direkte Verbindung zu Gitaly herzustellen.\n\nWenn jedoch ein(e) Benutzer(in) eine Änderung in der Bedienoberfläche vornimmt, leitet Gitaly die Anfrage an einen `gitaly-ruby`-Service weiter, der in Ruby geschrieben ist.  `gitaly-ruby` nimmt Änderungen am Repository vor und meldet diese über einen gRPC-Aufruf an seinen übergeordneten Prozess zurück. Wie in Schritt 4 unten zu sehen ist, fand der Reporting-Schritt jedoch nicht statt:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>P: CONNECT\n    P->>GR: FAIL\n```\n\nDa gRPC HTTP/2 als Transport verwendet, versuchte  `gitaly-ruby` einen CONNECT zum Proxy, da es mit der falschen `no_proxy`-Einstellung konfiguriert war. Der Proxy lehnte diese HTTP-Anfrage sofort ab, was den Fehler im Web-UI-Push-Case verursachte.\n\nNachdem wir den Kleinbuchstaben `no_proxy` aus der Umgebung entfernt hatten, funktionierte der Push von der Bedienoberfläche wie erwartet, und  `gitaly-ruby` verband sich direkt mit dem übergeordneten Gitaly-Prozess. Schritt 4 funktionierte, wie im folgenden Diagramm dargestellt:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>G: OK\n    G->>R: OK\n    R->>C: OK\n```\n\n### Eine überraschende Entdeckung mit gRPC\n\nBeachte, dass der Kunde `HTTPS_PROXY` auf einen unverschlüsselten `HTTP_PROXY` gesetzt hat; beachte, dass `http://` anstelle von `https://` verwendet wird. Dies ist zwar vom Standpunkt der Sicherheit aus nicht ideal, aber es kann gemacht werden, um zu vermeiden, dass Clients aufgrund von Problemen bei der TLS-Zertifikatsüberprüfung scheitern.\n\nIronischerweise wäre dieses Problem nicht aufgetreten, wenn ein HTTPS-Proxy angegeben worden wäre. Wenn ein HTTPS-Proxy verwendet wird, ignoriert gRPC diese Einstellung, da HTTPS-Proxys nicht unterstützt werden.\n\n## Der kleinste gemeinsame Nenner\n\nMan sollte niemals inkonsistente Werte mit Proxy-Einstellungen in Klein- und Großbuchstaben definieren. Falls du allerdings jemals einen Stack verwalten musst, der in mehreren Sprachen geschrieben ist, solltest du in Erwägung ziehen, HTTP-Proxy-Konfigurationen auf den kleinsten gemeinsamen Nenner zu setzen:\n\n#### `http_proxy` und `https_proxy`\n\n* Verwende die Kleinschreibung. `HTTP_PROXY`  wird nicht immer unterstützt oder empfohlen.\n    * Wenn du unbedingt die Variante mit Großbuchstaben verwenden musst, achte darauf, dass sie denselben Wert hat.\n\n#### `no_proxy`\n\n1. Verwende die Kleinschreibung.\n2. Nutze durch Kommas getrennte `hostname:port` Werte.\n3. IP-Adressen sind okay, aber Hostnamen werden nie aufgelöst. \n4. Endungen werden immer zugeordnet (z.B. `example.com` wird `test.example.com` zugeordnet).\n5. Wenn Top-Level-Domains abgeglichen werden müssen, solltest du einen vorangestellten Punkt vermeiden (.).\n6. Vermeide die Verwendung von CIDR-Matching, da dies nur von Go und Ruby unterstützt wird.\n\n## Standardisierung von `no_proxy`\n\nDie Kenntnis des kleinsten gemeinsamen Nenners kann helfen, Probleme zu vermeiden, wenn diese Definitionen für verschiedene Webclients kopiert werden. Aber sollte es für `no_proxy` und die anderen Proxy-Einstellungen einen dokumentierten Standard geben und nicht nur eine Ad-hoc-Übereinstimmung? Die folgende Liste kann als Ausgangspunkt für einen Vorschlag dienen:\n\n1. Bevorzugung von Kleinbuchstaben gegenüber Großbuchstaben bei Variablen (z. B.  `http_proxy` sollte vor `HTTP_PROXY` gesucht werden).\n2. Verwende durch  Kommas getrennte Werte für `hostname:port`.\n    * Jeder Wert kann optionale Leerzeichen enthalten.\n3. Führe niemals DNS-Lookups durch und verwende keine regulären Formeln.\n4. Nutze `*` um alle Hosts zu verbinden.\n5. Führende Punkte (`.`) werden entfernt und mit Domain-Suffixen abgeglichen.\n6. Unterstützung des CIDR-Blockabgleichs.\n7. Stelle niemals Vermutungen über spezielle IP-Adressen an (z. B. Loopback-IP-Adressen in `no_proxy`).\n\n## Fazit \n\nSeit der Veröffentlichung des ersten Web-Proxys sind über 25 Jahre vergangen. Obwohl sich die grundlegenden Mechanismen zur Konfiguration eines Webclients über Umgebungsvariablen (wie z. B. environment no_proxy/env no_proxy) kaum verändert haben, haben sich bei den verschiedenen Implementierungen zahlreiche Feinheiten herausgebildet. Ein Beispiel aus der Praxis zeigt, dass die irrtümliche Definition widersprüchlicher `no_proxy`- und `NO_PROXY`-Variablen zu stundenlanger Fehlersuche führte, da Ruby und Go diese Einstellungen unterschiedlich auswerten. Das Hervorheben dieser Unterschiede kann helfen, zukünftige Probleme in deinem Produktions-Stack zu vermeiden. Es wäre wünschenswert, dass Webclient-Maintainer das Verhalten standardisieren, um solche Probleme von vornherein auszuschließen.",[9,768,769,770],"careers","user stories","startups","2024-10-09",{"slug":773,"featured":6,"template":679},"we-need-to-talk-no-proxy","content:de-de:blog:we-need-to-talk-no-proxy.yml","We Need To Talk No Proxy","de-de/blog/we-need-to-talk-no-proxy.yml","de-de/blog/we-need-to-talk-no-proxy",{"_path":779,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":780,"content":783,"config":792,"_id":794,"_type":13,"title":795,"_source":15,"_file":796,"_stem":797,"_extension":18},"/de-de/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":781,"description":782},"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":784,"description":782,"authors":785,"heroImage":787,"body":788,"date":789,"category":699,"tags":790},"Was gibt es Neues in Git 2.50.0?",[786],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Das Git-Projekt hat kürzlich\n[Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)\nveröffentlicht. Werfen wir einen Blick auf die Highlights dieser\nVeröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten\nGit-Community enthält.\n\n\n## Neuer Befehl git-diff-pairs(1)\n\n\nDiffs sind das Herzstück jeder Code Review und zeigen alle Änderungen, die zwischen zwei Revisionen vorgenommen wurden. GitLab zeigt Diffs an verschiedenen Stellen an, am häufigsten aber auf der [Registerkarte „Änderungen“ (in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/merge_requests/changes/) eines Merge Requests.\n\n\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nDieser Befehl gibt das vollständige Diff für alle geänderten Dateien zurück. Dies kann eine Herausforderung für die Skalierbarkeit darstellen, vor allem, wenn die Anzahl der Dateien, die innerhalb einer Reihe von Revisionen geändert wurden, sehr groß ist. Dies kann dazu führen, dass der Befehl selbst auferlegte Zeitlimits für das GitLab-Backend erreicht. Bei großen Änderungen wäre es besser, wenn\n\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\n\nEine Möglichkeit dafür ist die Verwendung von\n\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\n\nüber alle geänderten Dateien abzurufen:\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGit bezeichnet diese Ausgabe als [„unbearbeitetes“ Format (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree#_raw_output_format).\n\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\n\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\n\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\n\nschnell und liefert eine Zusammenfassung aller Änderungen. Dieser Befehl kann optional eine Umbenennungserkennung durchführen, indem das Flag `-M` angehängt wird. So kannst du überprüfen, ob identifizierte Änderungen auf eine Dateiumbenennung zurückzuführen sind.\n\n\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\n\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\n\ndirekt angeben:\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nWir können diesen Vorgang für jedes der Dateipaare wiederholen, aber es ist nicht sehr effizient, für jede einzelne Datei einen\n\nseparaten Git-Prozess zu starten.\n\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\n\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\n\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\n\ndie entsprechende Patch-Ausgabe zu generieren.\n\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\n\nakzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl\n\nverwendet werden kann:\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\n\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\n\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\n\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\n\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\n\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n## Gesammelte Referenz-Updates\n\n\nMit dem Git-Befehl [`git-update-ref(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-update-ref)\n\n kannst du Referenzaktualisierungen durchführen. Bei Verwendung mit dem Flag `--stdin` können\n\nmehrere Referenzaktualisierungen in einer einzigen Transaktion gebündelt werden, indem Anweisungen für jede Referenzaktualisierung\n\nangegeben werden, die auf stdin durchgeführt werden soll.\n\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\n\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\n\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n\n```shell\n\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# Gib die Commit-IDs aus\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# Die Referenz „bar“ wurde nicht erstellt.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\n\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\n\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\n\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\n\nMassenaktualisierungen nutzen möchten.\n\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\n\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\n\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nDadurch können erfolgreiche Referenzaktualisierungen fortgesetzt werden, während gleichzeitig angegeben wird, unter welchen Umständen Aktualisierungen abgelehnt wurden und aus welchem Grund. Wir verwenden noch einmal das gleiche beispielhafte Repository wie im vorherigen Beispiel:\n\n\n```shell\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\n\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\n\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\n\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Neue Filteroption für git-cat-file(1)\n\n\nMit [`git-cat-file(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-cat-file) ist es möglich,\n\nInformationen für alle im Repository enthaltenen Objekte über die Option\n\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n\n```shell\n\n# Richte ein einfaches Repository ein.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# Erstelle ein nicht erreichbares Objekt.\n\n$ git commit --amend --no-edit\n\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\n\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\n\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n\n`grep(1)` verwenden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\n\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\n\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\n\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\n\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\n\nihrem Typ gefiltert werden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\n\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\n\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\n\nnachschlagen und so das Durchsuchen der\n\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\n\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n```\n\n\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\n\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\n\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Verbesserte Leistung beim Generieren von Bundles\n\n\nGit bietet die Möglichkeit, über den Befehl\n\n[`git-bundle(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-bundle) ein Archiv eines Repositories zu generieren, das einen\n\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\n\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\n\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\n\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\n\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\n\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\n\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\n\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \n\nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\n\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n\n100 000 Referenzen enthält:\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nWeitere Informationen findest du in unserem Blogbeitrag\n\n[Wie wir die Backup-Zeiten für GitLab-Repos von 48 Stunden auf 41 Minuten verringerten (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/).\n\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\n\n[hier](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Bessere Auflösung von URI-Bundles\n\n\nDurch den [Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus in Git können den Clients\n\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\n\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\n\nunter `refs/heads/*` zusammen mit\n\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\n\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\n\ndie Bundle-URI beim Klonen verwendet wird.\n\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\n\ndemonstriert den Unterschied beim Klonen von\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\n\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\n\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\n\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\n\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\n\nBeschleunigung um 25 %.\n\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*TDiese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n\n## Weiterlesen\n\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\n\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\n\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\n\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\n\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n","2025-06-16",[791,727,9],"git",{"featured":90,"template":679,"slug":793},"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":799,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":800,"content":804,"config":811,"_id":813,"_type":13,"title":814,"_source":15,"_file":815,"_stem":816,"_extension":18},"/de-de/blog/what-s-new-in-git-2-51-0",{"config":801,"ogImage":787,"title":802,"description":803},{"noIndex":6},"Was ist neu in Git 2.51.0?","Erfahren Sie mehr über die neuesten Beiträge von GitLabs Git-Team und der Git-Community, einschließlich Performance-Optimierungen für git-push(1) und git-fetch(1), die besonders für deutsche Entwicklungsteams relevant sind.",{"title":802,"description":803,"authors":805,"heroImage":787,"date":807,"body":808,"category":699,"tags":809},[806],"Karthik Nayak","2025-08-18","Das Git-Projekt hat kürzlich [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) veröffentlicht. Aufgrund des Sommers auf der Nordhalbkugel und langsamerer Fortschritte war dieser Release-Zyklus mit 8 Wochen eher kurz (normalerweise dauert ein Release-Zyklus etwa 12 Wochen). \n\n**Die wichtigste Neuerung: Git-Operationen werden bis zu 22-mal schneller** - besonders bei großen Repositories mit vielen Branches profitieren Entwicklungsteams von erheblichen Performance-Verbesserungen.\n\nSchauen wir uns diese und andere bemerkenswerte Änderungen in diesem Release an, einschließlich Beiträgen vom Git-Team bei GitLab und der breiteren Git-Community.\n\n## Massive Performance-Verbesserungen: Von Sekunden zu Millisekunden\n\nGroße Repositories mit tausenden von Branches standen vor einem schmerzhaften Engpass. Git-Operationen, die Referenzen aktualisieren, konnten mehrere Sekunden dauern - ein echter Produktivitätskiller für Teams mit umfangreichen CI/CD-Pipelines oder Monorepo-Workflows.\n\n**Git 2.51.0 ändert alles. Eine 10.000-Referenzen-Fetch-Operation, die 3,4 Sekunden dauerte, wird jetzt in 154 Millisekunden abgeschlossen:**\n\n```\nVORHER: git-fetch mit 10.000 Referenzen\nTime: 3.403 s ± 0.775 s\n\nNACHHER: git-fetch mit 10.000 Referenzen  \nTime: 154.3 ms ± 17.6 ms\n\nERGEBNIS: 22× schneller\n```\n\n**Ähnlich dramatische Verbesserungen bei git-push:**\n\n```\nVORHER: git-push mit 10.000 Referenzen\nTime: 4.276 s ± 0.078 s\n\nNACHHER: git-push mit 10.000 Referenzen\nTime: 235.4 ms ± 6.9 ms\n\nERGEBNIS: 18× schneller\n```\n\n### Wie wurde das erreicht?\n\nDas Problem lag in der Art, wie Git Referenz-Transaktionen behandelte. Die Kommandos git-push(1) und git-fetch(1) erstellten eine separate Transaktion für jedes Referenz-Update, was enormen Overhead verursachte - jede Transaktion benötigte eine Initialisierungs- und Abbauphase und löste Auto-Komprimierungen aus.\n\nGit 2.51.0 verwendet nun **gebündelte Updates**: Mehrere Referenzen werden in einer einzigen Transaktion aktualisiert, während einzelne Updates weiterhin fehlschlagen dürfen. Dies eliminiert den Overhead und skaliert linear mit der Anzahl der Referenzen.\n\nDas Beste daran? Benutzer profitieren automatisch von diesen Verbesserungen, ohne Änderungen an ihrem Workflow vornehmen zu müssen.\n\nDieses [Projekt](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Änderungen in Richtung Git 3.0\n\nVor 11 Jahren wurde Git 2.0 veröffentlicht, die letzte große Versionsfreigabe von Git. Obwohl wir keinen spezifischen Zeitplan für die nächste große Git-Veröffentlichung haben, enthält dieses Release Entscheidungen, die in Richtung Git 3.0 getroffen wurden.\n\nDie Git 3.0-Release-Planung ermöglicht es uns, Breaking Changes zu planen und zu implementieren und diese der erweiterten Git-Community zu kommunizieren. Neben der Dokumentation kann Git auch mit diesen Breaking Changes kompiliert werden für diejenigen, die mit diesen Änderungen experimentieren möchten. Weitere Informationen finden Sie im [BreakingChanges-Dokument](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc).\n\nDas Git 2.51.0-Release bringt einige bedeutende Änderungen in Richtung Git 3.0.\n\n### \"reftable\" wird Standard in Git 3.0\n\nIm [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads)-Release wurde das \"reftable\"-Format als neues Backend zur Speicherung von Referenzen wie Branches oder Tags in Git eingeführt, das viele der Probleme des bestehenden \"files\"-Backends behebt. Lesen Sie unseren [Einsteiger-Leitfaden zur Funktionsweise von reftables](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) für weitere Einblicke in das \"reftable\"-Backend.\n\nDas Git 2.51.0-Release markiert den Wechsel zur Verwendung des \"reftable\"-Formats als Standard in Git 3.0 für neu erstellte Repositories und verdrahtet die Änderung hinter einem Feature-Flag. Das \"reftable\"-Format bietet folgende Verbesserungen gegenüber dem traditionellen \"files\"-Backend:\n\n* Es ist unmöglich, zwei Referenzen zu speichern, die sich nur in der Groß-/Kleinschreibung unterscheiden, auf case-insensitiven Dateisystemen mit dem \"files\"-Format. Dieses Problem ist häufig auf Windows- und macOS-Plattformen. Da das \"reftable\"-Backend keine Dateisystem-Pfade zur Kodierung von Referenznamen verwendet, verschwindet dieses Problem.\n\n* Ebenso normalisiert macOS Pfadnamen, die Unicode-Zeichen enthalten, was zur Folge hat, dass Sie nicht zwei Namen mit Unicode-Zeichen speichern können, die unterschiedlich kodiert sind, mit dem \"files\"-Backend. Auch dies ist kein Problem mit dem \"reftable\"-Backend.\n\n* Das Löschen von Referenzen mit dem \"files\"-Backend erfordert, dass Git die komplette \"packed-refs\"-Datei neu schreibt. In großen Repositories mit vielen Referenzen kann diese Datei leicht dutzende Megabytes groß sein; in extremen Fällen kann sie Gigabytes umfassen. Das \"reftable\"-Backend verwendet Tombstone-Marker für gelöschte Referenzen und muss daher nicht alle seine Daten neu schreiben.\n\n* Repository-Hauskeeping mit dem \"files\"-Backend führt normalerweise All-into-One-Repacks von Referenzen durch. Dies kann sehr teuer sein, und folglich ist Housekeeping ein Kompromiss zwischen der Anzahl loser Referenzen, die sich ansammeln und Operationen verlangsamen, die Referenzen lesen, und der Komprimierung dieser losen Referenzen in die \"packed-refs\"-Datei. Das \"reftable\"-Backend verwendet geometrische Komprimierung nach jedem Schreibvorgang, was Kosten amortisiert und sicherstellt, dass das Backend immer in einem gut gewarteten Zustand ist.\n\n* Operationen, die mehrere Referenzen auf einmal schreiben, sind nicht atomisch mit dem \"files\"-Backend. Folglich kann Git Zwischenzustände sehen, wenn es Referenzen liest, während eine Referenz-Transaktion gerade auf die Festplatte committed wird.\n\n* Das Schreiben vieler Referenzen auf einmal ist langsam mit dem \"files\"-Backend, weil jede Referenz als separate Datei erstellt wird. Das \"reftable\"-Backend übertrifft das \"files\"-Backend um mehrere Größenordnungen.\n\n* Das \"reftable\"-Backend verwendet ein Binärformat mit Präfix-Komprimierung für Referenznamen. Als Resultat nutzt das Format weniger Platz im Vergleich zur \"packed-refs\"-Datei.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n### SHA-256 wird Standard in Git 3.0\n\nDas Git-Versionskontrollsystem speichert Objekte in einem inhaltsadressierbaren Dateisystem. Das bedeutet, es verwendet den Hash eines Objekts zur Adressierung von Inhalten wie Dateien, Verzeichnissen und Revisionen, anders als traditionelle Dateisysteme, die sequenzielle Nummern verwenden. Die Verwendung einer Hash-Funktion hat folgende Vorteile:\n\n* Einfache Integritätsprüfungen, da ein einzelner Bit-Flip die Hash-Ausgabe komplett verändern würde.\n* Schnelle Objektsuche, da Objekte nach ihrem Hash indexiert werden können.\n* Objektnamen können signiert werden und Drittparteien können dem Hash vertrauen, um das signierte Objekt und alle Objekte, auf die es verweist, zu adressieren.\n* Kommunikation über Git-Protokoll und Out-of-Band-Kommunikationsmethoden haben einen kurzen zuverlässigen String, der zur zuverlässigen Adressierung gespeicherter Inhalte verwendet werden kann.\n\nSeit seiner Entstehung hat Git den SHA-1-Hashing-Algorithmus verwendet. Sicherheitsforscher haben jedoch einige Schwachstellen in SHA-1 entdeckt, speziell den [SHAttered-Angriff](https://shattered.io), der eine praktische SHA-1-Hash-Kollision zeigt. Wir sind seit Git 2.13.0 standardmäßig zu einer gehärteten SHA-1-Implementierung übergegangen. SHA-1 ist jedoch immer noch ein schwacher Hashing-Algorithmus und es ist nur eine Frage der Zeit, bis zusätzliche Angriffe seine Sicherheit weiter reduzieren werden.\n\nSHA-256 wurde Ende 2018 als Nachfolger von SHA-1 identifiziert. Git 2.51.0 markiert es als Standard-Hash-Algorithmus für Git 3.0.\n\nDieses Projekt wurde von [brian m. carlson](https://github.com/bk2204) geleitet.\n\n### Entfernung von git-whatchanged(1)\n\nDer git-whatchanged(1)-Befehl zeigt Logs mit Unterschieden, die jeder Commit einführt. Obwohl dies nun von git log --raw abgelöst wurde, wurde der Befehl aus historischen Gründen beibehalten.\n\nGit 2.51.0 erfordert, dass Benutzer des Befehls explizit das --i-still-use-this-Flag verwenden, um alle Benutzer zu erfassen, die noch den veralteten Befehl verwenden, und markiert den Befehl auch für die Entfernung in Git 3.0.\n\nDieses Projekt wurde von [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano) geleitet.\n\n## git switch und git restore sind nicht mehr experimentell\n\nDer git-checkout(1)-Befehl kann für mehrere verschiedene Anwendungsfälle verwendet werden. Er kann zum Wechseln von Referenzen verwendet werden:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git checkout next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nOder zur Wiederherstellung von Dateien:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git checkout git.c\n1 Pfad von Index aktualisiert\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nFür neue Git-Benutzer kann dies zu viel Verwirrung führen. In Git 2.33.0 wurden diese in zwei neue Befehle aufgeteilt: git-switch(1) und git-restore(1).\n\nDer git-switch(1)-Befehl ermöglicht es Benutzern, zu einem bestimmten Branch zu wechseln:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git switch next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nUnd der git-restore(1)-Befehl ermöglicht es Benutzern, Working-Tree-Dateien wiederherzustellen:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nObwohl die beiden Befehle seit 2019 existieren, wurden sie als experimentell markiert. Der Effekt ist, dass das Git-Projekt keine Rückwärtskompatibilität für diese Befehle garantiert: das Verhalten kann sich jederzeit ändern. Obwohl die Absicht ursprünglich war, diese Befehle nach einigen Releases zu stabilisieren, ist das bis zu diesem Punkt nicht geschehen.\n\nDies hat zu mehreren Diskussionen auf der Git-Mailing-Liste geführt, wo Benutzer unsicher sind, ob sie diese neuen Befehle verwenden können oder ob sie eventuell wieder verschwinden. Da jedoch keine bedeutenden Änderungen vorgeschlagen wurden und einige Benutzer diese Befehle bereits verwenden, haben wir beschlossen, sie in Git 2.51 nicht mehr als experimentell zu deklarieren.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## git for-each-ref(1) erhält Paginierungs-Unterstützung\n\nDer git for-each-ref-Befehl wird verwendet, um alle im Repository vorhandenen Referenzen aufzulisten. Als Teil der Plumbing-Schicht von Git wird dieser Befehl häufig beispielsweise von Hosting-Forges verwendet, um Referenzen, die im Repository existieren, in ihrer UI aufzulisten. Aber während Repositories wachsen, wird es weniger realistisch, alle Referenzen auf einmal aufzulisten – schließlich können die größten Repositories Millionen davon enthalten! Stattdessen neigen Forges dazu, die Referenzen zu paginieren.\n\nDies zeigt eine wichtige Lücke auf: git-for-each-ref weiß nicht, Referenzen von vorherigen Seiten zu überspringen, die bereits gezeigt wurden. Folglich muss es möglicherweise eine große Anzahl uninteressanter Referenzen auflisten, bevor es endlich beginnt, die für die aktuelle Seite benötigten Referenzen zu liefern. Dies ist ineffizient und führt zu höherer als notwendiger Latenz oder sogar Timeouts.\n\nGit 2.51.0 unterstützt ein neues --start-after-Flag für git for-each-ref, das die Paginierung der Ausgabe ermöglicht. Dies kann auch mit dem --count-Flag kombiniert werden, um über einen Batch von Referenzen zu iterieren.\n\n```\n$ git for-each-ref --count=10\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Fazit\n\n**Diese Performance-Verbesserungen sind besonders relevant für deutsche Entwicklungsteams, die mit großen Repositories und intensiven CI/CD-Workflows arbeiten.** Die 22-fache Beschleunigung bei git-fetch kann erhebliche Zeitersparnisse in der täglichen Entwicklungsarbeit bedeuten.\n\nBereit, diese Verbeszerungen zu erleben? Aktualisieren Sie auf Git 2.51.0 und beginnen Sie, git switch und git restore in Ihrem täglichen Workflow zu verwenden.\n\nFür GitLab-Benutzer werden diese Performance-Verbesserungen automatisch Ihre Entwicklungserfahrung verbessern, sobald Ihre Git-Version aktualisiert wird.\n\nErfahren Sie mehr in den [offiziellen Git 2.51.0 Release Notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) und erkunden Sie unser [komplettes Archiv der Git-Entwicklungsberichterstattung](https://about.gitlab.com/blog/tags/git/).\n\n---\n\n*Für vollständige technische Details, Benchmarks und Implementierungshinweise lesen Sie den [englischen Originalartikel](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/).*\n",[791,727,9,810],"performance",{"featured":6,"template":679,"slug":812},"what-s-new-in-git-2-51-0","content:de-de:blog:what-s-new-in-git-2-51-0.yml","What S New In Git 2 51 0","de-de/blog/what-s-new-in-git-2-51-0.yml","de-de/blog/what-s-new-in-git-2-51-0",{"_path":818,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":819,"content":824,"config":830,"_id":832,"_type":13,"title":833,"_source":15,"_file":834,"_stem":835,"_extension":18},"/de-de/blog/whats-new-in-git-2-45-0",{"title":820,"description":821,"ogTitle":820,"ogDescription":821,"noIndex":6,"ogImage":760,"ogUrl":822,"ogSiteName":691,"ogType":692,"canonicalUrls":822,"schema":823},"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://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":820,"description":821,"authors":825,"heroImage":760,"date":827,"body":828,"category":699,"tags":829},[826],"Patrick Steinhardt","2024-04-30","Das Git-Projekt hat kürzlich [Git-Version\n2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Git Version\n2.45.0\") veröffentlicht. Werfen wir einen Blick auf die Highlights dieser\nVersion, die Beiträge des Git-Teams von GitLab und der gesamten\nGit-Community enthält.\n\n\n## Reftables: Ein neues Backend zum Speichern von Referenzen\n\n\nJedes Git-Repository muss zwei grundlegende Datenstrukturen erfassen:\n\n\n- Den Objektgraphen, der die Daten deiner Dateien, die Verzeichnisstruktur,\nCommit-Nachrichten und Tags speichert.\n\n- Referenzen, die auf diesen Objektgraphen verweisen, um bestimmte Objekte\nmit einem leichter verständlichen Namen zu verknüpfen. Ein Branch ist zum\nBeispiel eine Referenz, deren Name mit dem Präfix `refs/heads/` beginnt.\n\n\nDas Format, in dem Referenzen in einem Repository auf der Festplatte\ngespeichert werden, ist seit der Einführung von Git weitgehend unverändert\ngeblieben und wird als „files“-Format bezeichnet. Jedes Mal, wenn du eine\nReferenz erstellst, legt Git eine sogenannte „lose Referenz“ an. Das ist\neine einfache Datei in deinem Git-Repository, deren Pfad mit dem Namen der\nReferenz übereinstimmt. Zum Beispiel:\n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Das Updaten einer Referenz veranlasst Git dazu, eine “lose Referenz”\n\n# zu erstellen. Diese lose Referenz ist eine einfache Datei, welche die\n\n# Objekt-ID des Commits enthält.\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) c70f266] Initial commit\n\n$ cat .git/refs/heads/main\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n# Wenn man eine zweite Referenz erstellt, wird diese als zweite lose\n\n# Referenz gespeichert.\n\n$ git branch feature\n\n$ cat .git/refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946\n\n$ tree .git/refs\n\n.git/refs/\n\n├── heads\n\n│   ├── feature\n\n│   └── main\n\n└── tags\n\n\n3 directories, 2 files\n\n```\n\nVon Zeit zu Zeit packt Git diese Referenzen in ein „gepacktes“ Dateiformat,\ndamit es effizienter wird, Referenzen nachzuschlagen. Zum Beispiel:\n\n\n```shell\n\n# Wenn man Referenzen packt, erstellt Git eine “packed-refs” Datei.\n\n# Diese Datei enthält die sortierte Liste von vorher losen Referenzen.\n\n# Die losen Referenzen existieren nicht mehr.\n\n$ git pack-refs --all\n\n$ cat .git/refs/heads/main\n\ncat: .git/refs/heads/main: No such file or directory\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n```\n\nDieses Format ist zwar ziemlich simpel, hat aber Einschränkungen:\n\n\n- In großen Mono-Repos mit vielen Referenzen stießen wir auf Probleme mit\nder Skalierbarkeit. Das Löschen von Referenzen ist besonders ineffizient, da\ndie gesamte „packed-refs“-Datei neu geschrieben werden muss, um die\ngelöschte Referenz zu entfernen. In unseren größten Repositorys kann dies\ndazu führen, dass bei jedem Löschen einer Referenz mehrere Gigabyte an Daten\nneu geschrieben werden müssen.\n\n- Da mehrere Dateien gelesen werden müssen, um alle Referenzen des Repos zu\nermitteln, ist dies atomar nicht möglich. Sobald andere Prozesse existieren,\ndie in das Repo schreiben wollen, kann es dadurch zu Inkonsistenzen kommen.\n\n- Es ist unmöglich, atomar mehrere Referenzen gleichzeitig zu schreiben,\nweil dafür mehrere Dateien erstellt oder aktualisiert werden müssen.\n\n- Das Packen von Referenzen lässt sich nicht gut skalieren, weil die gesamte\n„packed-refs“-Datei neu geschrieben werden muss.\n\n- Da lose Referenzen den Dateisystempfad als Namen verwenden, unterliegen\nsie dem dateisystemspezifischen Verhalten. So können z. B. Dateisysteme, die\nGroß- und Kleinschreibung nicht unterscheiden, keine Referenzen speichern,\nbei denen nur die Groß- und Kleinschreibung unterschiedlich ist.\n\n\nUm diese Probleme zu lösen, wurde mit Git v2.45.0 ein neues\n„reftable“-Backend eingeführt, das ein neues Binärformat zum Speichern von\nReferenzen verwendet. Dieses neue Backend wird schon sehr lange entwickelt:\nes wurde ursprünglich von [Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/ \"Shawn\nPearce\") im Juli 2017 vorgeschlagen und zunächst in\n[JGit](https://www.eclipse.org/jgit/ \"JGit\") implementiert. Das\n[Gerrit-Projekt](https://www.gerritcodereview.com/ \"Gerrit Projekt\") nutzt\nes bereits ausgiebig. Im Jahr 2021 hat [Han-Wen\nNienhuys](https://hanwen.home.xs4all.nl/ \"Han-Wen Nienhuys\") die Bibliothek\nin Git hochgeladen, die es ermöglicht, das reftable-Format zu lesen und zu\nschreiben.\n\n\nDas neue „reftable“-Backend, das wir in Git v2.45.0 hochgeladen haben,\nbringt nun endlich die reftable-Bibliothek und Git zusammen, so dass du das\nneue Format als Speicher-Backend in deinen Git-Repositorys verwenden kannst.\n\n\nWenn du mindestens Git v2.45.0 verwendest, kannst du neue Repositorys mit\ndem „reftable“-Format erstellen, indem du den Schalter\n`--ref-format=reftable` entweder an `git-init(1)` oder an `git-clone(1)`\nübergibst. Zum Beispiel:\n\n\n```shell\n\n$ git init --ref-format=reftable .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/tables.list\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n.git/reftable/tables.list\n\n```\n\nWie du siehst, werden die Referenzen jetzt im Verzeichnis `.git/reftable`\nstatt in `.git/refs` gespeichert. Die Referenzen und die Reflogs werden in\n„tables“ gespeichert. Das sind die Dateien, die auf `.ref` enden. Die Datei\n`tables.list` enthält die Liste aller derzeit aktiven Tabellen. Die\ntechnischen Details rund um die Funktionsweise werden wir in einem separaten\nBlogbeitrag erklären. Bleib dran!\n\n\nDas „reftable“-Backend ist als vollwertiger Ersatz für das „files“-Backend\ngedacht. Aus der Sicht der Benutzer(innen) sollte also alles gleich\nfunktionieren.\n\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Patrick Steinhardt\") geleitet. Dank gebührt auch Shawn Pearce, dem Erfinder\ndes Formats, und Han-Wen Nienhuys, dem Autor der reftable-Bibliothek.\n\n\n## Bessere Tools für Referenzen \n\n\nDas Format „reftable“ löst zwar viele der Probleme, die wir haben, es bringt\nallerdings auch einige neue Probleme mit sich. Eines der wichtigsten\nProbleme ist die Zugänglichkeit der darin enthaltenen Daten.\n\n\nMit dem „files“-Backend kannst du im schlimmsten Fall deine normalen\nUnix-Tools verwenden, um den Zustand der Referenzen zu überprüfen. Sowohl\ndie „gepackten“ als auch die „losen“ Referenzen enthalten menschenlesbare\nDaten, die man leicht verstehen kann. Das ist beim „reftable“-Format anders,\nda es sich um ein Binärformat handelt. Daher muss Git alle notwendigen Tools\nbereitstellen, um Daten aus dem neuen „reftable“-Format zu extrahieren.\n\n\n### Auflisten aller Referenzen\n\n\nDas erste Problem bestand darin, dass es im Grunde unmöglich ist, alle\nReferenzen zu ermitteln, die ein Repository kennt. Das ist zunächst etwas\nrätselhaft: Du kannst über Git Referenzen erstellen und ändern, aber es kann\nnicht alle Referenzen auflisten, die es kennt?\n\n\nWährend es problemlos alle „normalen“ Referenzen auflisten kann, die mit dem\nPräfix `refs/` beginnen, verwendet Git auch sogenannte Pseudo-Referenzen.\nDiese Dateien befinden sich direkt im Stammverzeichnis des\nGit-Verzeichnisses und wären zum Beispiel Dateien wie `.git/MERGE_HEAD`. Das\nProblem dabei ist, dass diese Pseudo-Referenzen neben anderen Dateien\nliegen, die Git speichert, wie z. B. `.git/config`.\n\n\nWährend einige Pseudo-Referenzen bekannt und daher leicht zu identifizieren\nsind, gibt es theoretisch keine Grenzen dafür, welche Referenzen Git\nschreiben kann. Nichts hält dich davon ab, eine Referenz mit dem Namen\n„foobar“ zu erstellen.\n\n\nZum Beispiel:\n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\nDas Problem des „files“-Backends ist, dass es Referenzen nur aufzählen kann,\nindem es Verzeichnisse durchsucht. Um herauszufinden, dass es sich bei\n`.git/foobar` tatsächlich um eine Referenz handelt, müsste Git die Datei\nöffnen und prüfen, ob sie wie eine Referenz formatiert ist oder nicht.\n\n\nDas „reftable“-Backend hingegen kennt sämtliche Referenzen, die es enthält:\nSie sind in seinen Datenstrukturen kodiert, so dass es lediglich diese\nReferenzen dekodieren und zurückgeben muss. Aufgrund der Einschränkungen des\n„files“-Backends gibt es jedoch kein Tool, mit dem du alle vorhandenen\nReferenzen ermitteln kannst.\n\n\nUm dieses Problem zu lösen, haben wir `git-for-each-ref(1)` mit dem neuen\nFlag `--include-root-refs` ausgestattet, das auch alle Referenzen auflistet,\ndie im Stammverzeichnis der Referenznamen-Hierarchie existieren. Zum\nBeispiel:\n\n\n```shell\n\n$ git for-each-ref --include-root-refs\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n```\n\nFür das „files“-Backend wird dieses neue Flag nach dem Best-Effort-Prinzip\nbehandelt, d.h. es werden alle Referenzen aufgenommen, die mit einem\nbekannten Pseudo-Referenznamen übereinstimmen. Für das „reftable“-Backend\nkönnen wir einfach alle bekannten Referenzen auflisten.\n\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl\n\"Karthik Nayak\") geleitet.\n\n\n### Auflisten aller reflogs\n\n\nJedes Mal, wenn du einen Branch aktualisierst, zeichnet Git diese\nBranch-Aktualisierung standardmäßig in einem sogenannten reflog auf. Dieses\nreflog ermöglicht es dir, Änderungen an diesem Branch rückgängig zu machen,\nfalls du eine unbeabsichtigte Änderung vorgenommen hast, und kann daher sehr\nhilfreich sein.\n\n\nMit dem „files“-Backend werden diese Protokolle in deinem\n`.git/logs`-Verzeichnis gespeichert:\n\n\n```shell\n\n$ find -type f .git/logs/\n\n.git/logs/HEAD\n\n.git/logs/refs/heads/main\n\n```\n\nTatsächlich ist die Auflistung der Dateien in diesem Verzeichnis die einzige\nMöglichkeit, um herauszufinden, welche Referenzen überhaupt ein reflog\nhaben. Dies ist ein Problem für das „reftable“-Backend, das diese Logs\nzusammen mit den Referenzen speichert. Folglich gibt es keine Möglichkeit\nmehr, herauszufinden, welche reflogs im Repository überhaupt existieren,\nwenn du das „reftable“ Format verwendest.\n\n\nDies ist jedoch nicht wirklich die Schuld des „reftable“-Formats, sondern\neine Lücke in den von Git bereitgestellten Tools. Um diese Lücke zu\nschließen, haben wir einen neuen Unterbefehl `list` für `git-reflog(1)`\neingeführt, mit dem du alle vorhandenen reflogs auflisten kannst:\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Patrick Steinhardt\") geleitet.\n\n\n### Effizienteres Packen von Referenzen\n\n\nUm effizient zu bleiben, müssen Git-Repositorys regelmäßig gewartet werden.\nNormalerweise wird diese Wartung durch verschiedene Git-Befehle ausgelöst,\ndie Daten in die Git-Repositorys schreiben, indem sie den Befehl `git\nmaintenance run --auto` ausführen. Dieser Befehl optimiert nur die\nDatenstrukturen, die tatsächlich optimiert werden müssen, damit Git keine\nComputeressourcen verschwendet.\n\n\nEine Datenstruktur, die von der Git-Wartung optimiert wird, ist die\nReferenzdatenbank, die mit dem Befehl `git pack-refs --all` optimiert wird.\nFür das „files“-Backend bedeutet dies, dass alle Referenzen in die\n„packed-refs“-Datei gepackt und die losen Referenzen gelöscht werden,\nwährend für das „reftable“-Backend alle Tabellen in einer einzigen Tabelle\nzusammengefasst werden.\n\n\nIm Hinblick auf das „files“-Backend können wir nicht viel besser vorgehen.\nDa die gesamte „packed-refs“-Datei ohnehin neu geschrieben werden muss, ist\nes sinnvoll, alle losen Referenzen zu packen.\n\n\nFür das „reftable“-Backend ist dies jedoch suboptimal, da sich das\n„reftable“-Backend selbst optimiert. Jedes Mal, wenn Git eine neue Tabelle\nan das „reftable“-Backend anhängt, führt es eine automatische Komprimierung\ndurch und führt die Tabellen nach Bedarf zusammen. Deshalb sollte sich die\nReferenzdatenbank immer in einem gut optimierten Zustand befinden, sodass\ndas Zusammenführen aller Tabellen vergebliche Mühe wäre.\n\n\nIn Git v2.45.0 haben wir daher einen neuen Modus `git pack-refs --auto`\neingeführt, der das Referenz-Backend auffordert, nach Bedarf zu optimieren.\nWährend das „files“-Backend auch bei gesetztem `--auto`-Flag weiterhin\ngleich funktioniert, verwendet das „reftable“-Backend die gleichen\nHeuristiken, die es bereits für seine automatische Komprimierung verwendet.\nIn der Praxis sollte dies in den meisten Fällen kein Problem darstellen.\n\n\nAußerdem wurde `git maintenance run --auto` so angepasst, dass das Flag\n`--auto` an `git-pack-refs(1)` übergeben wird, um diesen neuen Modus\nstandardmäßig zu verwenden.\n\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Patrick Steinhardt\") geleitet. \n\n\n## Weiterlesen\n\n\nIn diesem Blogbeitrag ging es vor allem um das neue „reftable“-Backend, das\nes uns ermöglicht, in großen Repositorys mit vielen Referenzen besser zu\nskalieren, sowie um die zugehörigen Tools, die wir parallel dazu eingeführt\nhaben, damit es gut funktioniert. Natürlich hat die Git-Community mit dieser\nVersion auch verschiedene Leistungsverbesserungen, Fehlerbehebungen und\nkleinere Funktionen eingeführt. Diese kannst du in der [offiziellen\nVersionsankündigung](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/\n\"offiziellen Versionsankündigung\") des Git-Projekts nachlesen.\n",[791,9],{"slug":831,"featured":6,"template":679},"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",{"_path":837,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":838,"content":844,"config":850,"_id":852,"_type":13,"title":853,"_source":15,"_file":854,"_stem":855,"_extension":18},"/de-de/blog/whats-new-in-git-2-46-0",{"title":839,"description":840,"ogTitle":839,"ogDescription":840,"noIndex":6,"ogImage":841,"ogUrl":842,"ogSiteName":691,"ogType":692,"canonicalUrls":842,"schema":843},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","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":839,"description":840,"authors":845,"heroImage":841,"date":846,"body":847,"category":699,"tags":848,"updatedDate":849},[786],"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.",[791,727,9],"2024-08-14",{"slug":851,"featured":90,"template":679},"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":857,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":858,"content":864,"config":870,"_id":872,"_type":13,"title":873,"_source":15,"_file":874,"_stem":875,"_extension":18},"/de-de/blog/whats-new-in-git-2-47-0",{"title":859,"description":860,"ogTitle":859,"ogDescription":860,"noIndex":6,"ogImage":861,"ogUrl":862,"ogSiteName":691,"ogType":692,"canonicalUrls":862,"schema":863},"Was gibt es Neues in Git 2.47.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter neue globale Variablen zum Konfigurieren von Referenz- und Objekt-Hash-Formaten. Entdecke Beträge des Git-Teams von GitLab und der gesamten Git-Community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.47.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":859,"description":860,"authors":865,"heroImage":861,"date":866,"body":867,"category":699,"tags":868,"updatedDate":869},[786],"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/)",[791,727,9],"2024-11-05",{"slug":871,"featured":90,"template":679},"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":877,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":878,"content":883,"config":890,"_id":892,"_type":13,"title":893,"_source":15,"_file":894,"_stem":895,"_extension":18},"/de-de/blog/whats-new-in-git-2-48-0",{"title":879,"description":880,"ogTitle":879,"ogDescription":880,"noIndex":6,"ogImage":861,"ogUrl":881,"ogSiteName":691,"ogType":692,"canonicalUrls":881,"schema":882},"Was gibt es Neues in Git 2.48.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter ein neues Build-System und eine Optimierung im neuen reftables-Backend. Entdecke Beiträge des Git-Teams von GitLab und der Git-Community.","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.48.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }\n                  ",{"title":879,"description":880,"authors":884,"heroImage":861,"date":886,"body":887,"category":699,"tags":888,"updatedDate":889},[885],"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",[791,727,9],"2025-01-20",{"slug":891,"featured":90,"template":679},"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":897,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":898,"content":903,"config":910,"_id":912,"_type":13,"title":913,"_source":15,"_file":914,"_stem":915,"_extension":18},"/de-de/blog/whats-new-in-git-2-49-0",{"title":899,"description":900,"ogTitle":899,"ogDescription":900,"noIndex":6,"ogImage":787,"ogUrl":901,"ogSiteName":691,"ogType":692,"canonicalUrls":901,"schema":902},"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":899,"description":900,"authors":904,"heroImage":787,"date":906,"body":907,"category":699,"tags":908,"updatedDate":909},[905],"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/)",[9,727,791],"2025-04-08",{"slug":911,"featured":90,"template":679},"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":917,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":918,"config":921,"content":923,"_id":932,"_type":13,"title":933,"_source":15,"_file":934,"_stem":935,"_extension":18},"/de-de/blog/docs-site-design-overhaul",{"title":919,"description":920},"Wir haben die GitLab-Dokumentationsseite komplett redesigned","Die Produktdokumentation ist nun sauberer, einfacher zu navigieren und enthält einen Dark Mode.",{"slug":922,"featured":6,"template":679},"docs-site-design-overhaul",{"title":919,"description":924,"authors":925,"heroImage":672,"date":929,"category":674,"tags":930,"body":931},"Erfahre mehr über die Features unserer neu gestalteten Produktdokumentationsseite, die einen einfachen Feedback-Mechanismus und den vielgewünschten Dark Mode bietet.",[926,927,928],"Suzanne Selhorn","Sarah German","Julia Miocene","2025-08-20",[9],"Die GitLab-Dokumentationsseite hat jetzt ein völlig neues Look-and-Feel.\nWas als Anfrage für gezielte Design-Fixes begann, wurde zu einem umfassenden Redesign mit vier wichtigen Verbesserungen:\n\n**Auch und gerade für deutsche Entwicklungsteams:** Diese Verbesserungen machen es einfacher, die englische Dokumentation zu nutzen. Dark Mode und die klarere Navigation helfen dabei, auch bei längeren Sessions die benötigten Informationen zu finden – ohne dass Sprachbarrieren durch schlechte UX verstärkt werden.\n\n## Die vier wichtigsten neuen Features\n\n**Der Dark Mode**: Das meistgewünschte Feature ist endlich da. Du kannst zwischen hellen und dunklen Themes in der oberen rechten Ecke wechseln\nfür bessere Lesbarkeit und weniger Augenbelastung.\n\n**Die Redesigned Navigation**: Wir haben die primäre Navigation nach oben verschoben und die linke Sidebar umstrukturiert, damit unsere 2 300+ Seiten\nweniger überwältigend und besser auffindbar sind.\n\n**Das Simplified Feedback**: Du kannst jetzt Thumbs-up/down-Feedback geben und Kommentare direkt auf jeder Dokumentationsseite hinzufügen.\n\n**Die Technical Debt Fixes**: Dutzende kleiner, aber wirkungsvoller Fixes für Typography, Spacing, Code Blocks und visuelle Inkonsistenzen,\ndie wir über die Jahre gesammelt haben.\n\nDie Brand Alignment mit GitLab's Marketing-Site sorgt außerdem für eine einheitlichere Experience über alle GitLab Properties hinweg.\n\n## Warum jetzt? Das Fundament für Veränderung\n\nAnfang des Jahres hat unser Documentation Engineering Team unter Leitung von Sarah German ein kritisches Replatforming-Projekt durchgeführt\nund von Nanoc zu Hugo migriert. Während diese Änderung für Teams größtenteils unsichtbar war, brachte sie dramatische Performance-Verbesserungen – 130x schnellere lokale Builds\nund 30x schnellere vollständige Builds – und bot die solide technische Grundlage für diese Verbesserungen.\n\nMit diesem Replatforming haben wir die Grundlage geschaffen, die es uns ermöglicht hat, uns auf User Experience-Verbesserungen zu konzentrieren, anstatt mit veralteter Infrastructure zu kämpfen.\n\nSchauen wir uns die Änderungen genauer an.\n\n### Dark Mode\n\nMöglicherweise die größte News für dieses Release: Dark Mode ist jetzt über die gesamte Dokumentationsseite verfügbar.\nDu änderst die Einstellung in der oberen rechten Ecke, und die Site merkt sich deine Präferenz.\nFür viele Teams macht Dark Mode Content einfacher zu lesen und reduziert Eyestrain.\n\n![image of dark mode](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617168/gz45eaygeb0nizf1kwyu.png)\n\n### Redesigned Navigation\n\nWir standen vor der großen Herausforderung, über 2 300 Seiten so zu organisieren, dass Teams nicht überwältigt werden.\nUnsere vorherige einzelne linke Navigation war zwar umfassend, aber schuf eine einschüchternde Experience:\n\n![image of former navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617332/k75fwr3rhjxfjyxmc49d.png)\n\nDer neue Ansatz verschiebt die primäre Navigation nach oben und schafft kürzere, überschaubarere Table-of-Contents-Sections, die sich weniger überwältigend navigieren lassen:\n\n![image of new navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617366/wziabrijury9jl5j7ica.png)\n\nSo zeigen wir die Relationships zwischen Features besser, während einzelne Sections verdaulicher werden.\n\n### Simplified Feedback Mechanism\n\nWir haben den Feedback-Prozess vereinfacht. Anstatt zu verlangen, dass Teams die Docs-Site verlassen und GitLab Issues erstellen,\nkönnen sie jetzt sofortiges Feedback mit Thumbs-up/down-Ratings und Comments direkt auf jeder Page geben.\nScroll einfach auf jeder Dokumentationspage nach unten, um diese neue Functionality in Action zu sehen.\n\n![image of feedback area](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617289/rjocpkmqumacaw7thjqi.png)\n\n### Style Updates und Technical Debt\n\nÜber die Jahre hatten sich kleine Style-Inkonsistenzen angesammelt – inkonsistente Padding in Lists, zusätzliche Spacing um Alerts und verschiedene Typography-Issues.\nDie sehen zwar klein aus, aber zusammen schufen sie eine subtil störende Experience für Daily Users.\n\nUnsere Tabs und Code Blocks haben besondere Aufmerksamkeit bekommen und sind jetzt besser definiert.\n\nVorher sahen Tabs mit Code so aus:\n\n![image of old tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617460/jsa2gz3b2slqu0udrg28.png)\n\nUnd jetzt, mit ein paar kleinen Tweaks, sehen sie so aus:\n\n![image of new tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617493/jpxiybvnadsex39lyawu.png)\n\nDiese Papercut-Fixes sind einzeln klein, aber zusammen schaffen sie eine viel poliertere, professionellere Experience.\n\n## Was kommt als nächstes?\n\nDieses Redesign zeigt, wie wir bei GitLab iterieren – wir shippen meaningful Improvements und bauen gleichzeitig für eine noch bessere Zukunft.\nWir erwarten, die Struktur weiter zu verfeinern und Features hinzuzufügen, die Teams helfen, leichter zu finden, was sie brauchen.\n\nUser Feedback wird unsere nächsten Iterationen antreiben, und mit unserem neuen simplified Feedback Mechanism\nsind wir besser positioniert denn je, direkt von unseren Documentation-Teams zu hören.\n\n## Das Team\n\nDas ganze Team hat an dieser Transformation gearbeitet. Kudos an UX Papercuts und Julia Miocene dafür,\naus einer einfachen Anfrage eine umfassende Design Vision zu machen. Thanks an die Engineers im Technical Writing:\nSarah German, Pearl Latteier und Hiru Fernando, die diese Designs zum Leben erweckt haben.\n\nDas neue Design balanciert Information Density mit Visual Clarity, modernisiert unsere Site unter Beibehaltung\nvon Usability- und Accessibility-Standards und ist ein großer Schritt nach vorn in User Experience und Visual Design.\n","content:de-de:blog:docs-site-design-overhaul.yml","Docs Site Design Overhaul","de-de/blog/docs-site-design-overhaul.yml","de-de/blog/docs-site-design-overhaul",2,[663,684,711,735,755,778,798,817,836],1758326276775]