[{"data":1,"prerenderedAt":1084},["ShallowReactive",2],{"/fr-fr/blog/categories/open-source/":3,"navigation-fr-fr":22,"banner-fr-fr":443,"footer-fr-fr":456,"open-source-category-page-fr-fr":667},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/fr-fr/blog/categories/open-source","categories",false,"",{"title":9,"description":10},"Open source","Browse articles related to Open source on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","open-source","content:fr-fr:blog:categories:open-source.yml","yaml","Open Source","content","fr-fr/blog/categories/open-source.yml","fr-fr/blog/categories/open-source","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":439,"_type":16,"title":440,"_source":18,"_file":441,"_stem":442,"_extension":21},"/shared/fr-fr/main-navigation","fr-fr",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":380,"minimal":416,"duo":430},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/fr-fr/","gitlab logo","header",{"text":32,"config":33},"Commencer un essai gratuit",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Contacter l'équipe commerciale",{"href":39,"dataGaName":40,"dataGaLocation":30},"/fr-fr/sales/","sales",{"text":42,"config":43},"Connexion",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,190,195,301,361],{"text":48,"config":49,"cards":51,"footer":74},"Plateforme",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":55,"config":56},"Découvrir notre plateforme",{"href":57,"dataGaName":50,"dataGaLocation":30},"/fr-fr/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":62,"config":63},"Découvrez GitLab Duo",{"href":64,"dataGaName":65,"dataGaLocation":30},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":70,"config":71},"En savoir plus",{"href":72,"dataGaName":73,"dataGaLocation":30},"/fr-fr/why-gitlab/","why gitlab",{"title":75,"items":76},"Démarrer avec",[77,82,87],{"text":78,"config":79},"Ingénierie de plateforme",{"href":80,"dataGaName":81,"dataGaLocation":30},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Expérience développeur",{"href":85,"dataGaName":86,"dataGaLocation":30},"/fr-fr/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":172},"Produit",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Voir toutes les solutions",{"href":99,"dataGaName":95,"dataGaLocation":30},"/fr-fr/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/fr-fr/solutions/continuous-integration/",{"text":115,"config":116},"Développement assisté par l'IA",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"Gestion du code source",{"href":121,"dataGaLocation":30,"dataGaName":122},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Livraison de logiciels automatisée",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":30,"icon":134},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,141,146],{"text":137,"config":138},"Application Security Testing",{"href":139,"dataGaName":140,"dataGaLocation":30},"/solutions/application-security-testing/","Application security testing",{"text":142,"config":143},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":144,"dataGaLocation":30,"dataGaName":145},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":147,"config":148},"Software Compliance",{"href":149,"dataGaName":147,"dataGaLocation":30},"/solutions/software-compliance/",{"title":151,"link":152,"items":157},"Mesures",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":30},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Visibilité et mesures",{"href":155,"dataGaLocation":30,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Gestion de la chaîne de valeur",{"href":165,"dataGaLocation":30,"dataGaName":166},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Données d'analyse et informations clés",{"href":170,"dataGaLocation":30,"dataGaName":171},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab pour",[175,180,185],{"text":176,"config":177},"Entreprises",{"href":178,"dataGaLocation":30,"dataGaName":179},"/fr-fr/enterprise/","enterprise",{"text":181,"config":182},"PME",{"href":183,"dataGaLocation":30,"dataGaName":184},"/fr-fr/small-business/","small business",{"text":186,"config":187},"Secteur public",{"href":188,"dataGaLocation":30,"dataGaName":189},"/fr-fr/solutions/public-sector/","public sector",{"text":191,"config":192},"Tarifs",{"href":193,"dataGaName":194,"dataGaLocation":30,"dataNavLevelOne":194},"/fr-fr/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"Ressources",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Afficher toutes les ressources",{"href":202,"dataGaName":198,"dataGaLocation":30},"/fr-fr/resources/",[204,237,260],{"title":205,"items":206},"Premiers pas",[207,212,217,222,227,232],{"text":208,"config":209},"Installation",{"href":210,"dataGaName":211,"dataGaLocation":30},"/fr-fr/install/","install",{"text":213,"config":214},"Guides de démarrage rapide",{"href":215,"dataGaName":216,"dataGaLocation":30},"/fr-fr/get-started/","quick setup checklists",{"text":218,"config":219},"Apprentissage",{"href":220,"dataGaLocation":30,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Documentation sur le produit",{"href":225,"dataGaName":226,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Vidéos sur les bonnes pratiques",{"href":230,"dataGaName":231,"dataGaLocation":30},"/fr-fr/getting-started-videos/","best practice videos",{"text":233,"config":234},"Intégrations",{"href":235,"dataGaName":236,"dataGaLocation":30},"/fr-fr/integrations/","integrations",{"title":238,"items":239},"Découvrir",[240,245,250,255],{"text":241,"config":242},"Histoires de succès client",{"href":243,"dataGaName":244,"dataGaLocation":30},"/fr-fr/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":30},"/fr-fr/blog/","blog",{"text":251,"config":252},"Travail à distance",{"href":253,"dataGaName":254,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":30},"/fr-fr/teamops/","teamops",{"title":261,"items":262},"Connecter",[263,268,273,278,283],{"text":264,"config":265},"Services GitLab",{"href":266,"dataGaName":267,"dataGaLocation":30},"/fr-fr/services/","services",{"text":269,"config":270},"Communauté",{"href":271,"dataGaName":272,"dataGaLocation":30},"/community/","community",{"text":274,"config":275},"Forum",{"href":276,"dataGaName":277,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"Événements",{"href":281,"dataGaName":282,"dataGaLocation":30},"/events/","events",{"text":284,"config":285},"Partenaires",{"href":286,"dataGaName":287,"dataGaLocation":30},"/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":293,"config":294},"carte promo The Source",{"src":295},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":297,"config":298},"Lire les articles les plus récents",{"href":299,"dataGaName":300,"dataGaLocation":30},"/fr-fr/the-source/","the source",{"text":302,"config":303,"lists":305},"Société",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"À propos",{"href":311,"dataGaName":312,"dataGaLocation":30},"/fr-fr/company/","about",{"text":314,"config":315,"footerGa":318},"Emplois",{"href":316,"dataGaName":317,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":30},{"text":322,"config":323},"Leadership",{"href":324,"dataGaName":325,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":327,"config":328},"Équipe",{"href":329,"dataGaName":330,"dataGaLocation":30},"/company/team/","team",{"text":332,"config":333},"Manuel",{"href":334,"dataGaName":335,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"Relations avec les investisseurs",{"href":339,"dataGaName":340,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"Centre de confiance",{"href":344,"dataGaName":345,"dataGaLocation":30},"/fr-fr/security/","trust center",{"text":347,"config":348},"Centre pour la transparence de l'IA",{"href":349,"dataGaName":350,"dataGaLocation":30},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"Newsletter",{"href":354,"dataGaName":355,"dataGaLocation":30},"/company/contact/","newsletter",{"text":357,"config":358},"Presse",{"href":359,"dataGaName":360,"dataGaLocation":30},"/press/","press",{"text":362,"config":363,"lists":364},"Nous contacter",{"dataNavLevelOne":304},[365],{"items":366},[367,370,375],{"text":37,"config":368},{"href":39,"dataGaName":369,"dataGaLocation":30},"talk to sales",{"text":371,"config":372},"Aide",{"href":373,"dataGaName":374,"dataGaLocation":30},"/support/","get help",{"text":376,"config":377},"Portail clients GitLab",{"href":378,"dataGaName":379,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":381,"login":382,"suggestions":389},"Fermer",{"text":383,"link":384},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":385,"config":386},"gitlab.com",{"href":44,"dataGaName":387,"dataGaLocation":388},"search login","search",{"text":390,"default":391},"Suggestions",[392,395,400,402,407,412],{"text":59,"config":393},{"href":64,"dataGaName":394,"dataGaLocation":388},"GitLab Duo (AI)",{"text":396,"config":397},"Suggestions de code (IA)",{"href":398,"dataGaName":399,"dataGaLocation":388},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":401},{"href":113,"dataGaName":111,"dataGaLocation":388},{"text":403,"config":404},"GitLab sur AWS",{"href":405,"dataGaName":406,"dataGaLocation":388},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":408,"config":409},"GitLab sur Google Cloud ",{"href":410,"dataGaName":411,"dataGaLocation":388},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":413,"config":414},"Pourquoi utiliser GitLab ?",{"href":72,"dataGaName":415,"dataGaLocation":388},"Why GitLab?",{"freeTrial":417,"mobileIcon":422,"desktopIcon":427},{"text":418,"config":419},"Commencer votre essai gratuit",{"href":420,"dataGaName":35,"dataGaLocation":421},"https://gitlab.com/-/trials/new/","nav",{"altText":423,"config":424},"Icône GitLab",{"src":425,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":423,"config":428},{"src":429,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":431,"mobileIcon":435,"desktopIcon":437},{"text":432,"config":433},"En savoir plus sur GitLab Duo",{"href":64,"dataGaName":434,"dataGaLocation":421},"gitlab duo",{"altText":423,"config":436},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":438},{"src":429,"dataGaName":426,"dataGaLocation":421},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":444,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":445,"titleMobile":445,"button":446,"config":451,"_id":453,"_type":16,"_source":18,"_file":454,"_stem":455,"_extension":21},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":447,"config":448},"Essayer la version bêta",{"href":449,"dataGaName":450,"dataGaLocation":30},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":452},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":457,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":458,"_id":663,"_type":16,"title":664,"_source":18,"_file":665,"_stem":666,"_extension":21},"/shared/fr-fr/main-footer",{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":654},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":461,"config":462},"Afficher le code source de la page",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Modifier cette page",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"Veuillez contribuer",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,559,591,625],{"title":48,"links":483,"subMenu":488},[484],{"text":485,"config":486},"Plateforme DevSecOps",{"href":57,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":191,"links":490},[491,495,500],{"text":492,"config":493},"Voir les forfaits",{"href":193,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Pourquoi choisir GitLab Premium ?",{"href":498,"dataGaName":499,"dataGaLocation":465},"/fr-fr/pricing/premium/","why premium",{"text":501,"config":502},"Pourquoi choisir GitLab Ultimate ?",{"href":503,"dataGaName":504,"dataGaLocation":465},"/fr-fr/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Solutions",[508,513,516,518,523,528,532,535,538,543,545,547,549,554],{"text":509,"config":510},"Transformation digitale",{"href":511,"dataGaName":512,"dataGaLocation":465},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":514,"config":515},"Sécurité et conformité",{"href":139,"dataGaName":140,"dataGaLocation":465},{"text":124,"config":517},{"href":107,"dataGaName":108,"dataGaLocation":465},{"text":519,"config":520},"Développement agile",{"href":521,"dataGaName":522,"dataGaLocation":465},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":524,"config":525},"Transformation cloud",{"href":526,"dataGaName":527,"dataGaLocation":465},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":529,"config":530},"SCM",{"href":121,"dataGaName":531,"dataGaLocation":465},"source code management",{"text":111,"config":533},{"href":113,"dataGaName":534,"dataGaLocation":465},"continuous integration & delivery",{"text":163,"config":536},{"href":165,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/fr-fr/solutions/gitops/","gitops",{"text":176,"config":544},{"href":178,"dataGaName":179,"dataGaLocation":465},{"text":181,"config":546},{"href":183,"dataGaName":184,"dataGaLocation":465},{"text":186,"config":548},{"href":188,"dataGaName":189,"dataGaLocation":465},{"text":550,"config":551},"Formation",{"href":552,"dataGaName":553,"dataGaLocation":465},"/fr-fr/solutions/education/","education",{"text":555,"config":556},"Services financiers",{"href":557,"dataGaName":558,"dataGaLocation":465},"/fr-fr/solutions/finance/","financial services",{"title":196,"links":560},[561,563,565,567,570,572,575,577,579,581,583,585,587,589],{"text":208,"config":562},{"href":210,"dataGaName":211,"dataGaLocation":465},{"text":213,"config":564},{"href":215,"dataGaName":216,"dataGaLocation":465},{"text":218,"config":566},{"href":220,"dataGaName":221,"dataGaLocation":465},{"text":223,"config":568},{"href":225,"dataGaName":569,"dataGaLocation":465},"docs",{"text":246,"config":571},{"href":248,"dataGaName":249},{"text":573,"config":574},"Histoires de réussite client",{"href":243,"dataGaLocation":465},{"text":241,"config":576},{"href":243,"dataGaName":244,"dataGaLocation":465},{"text":251,"config":578},{"href":253,"dataGaName":254,"dataGaLocation":465},{"text":264,"config":580},{"href":266,"dataGaName":267,"dataGaLocation":465},{"text":256,"config":582},{"href":258,"dataGaName":259,"dataGaLocation":465},{"text":269,"config":584},{"href":271,"dataGaName":272,"dataGaLocation":465},{"text":274,"config":586},{"href":276,"dataGaName":277,"dataGaLocation":465},{"text":279,"config":588},{"href":281,"dataGaName":282,"dataGaLocation":465},{"text":284,"config":590},{"href":286,"dataGaName":287,"dataGaLocation":465},{"title":302,"links":592},[593,595,597,599,601,603,605,609,614,616,618,620],{"text":309,"config":594},{"href":311,"dataGaName":304,"dataGaLocation":465},{"text":314,"config":596},{"href":316,"dataGaName":317,"dataGaLocation":465},{"text":322,"config":598},{"href":324,"dataGaName":325,"dataGaLocation":465},{"text":327,"config":600},{"href":329,"dataGaName":330,"dataGaLocation":465},{"text":332,"config":602},{"href":334,"dataGaName":335,"dataGaLocation":465},{"text":337,"config":604},{"href":339,"dataGaName":340,"dataGaLocation":465},{"text":606,"config":607},"Sustainability",{"href":608,"dataGaName":606,"dataGaLocation":465},"/sustainability/",{"text":610,"config":611},"Diversité, inclusion et appartenance (DIB)",{"href":612,"dataGaName":613,"dataGaLocation":465},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":615},{"href":344,"dataGaName":345,"dataGaLocation":465},{"text":352,"config":617},{"href":354,"dataGaName":355,"dataGaLocation":465},{"text":357,"config":619},{"href":359,"dataGaName":360,"dataGaLocation":465},{"text":621,"config":622},"Déclaration de transparence sur l'esclavage moderne",{"href":623,"dataGaName":624,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":362,"links":626},[627,630,632,634,639,644,649],{"text":628,"config":629},"Échanger avec un expert",{"href":39,"dataGaName":40,"dataGaLocation":465},{"text":371,"config":631},{"href":373,"dataGaName":374,"dataGaLocation":465},{"text":376,"config":633},{"href":378,"dataGaName":379,"dataGaLocation":465},{"text":635,"config":636},"Statut",{"href":637,"dataGaName":638,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":640,"config":641},"Conditions d'utilisation",{"href":642,"dataGaName":643},"/terms/","terms of use",{"text":645,"config":646},"Déclaration de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":465},"/fr-fr/privacy/","privacy statement",{"text":650,"config":651},"Préférences en matière de cookies",{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,661],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":465},{"text":659,"config":660},"Politique de confidentialité",{"href":647,"dataGaName":648,"dataGaLocation":465},{"text":650,"config":662},{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":93},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"featuredPost":668,"allPosts":691,"totalPages":1082,"initialPosts":1083},{"_path":669,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":675,"config":684,"_id":687,"_type":16,"title":688,"_source":18,"_file":689,"_stem":690,"_extension":21},"/fr-fr/blog/what-s-new-in-git-2-51-0",{"config":671,"title":672,"ogTitle":672,"description":673,"ogDescription":673,"ogImage":674},{"noIndex":6},"Nouveautés de Git 2.51.0","Découvrez les dernières contributions de l'équipe Git de GitLab et de la communauté Git pour la version Git 2.51.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",{"title":672,"description":676,"authors":677,"heroImage":674,"date":679,"body":680,"category":14,"tags":681},"Découvrez les dernières contributions de l'équipe Git de GitLab et de la communauté Git, notamment les optimisations de performances pour git-push(1) et git-fetch(1).",[678],"Karthik Nayak","2025-08-25","Le projet Git a récemment publié la version [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u). En raison de l'été dans l'hémisphère nord et d'un développement plus lent, ce cycle de sortie de nouvelles versions a été plus court et a duré 8 semaines (au lieu des 12 semaines habituelles). Passons en revue certaines modifications notables de cette version, notamment les contributions de l'équipe Git de GitLab ainsi que de la communauté Git dans son ensemble.\n\n\n## Optimisations des performances pour `git-push(1)` et `git-fetch(1)`\n\n\n\nLes commandes `git-push(1)` et `git-fetch(1)` permettent aux utilisateurs de synchroniser les dépôts locaux et distants. Une partie de ces commandes consiste à mettre à jour les références dans le dépôt, ce qui peut prendre un temps considérable dans les dépôts comportant de nombreuses références, en particulier pour les utilisateurs qui travaillent avec de grands environnements de développement, des monorepos ou des dépôts avec des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu’est-ce qu’un pipeline CI/CD ?\") étendus.\n\n\n\nLes transactions de références Git peuvent inclure plusieurs mises à jour de références, mais elles suivent une approche « tout ou rien ». Si une seule mise à jour dans la transaction échoue, la transaction entière échoue, et aucune des mises à jour de références n'est appliquée. Cependant, les mises à jour de références dans `git-push(1)` et [`git-fetch(1)`](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git Pull et Git Fetch\") sont autorisées à échouer, ce qui permet aux dépôts de synchroniser un sous-ensemble de références même si un sous-ensemble différent a divergé. Pour faciliter ce comportement, Git crée une transaction distincte pour chaque mise à jour de référence afin que certaines transactions réussissent même si d'autres échouent.\n\n\n\nLa création d'une transaction distincte par mise à jour entraîne une surcharge opérationnelle importante, car chaque transaction comprend une phase d'initialisation et de finalisation, et vérifie s'il existe des noms de références contradictoires. Le backend « reftable » effectue également un compactage automatique à la fin de chaque transaction. De multiples transactions peuvent ainsi déclencher plusieurs compactages automatiques, ce qui peut augmenter considérablement la latence de la commande.\n\n\n\nDans Git 2.51.0, ces commandes utilisent désormais des mises à jour par lots au lieu de transactions distinctes afin de mettre à jour plusieurs références dans une seule transaction, tout en autorisant certaines mises à jour à échouer. Cette approche élimine le surcoût lié aux initialisations, vérifications et finalisations répétées et supporte mieux la montée en charge du nombre de références à mettre à jour, puisqu'une seule transaction est utilisée. Les performances du backend « reftable » en sont considérablement améliorées, et ce dernier surpasse désormais le backend « files ». Ces améliorations de performances s'appliquent de manière transparente pour les utilisateurs.\n\n\n\nPour `git-fetch(1)`, nous constatons *des performances 22x meilleures pour le backend « reftable »* et *1,25x meilleures pour le backend « files »* lorsque cette commande est utilisée dans un dépôt avec 10 000 références.\n\n\n\n```\nBenchmark 1: fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      3.403 s ±  0.775 s    [User: 1.875 s, System: 1.417 s]\n  Range (min … max):    2.454 s …  4.529 s    10 runs\n\nBenchmark 2: fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n Time (mean ± σ):     154.3 ms ±  17.6 ms    [User: 102.5 ms, System: 56.1 ms]\n Range (min … max):   145.2 ms … 220.5 ms    18 runs\n\nSummary\n  fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   22.06 ± 5.62 times faster than fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: fetch: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):     605.5 ms ±   9.4 ms    [User: 117.8 ms, System: 483.3 ms]\n  Range (min … max):   595.6 ms … 621.5 ms    10 runs\n\nBenchmark 2: fetch: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     485.8 ms ±   4.3 ms    [User: 91.1 ms, System: 396.7 ms]\n  Range (min … max):   477.6 ms … 494.3 ms    10 runs\n\nSummary\n  fetch: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n   1.25 ± 0.02 times faster than fetch: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\n\nPour `git-push(1)`, nous constatons des *performances 18x meilleures pour le backend reftable* et *1,21x meilleures pour le backend « files »* lorsque cette commande est utilisée dans un dépôt avec 10 000 références.\n\n\n\n```\nBenchmark 1: push: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      4.276 s ±  0.078 s    [User: 0.796 s, System: 3.318 s]\n  Range (min … max):    4.185 s …  4.430 s    10 runs\n\nBenchmark 2: push: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     235.4 ms ±   6.9 ms    [User: 75.4 ms, System: 157.3 ms]\n  Range (min … max):   228.5 ms … 254.2 ms    11 runs\n\nSummary\n  push: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   18.16 ± 0.63 times faster than push: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: push: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):      1.121 s ±  0.021 s    [User: 0.128 s, System: 0.975 s]\n  Range (min … max):    1.097 s …  1.156 s    10 runs\n\nBenchmark 2: push: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     927.9 ms ±  22.6 ms    [User: 99.0 ms, System: 815.2 ms]\n  Range (min … max):   903.1 ms … 978.0 ms    10 runs\n\nSummary\n  push: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.21 ± 0.04 times faster than push: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\n\nCe [projet](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n\n## En route vers la version Git 3.0\n\n\n\nLa dernière version majeure de Git, la version 2.0, a été publiée il y a onze ans déjà. Bien que nous n'ayons pas de calendrier spécifique pour la prochaine version majeure de Git, la version 2.51.0 inclut déjà des décisions concernant Git 3.0.\n\n\n\nLa planification de la version Git 3.0 nous permet de prévoir et d'implémenter des changements rendant cette version incompatible avec les précédentes et de les communiquer à la communauté Git. En plus de la documentation, Git peut également être compilé avec ces changements incompatibles à des fins de test. Pour en savoir plus, consultez le [document BreakingChanges](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc).\n\n\n\nLa version Git 2.51.0 apporte des changements importants en préparation de Git 3.0.\n\n\n\n### Reftable comme backend de références par défaut\n\n\n\nDans la version [Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), le format « reftable » a été introduit comme nouveau backend pour stocker les références comme les branches ou les tags dans Git, afin de corriger de nombreux problèmes avec le backend « files » existant. Consultez notre [guide du débutant sur le fonctionnement du format reftable](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable\") pour obtenir plus d'informations sur le backend « reftable ».\n\n\n\nLa version Git 2.51.0 marque le passage à l'utilisation du format « reftable » par défaut dans Git 3.0 pour les dépôts nouvellement créés et configure également le changement d'un feature flag. Le format « reftable » offre les améliorations suivantes par rapport au backend « files » traditionnel :\n\n\n\n* Il est impossible de stocker deux références avec pour seule différence la casse sur des systèmes de fichiers qui ne tiennent pas compte de la casse avec le format « files ». Ce problème est courant sur les systèmes Windows et macOS. Étant donné que le backend « reftable » n'utilise pas de chemins de système de fichiers pour encoder les noms de références, ce problème n'a plus lieu d'être.\n\n\n* De même, macOS normalise les noms de chemins qui contiennent des caractères unicode. Vous ne pouvez donc pas stocker deux noms avec des caractères unicode qui sont encodés différemment avec le backend « files », mais ce n'est pas un problème avec le backend « reftable ».\n\n\n* La suppression de références avec le backend « files » nécessite que Git réécrive le fichier complet « packed-refs ». Dans les grands dépôts avec de nombreuses références, ce fichier peut facilement faire des dizaines de mégaoctets, voire des gigaoctets. Le backend « reftable » utilise des marqueurs « tombstone » pour les références supprimées et n'a donc pas à réécrire toutes ses données.\n\n\n* La maintenance du dépôt avec le backend « files » effectue généralement des repacks tout-en-un des références. Cette approche peut être assez coûteuse, et par conséquent, la maintenance est un compromis entre le nombre de références seules par fichier qui s'accumulent et ralentissent les opérations qui lisent les références, et la compression de ces références non compactées en un seul fichier « packed-refs ». Le backend « reftable » utilise le compactage géométrique après chaque écriture, ce qui amortit les coûts et garantit que le backend est toujours bien entretenu.\n\n\n* Les opérations qui écrivent plusieurs références à la fois ne sont pas atomiques avec le backend « files ». Par conséquent, [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") peut voir des états intermédiaires lorsqu'il lit des références pendant qu'une transaction de référence est en cours de validation sur le disque.\n\n\n* L'écriture de nombreuses références à la fois est un processus lent avec le backend « files », car chaque référence est créée en tant que fichier séparé. Le backend « reftable » fournit des résultats considérablement meilleurs par rapport au backend « files ».\n\n\n* Le backend « reftable » utilise un format binaire avec compression de préfixe pour les noms de références. En conséquence, le format utilise moins d'espace par rapport au fichier « packed-refs ».\n\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n\n### SHA-256 comme fonction de hachage par défaut\n\n\n\nLe système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") Git stocke les objets dans un système de fichiers adressable par contenu. Cela signifie qu'il utilise le hachage d'un objet pour adresser le contenu tel que les fichiers, les répertoires et les révisions, contrairement aux systèmes de fichiers traditionnels, qui utilisent des nombres séquentiels. L'utilisation d'une fonction de hachage présente les avantages suivants :\n\n\n\n* Vérifications faciles de l'intégrité, car un seul bit inversé modifierait complètement le résultat du hachage.\n\n\n* Recherche d'objets rapide, car ces derniers peuvent être indexés par leur hachage.\n\n\n* Les noms d'objets peuvent être signés, et des tiers peuvent faire confiance au hachage pour adresser l'objet signé et tous les objets qu'il référence.\n\n\n* La communication via le protocole Git et les méthodes de communication hors bande disposent d'une chaîne de caractères courte et fiable qui peut être utilisée pour adresser de manière fiable le contenu stocké.\n\n\n\nDepuis sa création, Git a utilisé l'algorithme de hachage SHA-1. Cependant, des chercheurs en sécurité ont découvert quelques failles dans cet algorithme, en particulier l'[attaque SHAttered](https://shattered.io), qui montre une collision de hachage SHA-1 réalisable en pratique. Nous sommes passés à l'utilisation d'une implémentation SHA-1 renforcée par défaut depuis Git 2.13.0. Cependant, SHA-1 reste un algorithme de hachage faible, et ce n'est qu'une question de temps avant que des attaques supplémentaires ne diminuent encore davantage sa sécurité.\n\n\n\nSHA-256 a été identifié comme le successeur de SHA-1 fin 2018. Git 2.51.0 le marque comme l'algorithme de hachage par défaut à utiliser dans Git 3.0.\n\n\n\nCe projet a été mené par [brian m. carlson](https://github.com/bk2204).\n\n\n\n### Suppression de `git-whatchanged(1)`\n\n\n\nLa commande `git-whatchanged(1)` montre les logs avec les différences que chaque commit introduit. Bien que cette commande soit maintenant remplacée par `git log --raw`, elle a été conservée pour des raisons historiques.\n\n\n\nGit 2.51.0 oblige les utilisateurs de la commande à utiliser explicitement le flag `--i-still-use-this` pour identifier tous les utilisateurs qui utilisent encore cette commande dépréciée, et marque également la commande pour suppression dans Git 3.0.\n\n\n\nCe projet a été mené par [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano).\n\n\n\n## `git switch` et `git restore` ne sont plus en phase expérimentale\n\n\n\nLa commande `git-checkout(1)` peut être utilisée dans plusieurs cas d'utilisation différents. Elle peut être utilisée pour changer la référence courante :\n\n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git checkout next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\n\nOu pour restaurer des fichiers :\n\n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git checkout git.c\nUpdated 1 path from the index\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n```\n\n\n\nPour les nouveaux utilisateurs de Git, ces différentes possibilités peuvent être source de confusion. Dans Git 2.33.0, elles ont été divisées en deux nouvelles commandes, `git-switch(1)` et `git-restore(1)`.\n\n\n\nLa commande `git-switch(1)` permet aux utilisateurs de basculer vers une branche spécifique :\n\n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git switch next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\n\nEt la commande `git-restore(1)` permet aux utilisateurs de restaurer les fichiers de l'arbre de travail :\n\n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n```\n\n\n\nCes deux commandes existent depuis 2019, mais étaient en phase expérimentale. Ce qui signifie que le projet Git ne garantissait pas la compatibilité avec les versions précédentes pour ces commandes, et le comportement pouvait changer à tout moment. L'objectif était initialement de stabiliser ces commandes après quelques nouvelles versions, mais cela n'a pas été le cas jusqu'à présent.\n\n\n\nCela a entraîné plusieurs discussions sur la liste de diffusion Git, où les utilisateurs se demandaient s'ils pouvaient commencer à utiliser ces nouvelles commandes, ou si celles-ci pourraient éventuellement disparaître à nouveau. Mais étant donné qu'aucun changement significatif n'a été proposé, et que certains utilisateurs utilisent déjà ces commandes, nous avons décidé de les retirer de leur phase expérimentale dans la version Git 2.51.\n\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n\n## Prise en charge de la pagination pour `git for-each-ref(1)`\n\n\n\nLa commande `git for-each-ref` est utilisée pour indiquer toutes les références présentes dans un dépôt. Comme elle fait partie de la couche de plomberie de Git, cette commande est fréquemment utilisée par les forges logicielles d'hébergement pour lister sur leur interface utilisateur les références qui existent dans le dépôt. Mais à mesure que les dépôts grandissent, il n'est pas réaliste de lister toutes les références à la fois, car les plus grands dépôts peuvent en contenir des millions ! À la place, les forges ont tendance à paginer les références.\n\n\n\nUne lacune importante émerge ainsi : `git-for-each-ref` ne sait pas ignorer les références des pages précédentes qui ont déjà été affichées. Par conséquent, cette commande peut devoir lister un grand nombre de références sans intérêt avant de commencer à indiquer les références requises pour la page actuelle. Ce processus est peu efficace et conduit à une latence plus élevée que nécessaire ou même à des délais d'attente dépassés.\n\n\n\nGit 2.51.0 prend en charge une nouvelle option `--start-after` pour `git for-each-ref`, qui permet de paginer les données de sortie. Il est aussi possible de la combiner avec l'option `--count` pour itérer sur un lot de références.\n\n\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\n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n\n## Perspectives\n\n\n\nPrêt à découvrir ces améliorations ? Mettez à jour votre version Git et commencez à utiliser `git switch` et `git restore` dans vos workflows quotidiens.\n\n\n\nPour les utilisateurs de GitLab, ces améliorations de performances enrichiront automatiquement l'expérience de développement une fois la version de Git mise à jour.\n\n\n\nPour en savoir plus, consultez les [notes de version officielles de Git 2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) et explorez notre [archive complète de le développement de Git](https://about.gitlab.com/fr-fr/blog/tags/git/).\n",[682,683,272],"git","open source",{"featured":6,"template":685,"slug":686},"BlogPost","what-s-new-in-git-2-51-0","content:fr-fr:blog:what-s-new-in-git-2-51-0.yml","What S New In Git 2 51 0","fr-fr/blog/what-s-new-in-git-2-51-0.yml","fr-fr/blog/what-s-new-in-git-2-51-0",[692,713,733,757,778,798,819,842,863,884,906,925,945,964,984,1006,1024,1043,1064],{"_path":693,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":698,"config":707,"_id":709,"_type":16,"title":710,"_source":18,"_file":711,"_stem":712,"_extension":21},"/fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":695,"description":696,"ogDescription":696,"ogTitle":695,"ogImage":697},"Développer les communautés open source avec GitLab","Découvrez comment utiliser la plateforme DevSecOps de GitLab pour résoudre les problèmes d'intégration des nouveaux contributeurs.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_820,h_500,c_lfill/v1750099558/Blog/Hero%20Images/gitlabflatlogomap.png",{"description":696,"title":699,"category":14,"tags":700,"heroImage":697,"date":702,"body":703,"authors":704},"Comment nous utilisons GitLab pour développer les communautés open source",[683,272,701],"product","2025-07-22","L'équipe Contributor Success de GitLab faisait face au défi suivant : alors\nque nos contributeurs open source récurrents fusionnaient davantage de\nmodifications de code et collaboraient sur des fonctionnalités avancées, les\ncontributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions\nconscients que beaucoup de nouveaux contributeurs open source finissaient\npar abandonner sans même demander de l'aide. Attachés à la [mission de\nGitLab](https://handbook.gitlab.com/handbook/company/mission/) où chacun\npeut contribuer, nous aspirions à inverser cette tendance.\n\n\nNous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.\n\n\nTrois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.\n\n\nVoici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\").\n\n\n## Ce que nous avons appris sur les nouveaux contributeurs\n\n\nEn 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.\n\n\nVoici ce qu’ils nous ont dit : \n\n\n* La documentation destinée aux contributeurs était confuse\n\n* La prise en main était difficile \n\n* Trouver de l’aide n'était pas clair\n\n\nSeul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.\n\n\nIl est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc [itéré](https://handbook.gitlab.com/handbook/values/#iteration) !\n\n\nNotre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.\n\n\nEn 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.\n\n\n## Création d’une intégration personnalisée\n\n\nNotre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.\n\n\nNous avons créé un [template de ticket ](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md)avec une liste claire de tâches.\n\n\nLe ticket d'intégration gère également l'approbation d'accès aux [forks de la communauté de GitLab](https://about.gitlab.com/blog/gitlab-community-forks/), une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.\n\n\nEn utilisant des [labels à portée limitée](https://docs.gitlab.com/user/project/labels/#scoped-labels), nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.\n\n\n![Ticket d'intégration GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nNous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.\n\n\nÀ partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets. \n\n\n## Standardisation des réponses avec des templates de commentaires\n\n\nAvec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.\n\n\nNous avons créé des [templates de commentaires](https://docs.gitlab.com/user/profile/comment_templates/), que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un [script Ruby](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\n\nLe script est déclenché dans le fichier `.gitlab-ci.yml` lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).\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![Template de commentaire dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Suppression du temps d'attente de 5 minutes\n\n\nNotre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.\n\n\n[Niklas](https://gitlab.com/Taucher2003), un membre de notre [équipe Core](https://about.gitlab.com/community/core-team/), a trouvé une solution. Il a ajouté des [événements webhook pour les demandes d'accès](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094) et des [templates de charge utile personnalisés pour les webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\n\nCes fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée. \n\n\nNous avons configuré un [token de déclenchement de pipeline](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :\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![Liste de pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Automatisation des suivis\n\n\nAvec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.\n\n\nNous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance. \n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.\n\n\n![Relance automatisée des tickets d'intégration inactif dans GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## Organisation du suivi des tickets avec GLQL\n\n\nNous avons construit une [vue GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.\n\n\n![Vue GLQL du suivi des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nCes vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes [GitLab pour l’open source](https://about.gitlab.com/fr-fr/solutions/open-source/) et [GitLab pour l'éducation](https://about.gitlab.com/fr-fr/solutions/education/). Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.\n\n\n## Meilleure accessibilité du README\n\n\nLe [groupe @gitlab-community](https://gitlab.com/gitlab-community/) est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier `README.md` expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.\n\n\nNous avons alors utilisé la [mise en miroir de projet de GitLab](https://docs.gitlab.com/user/project/repository/mirror/) pour résoudre cela et mis en miroir le projet meta vers `gitlab-profile`. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.\n\n\n![Mise en miroir de projet GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![README de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Les résultats parlent d'eux-mêmes\n\n\nEn utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD?\").\n\n\nNotre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.\n\n\n![Graphique de croissance des forks de la communauté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nNous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer. \n\n\nNous utilisons l’[analyse de la chaîne de valeur](https://docs.gitlab.com/user/group/value_stream_analytics/) de GitLab pour suivre nos taux de réponse.\n\n\n* Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois\n\n* Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois\n\n\n![Chronologie de l’analyse de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nLe taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.\n\n\n## Meilleure reconnaissance des contributeurs\n\n\nCorriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : [contributors.gitlab.com](http://contributors.gitlab.com). Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.\n\n\n## Partager ce que nous avons appris\n\nCes améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer. \n\n\nAu fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance. \n\n\n**Contactez-nous**\n\n\nVous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à contributors@gitlab.com ou [créez un ticket](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues) pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.\n",[705,706],"Lee Tickett","Daniel Murphy",{"featured":6,"template":685,"slug":708},"how-we-use-gitlab-to-grow-open-source-communities","content:fr-fr:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"_path":714,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":715,"content":720,"config":727,"_id":729,"_type":16,"title":730,"_source":18,"_file":731,"_stem":732,"_extension":21},"/fr-fr/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":716,"description":717,"ogTitle":716,"ogDescription":718,"ogImage":719},"Nouveautés de Git 2.50.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.\n\n\n","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749663087/Blog/Hero%20Images/git3-cover.png",{"body":721,"title":716,"description":722,"heroImage":719,"authors":723,"date":725,"category":14,"tags":726},"Le projet Git a récemment publié la [version 2.50.0 de Git](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u).\n\nDécouvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.\n\n\n## Nouvelle commande git-diff-pairs(1)\n\n\nLes diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet [« Modifications »](https://docs.gitlab.com/user/project/merge_requests/changes/) d'une merge request. En arrière-plan, la génération de diff est effectuée par [`git-diff(1)`](https://git-scm.com/docs/git-diff).\n\n\nPar exemple :\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nCette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème de performance, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser le délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à traiter.\n\n\nPour ce faire, vous pouvez utiliser [`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree/fr) pour récupérer des informations sur tous les fichiers modifiés :\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n\n:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n\n\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n\n```\n\n\nGit appelle ce résultat le [format « brut »](https://git-scm.com/docs/git-diff-tree/fr). En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de diffs pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer une détection de changement de nom en ajoutant `-M` pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.\n\n\nAvec ces informations, nous pourrions utiliser `git-diff(1)` pour calculer chacun des diffs de paire de fichiers individuellement.\n\n\nPar exemple, nous pouvons fournir directement des ID de blob :\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nNous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme pouvant recevoir des informations « brutes » sur les paires de fichiers et générant en sortie les diffs correspondants.\n\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui reçoit sur son entrée standard (« stdin ») les informations de paires de fichiers au format « brut » pour déterminer avec précision les diffs à générer.\n\n\nL'exemple suivant montre comment cette commande peut être utilisée :\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nDe cette façon, la sortie générée est identique à celle obtenue avec `git-diff(1)`. En utilisant une commande distincte pour générer la sortie de diffs, la sortie « brute » de `git-diff-tree(1)` peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus `git-diff-pairs(1)` distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.\n\n\nPour plus d'informations sur ce changement, consultez ce [fil de discussion](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## Mises à jour des références par lots\n\n\nGit fournit la commande `git-update-ref(1)` pour effectuer des mises à jour de références. Lorsqu'elle est associée à `--stdin`, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur l'entrée standard (« stdin »). La mise à jour des références en un seul lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.\n\n\nVoici un exemple illustrant ce comportement :\n\n\n```shell\n\n# Create repository with three empty commits and branch named \"foo\"\n\n\n$ git init\n\n\n$ git commit --allow-empty -m 1\n\n\n$ git commit --allow-empty -m 2\n\n\n$ git commit --allow-empty -m 3\n\n\n$ git branch foo\n\n\n# Print out the commit IDs\n\n\n$ git rev-list HEAD\n\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n\n# Update is expected to fail because the specified old object ID doesn’t match.\n\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# The \"bar\" reference was not created.\n\n\n$ git switch bar\n\n\nfatal: invalid reference: bar\n\n```\n\n\nEn comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Mais nous voulons quand même bénéficier de l'efficacité des mises à jour par lot.\n\n\nAvec cette version, `git-update-ref(1)` met à disposition la nouvelle option `--batch-updates`, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.\n\n\nDans ce mode, les échecs individuels sont signalés dans le format suivant :\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n```\n\n\nIl est ainsi possible de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.\n\n\nVoici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :\n\n\n```shell\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n\n\n$ git switch bar\n\n\nSwitched to branch 'bar'\n\n```\n\n\nCette fois, avec l'option `--batch-updates`, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de diffs est un aperçu des futures améliorations des performances de `git-fetch(1)` et `git-receive-pack(1)` lors de la mise à jour de références par lot.\n\n\nPour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/).\n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n## Nouvelle option de filtre pour git-cat-file(1)\n\n\nAvec `git-cat-file(1)`, il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option `--batch–all-objects`.\n\n\nEn voici un exemple :\n\n\n```shell\n\n# Setup simple repository.\n\n\n$ git init\n\n\n$ echo foo >foo\n\n\n$ git add foo\n\n\n$ git commit -m init\n\n\n# Create an unreachable object.\n\n\n$ git commit --amend --no-edit\n\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.\n\n\nPar exemple, si nous voulons voir uniquement les objets qui sont des commits, nous pouvons utiliser `grep(1)` :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nBien que cela fonctionne, un des inconvénients du filtrage de la sortie est que `git-cat-file(1)` doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.\n\n\nAvec la version 2.50.0, `git-cat-file(1)` dispose désormais de l'option `--filter`, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour `git-rev-list(1)`, mais seul un sous-ensemble des filtres est pris en charge : `blob:none`, `blob:limit=`, ainsi que `object:type=`.\n\n\nComme dans l'exemple précédent, il est possible de filtrer les objets par type avec [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") directement :\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nNon seulement il est pratique de laisser Git s'occuper du traitement, mais pour les dépôts volumineux contenant de nombreux objets, c'est aussi potentiellement plus efficace. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage (« packfile »), ce qui accélère significativement le processus.\n\n\nLes benchmarks effectués sur le [dépôt Chromium](https://github.com/chromium/chromium.git) montrent des améliorations significatives :\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\n\n\nRange (min … max): 73.936 s … 89.690 s 10 runs\n\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\n\n\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\n\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\n\n\nRange (min … max): 1.541 s … 1.566 s 10 runs\n\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\n\n\nRange (min … max): 11.114 s … 11.245 s 10 runs\n\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\n\n\nRange (min … max): 62.836 s … 73.618 s 10 runs\n\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\n\n\nRange (min … max): 12.960 s … 13.199 s 10 runs\n\n\nSummary\n\n\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\n\n3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n```\n\n\nIl est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce [fil de discussion](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Ce projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n## Amélioration des performances lors de la génération d'archives\n\n\nAvec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui les accompagnent via la commande [`git-bundle(1)`](https://git-scm.com/docs/git-bundle/fr). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme [`bundle-URI`](https://git-scm.com/docs/bundle-uri).\n\n\nPour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab ([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans l'archive. L'implémentation utilisait une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui entrainait une complexité temporelle O(N^2). Cette façon de procéder dégradait fortement les performances à mesure que le nombre de références dans un dépôt augmentait.\n\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par un tableau associatif, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'une archive avec un dépôt contenant 100 000 références :\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n\n\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\n\n\nRange (min … max): 14.237 s … 14.920 s 10 runs\n\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n\n\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\n\n\nRange (min … max): 2.364 s … 2.425 s 10 runs\n\n\nSummary\n\n\nbundle (refcount = 100000, revision = HEAD) ran\n\n\n6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nPour en savoir plus, découvrez notre article de blog qui explique [comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/) et consultez ce [fil de discussion](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n*Ce projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n## Meilleur dégroupage des URI d'archives\n\n\nÀ l'aide du mécanisme [bundle-uri](https://git-scm.com/docs/bundle-uri) dans Git, il est possible de fournir aux clients les emplacements pour récupérer des archives dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge une archive, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés de l'archive dans le dépôt. Une archive peut contenir des références supplémentaires en dehors de `refs/heads/*` telles que `refs/tags/*`, qui sont simplement ignorées lors de l'utilisation de bundle-uri sur le clone.\n\n\nDans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à `refs/*` contenues dans l'archive téléchargée sont copiées.\n\n\n[Scott Chacon](https://github.com/schacon), qui a contribué à cette fonctionnalité, montre la différence lors du clonage de [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\n\nCloning into 'gl2.49'...\n\n\nremote: Enumerating objects: 1092703, done.\n\n\nremote: Counting objects: 100% (973405/973405), done.\n\n\nremote: Compressing objects: 100% (385827/385827), done.\n\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\n\nChecking objects: 100% (4194304/4194304), done.\n\n\nChecking connectivity: 959668, done.\n\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\n\nCloning into 'gl-2.50'...\n\n\nremote: Enumerating objects: 65538, done.\n\n\nremote: Counting objects: 100% (56054/56054), done.\n\n\nremote: Compressing objects: 100% (28950/28950), done.\n\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nEn comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction de l'archive, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.\n\n\nPour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*Cette série de contributions a été fournie par Scott Chacon.*\n\n\n## En savoir plus\n\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) du projet Git et en consultant ces [ressources](https://about.gitlab.com/blog/tags/git/).\n","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git, dont git-diff-pairs(1) et git-rev-list(1), pour la mise à jour de références par lot.",[724],"Justin Tobler","2025-07-02",[272,682,683],{"featured":6,"template":685,"slug":728},"what-s-new-in-git-2-50-0","content:fr-fr:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","fr-fr/blog/what-s-new-in-git-2-50-0.yml","fr-fr/blog/what-s-new-in-git-2-50-0",{"_path":734,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":735,"content":743,"config":751,"_id":753,"_type":16,"title":754,"_source":18,"_file":755,"_stem":756,"_extension":21},"/fr-fr/blog/what-is-open-source",{"title":736,"description":737,"ogTitle":736,"ogDescription":737,"noIndex":6,"ogImage":738,"ogUrl":739,"ogSiteName":740,"ogType":741,"canonicalUrls":739,"schema":742},"Open source : définition, avantages et défis","Qu'est-ce que l'open source ? Apprenez comment ce modèle collaboratif transforme le développement logiciel grâce au libre accès et au partage du code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662973/Blog/Hero%20Images/open-source-definition.jpg","https://about.gitlab.com/blog/what-is-open-source","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open source : définition, avantages et défis\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-04-16\",\n      }",{"title":736,"description":737,"authors":744,"heroImage":738,"date":746,"body":747,"category":14,"tags":748},[745],"GitLab France Team","2025-04-16","Basé sur des principes fondamentaux tels que l'ouverture, le partage des connaissances et l'amélioration continue, l'open source révolutionne le monde du développement logiciel. En réunissant des développeurs du monde entier, l'open source crée un environnement propice à l'innovation, où les idées et les solutions émergent grâce à la diversité des contributions. \n\nDécouvrez dans cet article les principes fondamentaux du développement [open source](https://about.gitlab.com/fr-fr/solutions/open-source/ \"Solutions GitLab pour les projets open source\"). \n\n## Qu’est-ce que l’open source ? \n\nL'open source est un modèle de développement fondé sur la transparence et la collaboration. Contrairement aux logiciels propriétaires, où seul le détenteur des droits peut modifier le code source ou redistribuer le produit, l'open source rend ce code accessible à tous. Les développeurs du monde entier peuvent ainsi l'examiner, l'améliorer et le partager librement, favorisant l'innovation et le progrès collectif.\n\n> [\nEssayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.\n\n## Quels sont les avantages de l'open source ?\n\nBien plus qu'une alternative technologique, l'open source est un modèle offrant de nombreux avantages. Réduction des coûts, accélération de l'innovation, meilleure sécurité des logiciels, ou encore personnalisation, sont autant d'atouts qui peuvent transformer les projets et stimuler la croissance des entreprises.\n\n### Des coûts réduits \n\nÀ l'opposé des solutions propriétaires parfois onéreuses, les logiciels open source se distinguent souvent par leur faible coût, vous dispensant des dépenses traditionnellement associées aux licences et au support technique. Chez GitLab par exemple, les utilisateurs ont la possibilité d’utiliser gratuitement [GitLab Community Edition (CE)](https://about.gitlab.com/fr-fr/install/ce-or-ee/ \"GitLab Community Edition (CE)\") qui est open source. \n\n### Une meilleure transparence\n\nL'accès au code source permet à qui le souhaite d'examiner, de modifier et d'améliorer les logiciels. Pour les développeurs, cette transparence facilite leur compréhension des logiciels, de la manière dont ils sont construits et des failles de sécurité potentielles qu'ils peuvent contenir. Par exemple, le code source de GitLab est disponible publiquement sur GitLab.com et offre aux utilisateurs l'opportunité d’inspecter le code, de comprendre son fonctionnement et même de contribuer activement à son développement.  \n\n### Des logiciels personnalisables \n\nL'open source offre aux entreprises la possibilité d'adapter leurs logiciels à leurs besoins spécifiques, là où les solutions propriétaires limitent souvent cette liberté. Grâce à leur nature modulable, les logiciels open source permettent d'optimiser l'efficacité opérationnelle en s'adaptant précisément aux besoins des entreprises. GitLab illustre cette flexibilité en offrant à tous la possibilité de contribuer de façon traditionnelle, et en offrant également aux entreprises la possibilité de développer des intégrations et des fonctionnalités sur mesure grâce à son [programme Co-Create](https://about.gitlab.com/community/co-create/ \"Programme Co-Create\").\n\n### Une communauté engagée \n\nLes projets open source reposent sur l'engagement d'une communauté qui partage ses connaissances pour résoudre des problèmes ou proposer des améliorations sur les logiciels. GitLab [tire pleinement parti de cet écosystème](https://about.gitlab.com/community/ \"Communauté de GitLab\") en s'appuyant sur une base d'utilisateurs et de développeurs qui enrichissent activement son développement et [partagent leur expertise](https://forum.gitlab.com/ \"Forum de GitLab\"). GitLab collabore également avec d'autres entreprises sur des projets open source comme Git, renforçant son engagement pour l'innovation collective et la création de solutions évolutives.\n\n### Un accélérateur d’innovations\n\nEn réunissant des talents du monde entier autour de projets communs, l'open source devient un puissant moteur d'innovation. Cette synergie stimule l'amélioration continue et l'enrichissement des logiciels grâce à la diversité des compétences partagées. Ce modèle accélère ainsi le développement technologique en rendant les outils open source accessibles à un large public. GitLab, avec son cycle de release mensuel, [intègre régulièrement de nouvelles fonctionnalités et améliorations](https://about.gitlab.com/releases/ \"Releases GitLab\") fondées sur les retours et contributions de sa communauté d'utilisateurs.\n\n### Des logiciels évolutifs\n\nLes logiciels open source reposent souvent sur des normes ouvertes qui [simplifient leur intégration avec d'autres systèmes](https://about.gitlab.com/fr-fr/integrations/ \"Intégrations GitLab\"). Conçus pour s'adapter à divers environnements, ils offrent aux entreprises la possibilité de créer des solutions sur mesure, performantes et évolutives.\n\n### Une sécurité logicielle renforcée\n\nLa sécurité et la fiabilité sont des piliers essentiels des logiciels open source. Grâce à l'examen continu du code par une large communauté de développeurs, les failles de sécurité sont rapidement identifiées et corrigées. Bien que cette approche ne garantisse pas une sécurité absolue, elle favorise grandement la réactivité des équipes de développement face aux vulnérabilités de toutes sortes. GitLab applique ce principe en [s'appuyant sur sa communauté pour renforcer la sécurité de sa plateforme](https://handbook.gitlab.com/handbook/security/product-security/application-security/runbooks/hackerone-process/).\n\n### Un savoir-faire enrichi\n\nLes logiciels open source représentent une mine d'opportunités d'apprentissage pour les développeurs. En s'impliquant dans ces projets, ils peuvent perfectionner leurs compétences et gagner en expérience auprès d'autres professionnels du domaine, enrichissant leur savoir-faire et accélérant leur développement professionnel.\n\nPar exemple, les développeurs peuvent étudier la base de code de GitLab pour apprendre les meilleures pratiques en matière de développement de plateformes DevSecOps. Les membres de l'équipe GitLab participent par ailleurs à des programmes de mentorat comme [Google Summer of Code](https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare/ \"Google Summer of Code\") et [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/ \"Outreachy\") qui permettent d'apprendre aux nouveaux participants comment contribuer à GitLab ou autres logiciels open source comme Git.\n\n### Des logiciels plus qualitatifs\n\nDe nombreux projets open source bénéficient de la contribution de développeurs talentueux. Grâce à leur expertise, le code des logiciels open source est constamment examiné, amélioré et renforcé, ce qui permet de développer des solutions robustes et performantes.\n\n## Quels sont les défis liés à l’open source\n\nExplorer l'univers des logiciels open source peut être aussi stimulant qu'exigeant. De la création de relations solides avec une communauté au renforcement de la sécurité des projets, chaque étape comporte ses propres défis. Pour réussir, il est essentiel de comprendre ces obstacles et de mettre en place des stratégies adaptées.\n\n### Construire une relation solide avec sa communauté \n\nLe succès du développement open source repose sur la capacité à établir et à maintenir une relation solide avec une communauté de développeurs et d'utilisateurs. Cela nécessite des échanges continus afin de comprendre et de répondre à ses attentes. Puisque la majorité des contributeurs sont bénévoles, il est essentiel de coordonner leurs efforts de manière agile et structurée.\n\nPour maintenir leur motivation sur le long terme, notamment pour les contributeurs œuvrant sans contrepartie financière, il est crucial de reconnaître et de valoriser leur travail. Cela peut passer par des mentions officielles (crédits), des opportunités de formation ou d'autres formes de reconnaissances professionnelles. Sans cette valorisation, les contributeurs risquent de se détourner des projets, voire de créer des initiatives parallèles. Bâtir une communauté engagée et durable est donc au cœur du succès de tout projet open source.\n\n### Trouver un équilibre entre les intérêts de la communauté et celle des entreprises\n\nTrouver un équilibre entre les intérêts des entreprises et ceux de la communauté est un défi central dans le développement open source. Les entreprises impliquées dans ces projets ont généralement des objectifs prioritaires. Ces priorités, souvent commerciales, peuvent entrer en conflit avec les attentes plus larges de la communauté, dont les intérêts sont plutôt axés sur l'innovation libre ou la personnalisation des logiciels.\n\nLorsque les décisions semblent trop axées sur les intérêts de l'entreprise, la communauté risque de se sentir exclue, ce qui peut réduire son engagement et limiter ses contributions. Pour éviter ce désengagement, les entreprises doivent partager clairement leurs objectifs et échanger régulièrement avec leur communauté pour garantir la pérennité et le succès à long terme des projets open source.\n\n### Maintenir la sécurité des logiciels\n\nLes logiciels open source sont exposés à certains défis en matière de sécurité. La transparence du code, bien qu'étant l'un de leurs plus grands atouts, peut aussi les exposer à des attaques ciblées, ce qui peut devenir un risque majeur si l'entreprise à l’origine du projet open source ne corrige pas rapidement les failles identifiées. \n\nLes utilisateurs comptent ainsi sur la réactivité de l'entreprise pour garantir la sécurité de leurs systèmes et de leurs données. \n\n## GitLab : un partenaire incontournable pour les projets open source\n\nLes projets open source sont un moteur d'innovation technologique, et choisir la bonne plateforme pour les héberger est essentiel. Grâce à son système de gestion de versions basé sur [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"), GitLab permet aux équipes de développement de collaborer efficacement, de suivre les modifications de code et de conserver un historique complet de leurs projets. \n\n### Une suite complète de fonctionnalités collaboratives\n\nGitLab met à disposition de ses utilisateurs une suite complète de fonctionnalités adaptées au développement et à la gestion de projets open source. Parmi ces fonctionnalités figurent le [suivi des tickets](https://docs.gitlab.com/ee/user/project/issues/ \"Tickets GitLab\"), les [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/ \"merge requests\"), la [revue de code](https://about.gitlab.com/fr-fr/topics/version-control/what-is-code-review/ \"Qu'est-ce qu'une revue de code ? \"), les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\") et les [GitLab Pages](https://about.gitlab.com/fr-fr/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages/ \"GitLab Pages\"). Ces fonctionnalités permettent aux équipes de suivre l'évolution des projets, de collaborer, de proposer des améliorations, de corriger des bogues et de documenter leurs progrès en temps réel. \n\n### Des pratiques CI/CD au service des projets open source\n\nLes fonctionnalités [CI/CD](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/ \"Meilleures pratiques CI/CD\") de GitLab sont un atout majeur pour les projets open source. Elles automatisent des étapes clés du développement logiciel, comme les [tests](https://docs.gitlab.com/ee/ci/testing/), la validation du code et le déploiement de nouvelles versions, assurant ainsi une meilleure fiabilité des logiciels open source et un développement accéléré. Chaque contribution est automatiquement testée dans un environnement dédié, ce qui permet de détecter rapidement les erreurs et de corriger les bogues. Cela réduit les risques de défaillances tout en assurant la stabilité des projets. \n\n### Un cycle de développement logiciel sécurisé\n\nGitLab propose une suite complète de fonctionnalités conçues pour aider les développeurs de projets open source à sécuriser leurs logiciels. Parmi ces fonctionnalités, nous retrouvons :\n\n- __Le test statique de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))__ qui examine le code source à la recherche de failles de sécurité en amont de la mise en service des logiciels. \n- __Le test dynamique de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))__* qui teste les applications en cours d'exécution au sein d’un environnement déployé pour détecter d'éventuelles vulnérabilités encore non repérées. \n- __L'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/ \"Analyse des dépendances\")__* qui envoie des alertes sur les bibliothèques obsolètes ou vulnérables. Des rapports détaillés sont générés à chaque étape du développement, offrant une visibilité claire sur l'état de la sécurité du projet. Grâce à cela, les développeurs peuvent rapidement éviter ou corriger les composants à risque.\n\n** Fonctionnalité disponible uniquement pour les utilisateurs de GitLab Ultimate.*\n\nEn intégrant ces fonctionnalités directement dans le [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\"), GitLab réduit le risque d'erreurs humaines et accélère l’identification et la correction des vulnérabilités. Cette approche permet ainsi aux développeurs de projets open source de maintenir un niveau élevé de sécurité tout au long du cycle du développement logiciel. \n\n### Une gestion de projet Agile\n\nGitLab met à disposition des équipes de développement un certain nombre de fonctionnalités pour faciliter la gestion des projets open source comme les [tableaux de tickets](https://docs.gitlab.com/ee/user/project/issue_board.html \"Tableaux de tickets\"), les [listes des jalons](https://docs.gitlab.com/ee/user/project/milestones/ \"Listes des jalons\") ou encore le [suivi du temps](https://docs.gitlab.com/ee/user/project/time_tracking.html \"Suivi du temps\"). Ces dernières permettent de voir facilement les tâches à réaliser, de suivre l'avancement des projets en fixant des échéances claires, mais aussi d’évaluer la charge de travail en vue d'optimiser l'utilisation des ressources. En combinant ces fonctionnalités, GitLab permet aux équipes de mieux coordonner leurs efforts, de maintenir un processus de travail fluide et de progresser efficacement dans la réalisation de leurs projets open source.\n\n### Des contributions simplifiées\n\nLes équipes de développement peuvent facilement contribuer au développement de projets open source en les dupliquant ([fork](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html \"fork\")) et en créant des merge requests. Elles peuvent créer leurs propres copies du code, travailler sur des améliorations ou des correctifs dans des branches distinctes, puis soumettre leurs changements via des merge requests. Ce processus permet aux équipes de réviser et de valider chaque modification avant son intégration dans la branche principale, favorisant ainsi une amélioration continue des logiciels, tout en renforçant la qualité et la stabilité du code.\n\n### Une intégration facilité avec d’autres outils\n\nGitLab facilite considérablement son intégration avec d’autres outils et workflows , permettant aux équipes de développement de créer un environnement personnalisé en fonction des exigences spécifiques de leur projet. Pour en savoir plus, [consultez notre documentation](https://docs.gitlab.com/ee/api/). \n\n## Développez des logiciels open source avec GitLab \n\nL’open source continue de s'imposer dans le monde du développement logiciel. Avec des plateformes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") comme GitLab, les équipes de développement disposent de tous les outils et ressources nécessaires au bon développement de leurs logiciels open source.\n\nEn plus d’aider les entreprises à développer des logiciels performants et sécurisés, GitLab fait évoluer continuellement sa plateforme grâce aux contributions et aux retours de ses utilisateurs. En écoutant sa communauté en permanence, GitLab s'adapte aux transformations du développement logiciel, renforçant ainsi sa présence au sein de l'écosystème open source.\n\n> [\nEssayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/devsecops/ \"Essai gratuit de GitLab Ultimate\") et commencez à développer des logiciels open source dès aujourd'hui.",[683,749,750],"DevOps","DevSecOps",{"slug":752,"featured":6,"template":685},"what-is-open-source","content:fr-fr:blog:what-is-open-source.yml","What Is Open Source","fr-fr/blog/what-is-open-source.yml","fr-fr/blog/what-is-open-source",{"_path":758,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":759,"content":765,"config":772,"_id":774,"_type":16,"title":775,"_source":18,"_file":776,"_stem":777,"_extension":21},"/fr-fr/blog/journey-through-gits-20-year-history",{"title":760,"description":761,"ogTitle":760,"ogDescription":761,"noIndex":6,"ogImage":762,"ogUrl":763,"ogSiteName":740,"ogType":741,"canonicalUrls":763,"schema":764},"Git : 20 ans d'histoire","Revivez les débuts du projet Git, avec le tout premier commit, découvrez les particularités des premières versions et replongez dans la confusion qu'a provoquée le changement du comportement par défaut de git-push(1).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","https://about.gitlab.com/blog/journey-through-gits-20-year-history","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git : 20 ans d'histoire\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }\n                  ",{"title":760,"description":761,"authors":766,"heroImage":762,"date":768,"body":769,"category":14,"tags":770,"updatedDate":771},[767],"Patrick Steinhardt","2025-04-14","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") vient de fêter ses 20 ans et depuis, bien des choses ont changé : si le design conceptuel de Git est resté globalement le même, la manière dont les utilisateurs s'en servent, elle, a considérablement évolué. Git est au cœur de notre travail chez GitLab et nous sommes fiers d'être liés à son histoire.\n\nRemontez le temps avec nous pour retracer les grandes étapes de son évolution.\n\n## Le premier commit\n\nLe premier commit a été effectué le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux : `e83c5163316 (Initial revision of \"git\", the information manager from hell, 2005-04-07)`.\n\nComme vous pouvez le constater, ce commit ne contient pas beaucoup de fichiers :\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nOutre l'infrastructure de compilation, le premier commit fournit sept commandes principales :\n\n- `init-db` pour initialiser un nouveau dépôt Git\n- `update-cache` pour ajouter des fichiers à l'index\n- `write-tree` pour créer un nouvel arbre à partir des éléments de l'index\n- `read-tree` pour lire un objet arbre\n- `commit-tree` pour créer un commit à partir d'un arbre\n- `cat-file` pour lire un objet spécifique dans un fichier temporaire\n\nNotez que la commande `git` n'existait pas encore à ce moment-là. Il fallait dès lors les exécuter directement.\n\nPour vous montrer un exemple concret, créons un nouveau dépôt :\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nCela peut surprendre : il n'y a pas de répertoire `.git`, mais un répertoire `.dircache`. Ce dernier représentait une zone de stockage privée. \n\nGit distinguait alors deux types d'espaces de stockage des objets : un espace « privé » et un espace « partagé ». Ceux-ci regroupaient tous vos objets Git : vos commits et vos blobs, par exemple.\n\nPar défaut, `init-db` créait un espace de stockage des objets privé qui n'était utilisé que pour le répertoire géré dans lequel il avait été créé. L'espace de stockage des objets « partagé », quant à lui, permettait de centraliser les objets communs à plusieurs répertoires, ce qui évitait d'avoir à les stocker deux fois.\n\n### Créer un commit\n\nNous disposons maintenant d'un dépôt, mais comment procéder pour créer un commit ? Autant vous dire que ce n'est pas aussi simple qu'avec la commande actuelle `git add . && git commit`. À l'époque, vous deviez :\n\n1. Mettre à jour l'index en appelant `update-cache` pour chaque fichier que vous souhaitiez ajouter. \n2. Écrire un nouvel arbre en appelant `write-tree` pour prendre le contenu que vous aviez\n   ajouté à l'index.\n3. Configurer les variables d'environnement pour indiquer à Git que vous en étiez l'auteur.\n4. Créer un objet de commit en appelant `commit-tree`.\n\nCréons un commit dans le dépôt pour illustrer ce processus :\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nCertes, ce processus n'est pas très pratique, mais il fonctionne ! Découvrons maintenant le commit généré :\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nNotez que `cat-file` n'a pas affiché le contenu directement, mais l'a d'abord écrit\ndans un fichier temporaire. Toutefois, le contenu du fichier ressemblait déjà en tous points à\ncelui des commits actuels.\n\n### Apporter des modifications\n\nMaintenant que nous avons des fichiers, comment pouvons-nous obtenir leur statut ? Vous l'aviez peut-être deviné, en utilisant `show-diff` :\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nÉtonnamment, la commande `show-diff` permettait déjà de générer des diffs entre l'ancien et le nouvel état des fichiers modifiés ! Et pour l'anecdote, Git accomplissait cette tâche en exécutant simplement l'outil Unix diff(1).\n\nEn somme, tout était encore rudimentaire, mais suffisant pour assurer le suivi de l'historique. À ce stade, Git était encore très limité :\n\n- Il était impossible de passer facilement d'un commit à un autre.\n- Il était impossible d'afficher les logs.\n- Il n'y avait pas de branches, de tags ou même de références. Les utilisateurs devaient manuellement conserver une trace des ID d'objet.\n- Il était impossible de synchroniser deux dépôts. Par conséquent,\n  les utilisateurs devaient utiliser rsync(1) pour synchroniser les répertoires `.dircache`.\n- Il était impossible de fusionner des modifications.\n\n## Git 0.99\n\nLa version 0.99 de Git a été la première à entrer en phase de test. Celle-ci a été publiée seulement deux mois après le commit initial, mais contenait déjà 1 076 commits. Près de 50 développeurs différents ont participé à son développement. À ce stade, Linus Torvalds était encore le principal contributeur, talonné de près par Junio Hamano, qui est aujourd'hui le chargé de maintenance.\n\nDe nombreuses améliorations avaient été mises en place depuis le premier commit :\n\n- Git avait commencé à suivre différentes branches de développement à l'aide de références, ce qui, dans la grande majorité des cas, dispensait les utilisateurs de suivre les ID d'objets manuellement.\n- Un nouveau protocole distant permettait désormais à deux dépôts d'échanger\n  des objets entre eux.\n- Le répertoire `.dircache` avait été renommé `.git`.\n- Il était désormais possible de fusionner des fichiers uniques entre eux.\n\nMais le changement le plus marquant a sans doute été l'arrivée de\nla commande principale `git` et de ses nombreuses sous-commandes. C'est aussi à cette occasion\nqu'est née la distinction entre les commandes dites de « plomberie » (plumbing) et de « porcelaine » (porcelain) :\n\n- Les outils de « plomberie » sont les commandes de bas niveau qui accèdent au dépôt Git\n sous-jacent.\n- Les outils de « porcelaine » sont des scripts shell qui encapsulent les commandes de « plomberie » pour fournir une interface utilisateur plus conviviale et performante.\n\nCette distinction existe encore aujourd'hui, comme expliqué dans\n[`git(1)`](https://git-scm.com/docs/git/fr#_commandes_de_haut_niveau_porcelaine), mais avec\nla réécriture en C de nombreuses commandes de « porcelaine » initialement en shell, la frontière entre ces deux catégories a commencé à s'estomper significativement.\n\n## Linus Torvalds passe la main\n\nLinus Torvalds n'a jamais créé Git par passion pour les systèmes de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version\"), mais parce qu'il était nécessaire de remplacer BitKeeper pour le développement du noyau Linux. Dès le départ, il n'avait pas l'intention d'en assurer la maintenance indéfiniment, mais juste le temps de trouver quelqu'un de confiance pour reprendre le flambeau. \n\nEt cette personne fut Junio Hamano. Junio a rejoint Git une semaine à peine après le premier  commit de Linus Torvalds et comptait déjà plusieurs centaines de commits dans l'historique au moment de la sortie de la version 0.99. Ainsi, le 26 juillet 2005, [Linus Torvalds l'a désigné comme nouveau chargé de maintenance du projet Git](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Même si Linus Torvalds a continué à contribuer à Git, son implication s'est progressivement réduite, ce qui n'a rien de surprenant, vu ses responsabilités à la tête du projet Linux. \n\nA ce jour, Junio Hamano dirige toujours le projet Git. \n\n## Git 1.0\n\nLa première version majeure de Git est sortie le 21 décembre 2005 par Junio Hamano. Fait intéressant : pas moins de 34 nouvelles versions ont été publiées entre la version 0.99 et la version 1.0 : 0.99.1 à 0.99.7, 0.99.7a à 0.99.7d, 0.99.8 à 0.99.8g, et 0.99.9 jusqu'à 0.99.9n.\n\nParmi les évolutions majeures depuis la version 0.99, l'une des plus importantes a sans doute été l'introduction de la commande `git-merge(1)` pour fusionner deux arbres. Un changement radical par rapport à la version précédente, dans laquelle chaque merge devait être effectuée manuellement, fichier par fichier.\n\n### Dépôts distants\n\nUn autre changement majeur a été l'introduction de la notation abrégée pour\nles dépôts distants. Git savait déjà communiquer avec eux, mais jusque-là,\nles utilisateurs devaient entrer l'URL complète à chaque\nrécupération de modifications. Ce processus était plutôt contraignant, car dans la grande majorité des cas, les utilisateurs interagissaient toujours avec le même dépôt distant. \n\nAujourd'hui, vous connaissez probablement le fonctionnement des dépôts distants,\nmais à l'époque, le mécanisme était encore très différent. Il n'existait pas de commande `git-remote(1)`  \npour les gérer. Ils n'étaient même pas stockés  \ndans votre fichier`.git/config` file. À vrai dire, lorsque les dépôts distants ont fait leur apparition dans\nla version 0.99.2, Git ne *disposait* même pas encore de fichiers de configuration. \n\nPour les configurer, il fallait créer un fichier dans le\nrépertoire `.git/branches`, un mécanisme qui semble aujourd'hui plutôt contre-intuitif. Mais  \nil fonctionne encore aujourd'hui :\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nEt ce n'est pas tout ! Le répertoire a été renommé en « dépôts distants » dès la version 0.99.5 de Git. Aujourd'hui, il existe donc trois méthodes distinctes pour configurer des dépôts distants dans un client Git actuel. \n\nMais soyons honnêtes : la plupart d'entre vous n'ont sans doute jamais eu à utiliser `.git/branches` ni `.git/remotes`,\ndeux mécanismes devenus obsolètes en 2005 et 2011,\nrespectivement. Ces répertoires seront d'ailleurs définitivement supprimés dans la version Git 3.0.\n\n## Image de marque de Git\n\nEn 2007, Git créé son premier logo. Le terme « logo » est peut-être un peu excessif : il ne s'agissait en réalité que de trois signes moins rouges au-dessus de trois signes plus verts, une référence visuelle directement inspirée de la sortie de `git diff` :\n\n![trois signes moins rouges au-dessus de trois signes plus verts, référence visuelle inspirée de la sortie de `git diff`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nLe site web [git-scm.com](https://git-scm.com) voit quant à lui le jour en 2008 :\n\n![page de destination pour git-scm.com en 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nEn 2012, le site web de Git est [remanié](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/) par Scott Chacon et Jason Long et son design ne changera que très peu par la suite :\n\n![site web git remanié en 2012](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nCette refonte du site arbore le nouveau logo rouge-orange conçu par Jason Long, qui est encore utilisé aujourd'hui :\n\n![logo git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nDès la version 1.0, Git ressemblait déjà fortement à la version d'aujourd'hui,\nc'est pourquoi nous allons faire un grand saut dans le temps et passer directement à une autre étape clé de son histoire : Git 2.0. Publiée environ dix ans après Git 1.0,\ncette version a été la première à\nintroduire délibérément des changements non compatibles avec les versions précédentes dans les workflows principaux.\n\n### Comportement par défaut de `git-push(1)`\n\nLe changement le plus déroutant de cette version a sans doute été\nl'ajustement du comportement par défaut de la commande  `git-push(1)`.\n\nSi vous réalisiez un push dans un dépôt distant sans en indiquer explicitement l'objet,\nGit pouvait réagir de plusieurs façons :\n\n- Refuser d'agir et vous inviter à préciser l'objet de votre push.\n- Effectuer un push de la branche actuellement extraite.\n- Effectuer un push de la branche actuellement extraite, mais uniquement s'il détectait une branche correspondante dans le dépôt distant.\n- Effectuer un push de toutes vos branches disposant d'un équivalent dans le dépôt distant.\n\nAujourd’hui, le comportement par défaut de Git suit la stratégie dite « simple », c'est-à-dire la\ntroisième option mentionnée ci-dessus. Mais avant Git 2.0, le comportement par défaut était la stratégie de « correspondance », soit la dernière option.\n\nLa stratégie de « correspondance » était nettement plus risquée. Avant le push, vous deviez toujours vous assurer que vous vouliez vraiment effectuer un push de toutes vos branches locales disposant d'un équivalent dans le dépôt distant. Dans le cas contraire, vous risquiez d'envoyer des modifications par erreur. C'est pourquoi Git a opté pour la stratégie dite « simple », afin de limiter les risques et de faciliter la prise en main pour les nouveaux utilisateurs.\n\n### `git-add(1)`\n\nLe comportement par défaut de `git-add(1)` vis-à-vis des fichiers supprimés\na lui aussi connu une évolution importante. Avant Git 2.0, la commande `git-add(1)` ne\nprenait pas en compte les fichiers supprimés : il fallait les ajouter manuellement\navec `git-rm(1)` pour qu'ils soient inclus dans un commit. À partir de la version 2.0, la commande `git-add(1)` détecte également les suppressions de fichiers et les ajoute à l’index.\n\n## La communauté Git à l'honneur\n\nNous n'allons pas entrer dans les détails du fonctionnement actuel de Git : vous l'utilisez probablement déjà au quotidien, et dans le cas contraire, de nombreux tutoriels existent pour bien débuter. Prenons plutôt un moment pour célébrer et remercier la communauté Git, qui a permis à ce système de rester aussi performant après deux décennies.\n\nAu fil du temps, Git a :\n\n- Accumulé 56 721 commits depuis [Git 2.49.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-49-0/ \"Git 2.49.0\")\n- Reçu des contributions de plus de 2 000 personnes différentes.\n- Publié 60 nouvelles versions majeures.\n\nLe projet Git continue aussi de se renouveler grâce à l'arrivée régulière de nouveaux contributeurs, notamment par le biais des programmes [Google Summer of Code](https://summerofcode.withgoogle.com/) et [Outreachy](https://www.outreachy.org/). Ce sont eux qui assurent la pérennité du projet Git. \n\n## L'avenir de Git\n\nGit s'est clairement imposé comme le grand gagnant dans la course aux systèmes de contrôle de version. Il domine largement le marché et il est rare aujourd'hui de voir un projet [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui n'utilise pas Git. C'est bien la preuve que Git a su faire les bons choix.\n\nCela dit, le développement de Git est loin d'être terminé et de nombreux défis restent à relever. Sur le plan technique :\n- la modernisation d'un code base vieillissant  \n- la mise à l'échelle face à la croissance continue des monorepos  \n- la gestion plus efficace des fichiers binaires volumineux\n\nSur le plan communautaire :\n- l'amélioration de la convivialité de Git  \n- la promotion de la communauté Git pour garantir la pérennité du\nprojet\n\nLe travail ne s'arrête pas là et chez GitLab, nous sommes fiers de contribuer activement à faire en sorte que Git reste un système de contrôle de version de référence pour les vingt années à venir.\n\n## En savoir plus sur Git\n\n- [Git fête ses 20 ans : entretien avec son créateur Linus Torvalds](https://about.gitlab.com/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) \n- [Format reftable de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git fetch vs git pull \")\n- [Commits Git : comment et pourquoi maintenir un historique propre](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\") \n- [Git en ligne de commande sous Windows avec Git Bash](https://about.gitlab.com/fr-fr/blog/git-bash/ \"Git Bash\")  \n- [Améliorez votre workflow avec Git rebase](https://about.gitlab.com/fr-fr/blog/take-advantage-of-git-rebase/ \"Git rebase\")\n",[683,682],"2025-04-25",{"slug":773,"featured":93,"template":685},"journey-through-gits-20-year-history","content:fr-fr:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","fr-fr/blog/journey-through-gits-20-year-history.yml","fr-fr/blog/journey-through-gits-20-year-history",{"_path":779,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":780,"content":786,"config":792,"_id":794,"_type":16,"title":795,"_source":18,"_file":796,"_stem":797,"_extension":21},"/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":781,"description":782,"ogTitle":781,"ogDescription":782,"noIndex":6,"ogImage":783,"ogUrl":784,"ogSiteName":740,"ogType":741,"canonicalUrls":784,"schema":785},"Git fête ses 20 ans : entretien avec son créateur Linus Torvalds","Linus Torvalds nous explique les origines de Git, pourquoi il en a confié la maintenance à Junio Hamano et ce qu'il pense de l'ajout de nouveaux langages de programmation à Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git fête ses 20 ans : entretien avec son créateur Linus Torvalds\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }\n                  ",{"title":781,"description":782,"authors":787,"heroImage":783,"date":788,"body":789,"category":14,"tags":790,"updatedDate":791},[767],"2025-04-07","Le système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ?\") Git a été introduit pour la première fois le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux. À l'occasion du 20e anniversaire de ce projet majeur, désormais adopté par la quasi-majorité des équipes de développement, nous nous sommes entretenus avec Linus sur l'histoire de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). Nous lui avons notamment demandé pourquoi il en a délégué la maintenance et quelles sont les étapes clés du projet qu'il considère comme les plus importantes.\n\n**En 2005, vous étiez déjà le chargé de maintenance du noyau Linux, qui était alors en plein essor. Pourquoi avez-vous décidé de créer un nouveau système de contrôle de version ?**\n\nJe me suis lancé dans cette aventure précisément parce que je détestais profondément les outils de contrôle de version existants.\n\nJ'avais utilisé des systèmes de contrôle de version traditionnels (CVS/RCS/SCCS) à la fois en tant qu'utilisateur final (pour suivre des projets [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") comme [GCC](https://gcc.gnu.org/)) et en tant que développeur (quand je travaillais chez Transmeta, nous utilisions exclusivement CVS) et j'en avais une aversion profonde.\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nÀ l'époque, la plupart des projets qui utilisaient CVS étaient passés à [SVN](https://subversion.apache.org/), mais en vérité, j'ai toujours pensé que SVN n'était qu'une pâle copie de CVS malgré les quelques améliorations apportées à l'interface utilisateur ; aucun des défauts fondamentaux n'avaient été corrigés et de nouveaux problèmes étaient même apparus.\n\nImpossible d'énumérer ici tous les problèmes rencontrés avec CVS et les autres systèmes du même type. Ils sont de toute façon devenus obsolètes. Les développeurs les plus jeunes n'ont même probablement jamais eu à les utiliser. J'ai toujours refusé de m'en servir pour le noyau Linux, même si quelques sous-systèmes (notamment le côté mise en réseau) utilisaient CVS pour gérer leur code dans les années 1990.\n\nÀ l'époque, je vivais dans la région de la baie de San Francisco, et Larry McVoy, qui était à l'origine notamment du projet [lmbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf), avait lancé la société BitMover, qui proposait un nouveau modèle de contrôle de version appelé BitKeeper (BK).\n\nBK n'était pas open source, mais Larry appréciait les projets open source et pensait que l'absence d'un système de contrôle de version pertinent freinait le développement du noyau Linux. Il n'avait pas tort, mais les systèmes de [gestion du code source (SCM)](https://about.gitlab.com/fr-fr/solutions/source-code-management/ \"Gestion du code source\") traditionnels ne me convenaient absolument pas. Larry a pris le temps de nous montrer, à David Miller (chargé de maintenance réseau et utilisateur de CVS) et à moi, les avantages de BitKeeper.\n\nBK n'était pas parfait. Il s'appuyait sur Source Code Control System (SCCS) comme tant d'autres SCM traditionnels et souffrait donc du même modèle restrictif d'« historique par fichier », qui pose un réel problème, notamment lors du renommage et de la suppression de fichiers.\n\nBK présentait tout de même quelques avantages. Même s'il utilisait SCCS de base, il corrigeait des problèmes vraiment essentiels et gérait le développement distribué convenablement. Il offrait par ailleurs un véritable historique global (et non par fichier). Par conséquent, le merge de code provenant de différents arbres fonctionnait réellement.\n\nAvec CVS, créer une branche et la fusionner était un événement majeur que vous deviez planifier et discuter en équipe. Avec BK, chaque dépôt correspondait à une branche. C'est une pratique courante à présent. Bien évidemment, Git l'a encore améliorée en proposant plusieurs branches *par* dépôt, mais même le modèle BK beaucoup plus limité représentait déjà une avancée majeure à l'époque.\n\nEncore une fois, BK n'était pas parfait. Son modèle basé sur un historique par fichier posait de réels problèmes, car les opérations de renommage et de merge de fichiers n'étaient tout simplement pas fiables, entraînant inévitablement des dysfonctionnements comparables à ceux rencontrés avec Attic pour les utilisateurs de CVS. Par ailleurs, BK manquait de robustesse en matière d’évolutivité, des limites qui ne devenaient toutefois réellement problématiques qu’à mesure que le projet gagnait en ampleur ou en complexité.\n\nMais la nécessité d'acquérir une licence pour pouvoir l'utiliser constituait un véritable obstacle. Bien que de nombreux chargés de maintenance du noyau avaient fini par l'adopter (nous l'avons d'ailleurs utilisé de 2002 à 2005), cette contrainte restait une source de frictions qui a atteint son paroxysme fin 2004, rendant l'utilisation de BK pour le développement du noyau intenable quelques mois plus tard.\n\nAinsi, pendant trois ans, j'ai enfin pu utiliser un contrôle de version qui fonctionnait et qui m'aidait à résoudre de nombreux problèmes. Je ne pouvais plus me passer d'un système de contrôle de version. Entretemps, aucun outil open source plus performant n’avait vu le jour au sein de la communauté open source.\n\nBien sûr, il était de notoriété publique que CVS et SVN ne fonctionnaient pas bien. Certaines équipes ont même tenté d'autres approches, parfois encore pires (comme un suivi de correctifs sophistiqué) ; d'autres ont eu de bonnes idées, mais qui aboutissaient pourtant à de nouvelles erreurs de conception (comme [Monotone](https://www.monotone.ca/)).\n\nAprès un certain temps et des recherches infructueuses, j'ai finalement décidé de créer mon propre système.\n\nTechniquement, il ne m'a fallu que quelques jours pour créer la première version de Git, comme le prouve l'historique des commits. Dès que celle-ci a atteint un niveau de fonctionnalité suffisant, j'ai pu commencer à appliquer les correctifs proposés par d'autres contributeurs. Quelques jours plus tard, ma version était activement utilisée pour le développement du noyau.\n\nMais cette rapidité apparente cache un travail préparatoire de plusieurs mois de *réflexion*. Écrire du code est relativement facile. Le plus important, c'est la conception initiale. L'historique des commits que j'évoquais plus tôt ne montre pas tout le travail de fond effectué en amont.\n\nEt pour être honnête, cette première version était ultra rudimentaire et relativement basique par rapport aux nombreuses fonctionnalités que Git propose aujourd'hui. Mais elle incluait déjà les éléments clés de la structure fondamentale de Git.\n\n**Pouvez-vous nous donner un bref aperçu des débuts du projet Git ?**\n\nEn somme, j'avais décidé de suspendre le développement du noyau tant que je n'aurais pas d'alternative qui me convenait : un système distribué, performant et capable de garantir la détection de toute corruption de fichiers.\n\nJe tiens cependant à souligner que je n'étais pas intéressé par les SCM en tant que tels. Ce qui m'importait, c'était le résultat final, pas le processus. Pour moi, Git n'avait pas le même intérêt que le noyau Linux : j'utilise Linux parce que je trouve que le fonctionnement des noyaux est fascinant, mais j'ai créé Git par obligation, pas par passion.\n\nD'où le fait que j'en ai délégué la maintenance.\n\n**Pourquoi avez-vous confié la maintenance de Git à Junio Hamano après quelques mois ? Pourquoi avez-vous choisi Junio ?**\n\nTransmettre la maintenance de Git était un choix évident. Je savais dès le départ que je me concentrerais de nouveau uniquement sur le noyau dès que j'aurais trouvé une personne de confiance à qui déléguer la maintenance.\n\nCela ne signifie pas pour autant que j'ai tout laissé tomber en priant pour que tout se passe bien. J'ai assuré la maintenance de Git pendant environ quatre mois, car je sentais que je devais trouver la perle rare qui s'investirait sur le long terme.\n\nJunio a été l'une des toutes premières personnes impliquées dans ce projet, dès la première semaine de développement. Mais je ne lui ai pas attribué ce rôle dès le départ. Il m'a fallu un certain temps pour voir qui restait, qui écrivait du code pertinent et qui prenait des décisions stratégiques.\n\nJunio s'est montré exceptionnel. On me donne bien trop de crédit pour les quelques mois que j’ai passés sur Git, notamment pour la célébration du 20e anniversaire de l’existence du projet. Je revendique avoir optimisé la conception centrale et lancé le projet, mais c'est vraiment grâce à Junio (et à des centaines d’autres contributeurs) que Git est ce qu’il est aujourd’hui.\n\n**La version initiale du système de contrôle de version Mercurial est sortie seulement 12 jours après la version initiale de Git, le 19 avril 2005. Beaucoup prétendent que l'expérience utilisateur de Mercurial était supérieure à celle de Git, mais de nos jours, Git est nettement plus populaire. Pour quelles raisons d'après vous ?**\n\nC'est en grande partie dû aux effets de réseau des SCM qui ont permis à CVS de survivre aussi longtemps malgré ses limites.\n\nLe fait que le noyau Linux utilise Git a joué un rôle majeur. Plus tard, la communauté Ruby on Rails a largement contribué à sa popularité, avant que l'utilisation de Git ne se généralise dans toutes les communautés de développeurs.\n\nMais je pense aussi que la conception de Git est fondamentalement supérieure. Son architecture est à la fois très simple et extrêmement puissante, ce qui, selon moi, a facilité son adaptation à d'autres environnements, comme JGit et des implémentations plus récentes telles que le système de fichiers virtuel MSgit, et bien d'autres encore.\n\nBien que Git avait la réputation d’être un outil difficile à prendre en main, les utilisateurs habitués à d'autres systèmes SCM le trouvaient contre-intuitif. Cette complexité provenait en partie du fait que Git avait adopté certains choix audacieux que jamais un utilisateur habitué aux systèmes traditionnels n'aurait osé faire.\n\n**Le projet Git a toujours été actif depuis que vous en avez confié la maintenance à Junio, et sa communauté développe en permanence de nouvelles fonctionnalités. Selon vous, quelles ont été les étapes clés depuis que vous avez quitté le projet ?**\n\nDifficile pour moi de répondre à cette question. J'ai évidemment tout fait pour que Git convienne à mes propres besoins. Les fonctionnalités que j'utilisais *moi-même* étaient opérationnelles dès le premier jour. Faire en sorte que Git fonctionne sur Windows était évidemment une étape importante pour beaucoup de développeurs, mais cela n'a eu absolument aucun impact sur *moi* ;)\n\nIl est évident que Git possède toute l'infrastructure nécessaire pour le rendre beaucoup plus facile à utiliser, mais je pense que les étapes majeures ont surtout concerné les projets construits autour de l'infrastructure Git. Ces développements sont par la suite souvent intégrés aux fonctionnalités de Git, mais, en réalité, les étapes clés sont souvent liées à des projets externes.\n\nPar exemple, les grandes plateformes d'hébergement Git ont constitué des étapes importantes. Le modèle distribué de Git a grandement facilité leur création, mais la véritable *étape* a été la façon dont elles ont rendu Git tellement plus accessible et pratique pour les utilisateurs et les équipes travaillant sur divers projets.\n\n**Si vous aviez la possibilité de travailler à nouveau sur Git à plein temps, qu'aimeriez-vous implémenter ?**\n\nAbsolument rien. Git me convenait parfaitement dès le début. Mon utilisation est en fait assez limitée et je ne m'intéresse vraiment qu'à un seul projet.\n\nComme je l'ai expliqué précédemment, je n'ai jamais vraiment été passionné par les SCM. Git a fini par se différencier positivement des autres SCM, car je l'ai traité comme un système de fichiers distribué basé sur les logs, et non comme un SCM traditionnel.\n\n**Y a-t-il une fonctionnalité ou une décision de conception dans Git que vous regrettez avec le recul ?**\n\nDes décisions de conception ? Non. Je suis convaincu que la conception globale est excellente, et vous pouvez discuter des concepts fondamentaux de Git sans jamais vous perdre dans les détails complexes de son implémentation.\n\nIl est essentiel dans un projet d'avoir un certain nombre de principes de conception générale pour guider sa direction conceptuelle.\n\nLes gens pensent parfois que l'étape de mise en œuvre doit suivre aveuglément les principes fondamentaux de la conception générale. Et c'est faux. La *mise en œuvre* aura son lot de cas particuliers compliqués parce les utilisateurs ont des besoins parfois étranges. L'essentiel est de définir une conception générale claire qui servira de référence au projet et à laquelle vous pourrez réfléchir avant de vous confronter à la réalité.\n\nEt je pense que Git offre un équilibre parfait avec un système basique de stockage d'objets (que les experts en contrôle de version appellent  « arbres de Merkle structurés » et que les spécialistes des systèmes de fichiers appellent « stockage avec adressage par contenu »). Cette conception centrale est très simple, mais elle ne représente en réalité qu'une infime partie de la totalité du code du projet. La majeure partie du *code* de Git concerne en effet toutes les opérations et fonctionnalités que l'on peut construire autour de ce modèle central. Malgré cela, cette simplicité et cette clarté fondamentales offrent au projet une structure d'ensemble solide, compréhensible et cohérente. \n\nC'est une structure semblable à celle d'Unix dont le principe est que « tout est un fichier » ou à sa gestion de processus. Ces « concepts » guident la conception, mais 99 % du code a pour objectif de créer des fonctionnalités utiles pour des utilisations concrètes.\n\nJ'ai deux mantras en technologie : « Si j'ai pu voir aussi loin, c'est parce que j'étais juché sur les épaules de géants » (Newton) et « Le génie, c'est 1 % d'inspiration et 99 % de transpiration » (Edison).\n\nBien que je sois très satisfait des grandes lignes de la conception, avec le recul, si je devais développer Git aujourd'hui, je changerais certains détails.\n\nMais honnêtement, ce sont des détails mineurs comparés à toutes les fonctionnalités *de qualité* qui ont été créées par la communauté au cours des deux dernières décennies.\n\n**Le noyau Linux a commencé à utiliser Rust comme langage de programmation pour certains de ses sous-systèmes. Pensez-vous qu'il soit logique de commencer à utiliser des langages de programmation aussi récents que celui-ci dans Git ?**\n\nEn ce qui concerne Git, mélanger les langages n'est pas une bonne idée, car cela reste toujours un processus complexe.\n\nDans le noyau Linux, le résultat final est un binaire unique, même si une grande partie peut être chargée dynamiquement sous forme de modules.\n\nEt cela rend plus difficile l'utilisation de plusieurs langages. En revanche, le noyau doit prendre en compte la sécurité de la mémoire et, par conséquent, envisager d'utiliser des langages plus récents.\n\nSi un développeur veut écrire certaines parties de Git en Rust ou dans un autre langage, il est beaucoup plus logique d'opter pour une mise en œuvre séparée plutôt que de mélanger les différents langages dans un seul binaire.\n\nLa conception du noyau Git est suffisamment simple pour autoriser des implémentations parallèles. Vous pouvez ensuite cibler des cas spécifiques pour lesquels l'utilisation d'un langage différent fait sens.\n\nJGit en est un parfait exemple. L'utilisation d'un autre langage était motivée par la présence d'un environnement web différent pour lequel ce choix de langage était beaucoup plus naturel.\n\nIl existe déjà des implémentations de certaines fonctionnalités Git de base en Rust qui font sens dans des contextes spécifiques, mais je doute que cela justifie une approche globale du type « convertissons tout en Rust ».\n\nJe recommande aux équipes qui souhaitent travailler avec Rust de cibler des domaines où ses avantages sont plus évidents. Je ne pense pas que C ait été si problématique dans le code source standard de Git.\n\n**De nouveaux systèmes de contrôle de version voient le jour tous les deux ou trois ans. Pensez-vous que Git restera pertinent à l'avenir ?**\n\nJ'ai déjà mentionné les effets de réseau dans les SCM. Selon moi, seul un système bien meilleur que Git sera en mesure de le remplacer. Ou alors il sera tellement compatible qu'il s'agira tout simplement d'une nouvelle implémentation de Git.\n\nDe plus, la situation des SCM a beaucoup évolué : Git n'a pas les énormes failles fondamentales des SCM qui l'ont précédé. Il est donc assez difficile de le surpasser.\n\nJe m'attends donc à ce que Git reste pertinent à l'avenir : les développeurs travailleront sur des améliorations *autour* de Git plutôt que de le remplacer par de nouveaux systèmes.\n\n*Remarque : cet entretien a été édité pour en raccourcir la longueur et améliorer la clarté.* \n\n## En savoir plus sur Git\n\n- [Nouveautés de Git 2.49.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-49-0/)  \n- [Nouveautés de Git 2.48.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/)  \n- [Format « reftable » de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Commits Git : comment et pourquoi maintenir un historique propre](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\") \n- [Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/ \"Git fetch vs git pull\") \n- [Git en ligne de commande sous Windows avec Git Bash](https://about.gitlab.com/fr-fr/blog/git-bash/ \"Git Bash\")\n- [Améliorez votre workflow avec Git rebase](https://about.gitlab.com/fr-fr/blog/take-advantage-of-git-rebase/ \"Git rebase\") \n- [Projet Git](https://git-scm.com/)",[683,682],"2025-04-22",{"slug":793,"featured":93,"template":685},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","content:fr-fr:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":799,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":800,"content":806,"config":813,"_id":815,"_type":16,"title":816,"_source":18,"_file":817,"_stem":818,"_extension":21},"/fr-fr/blog/whats-new-in-git-2-49-0",{"title":801,"description":802,"ogTitle":801,"ogDescription":802,"noIndex":6,"ogImage":803,"ogUrl":804,"ogSiteName":740,"ogType":741,"canonicalUrls":804,"schema":805},"Nouveautés de Git 2.49.0","Découvrez la dernière version de Git, y compris les performances améliorées avec l'intégration de zlib-ng et la commande git-backfill(1).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","https://about.gitlab.com/blog/whats-new-in-git-2-49-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.49.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n        \"datePublished\": \"2025-03-14\",\n      }\n                  ",{"title":801,"description":802,"authors":807,"heroImage":803,"date":809,"body":810,"category":14,"tags":811,"updatedDate":812},[808],"Toon Claes","2025-03-14","Le projet [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") a récemment publié sa version [Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large. \n\n## Commande git-backfill(1) associée à la nouvelle API path-walk\n\nLorsque vous exécutez un [`git-clone(1)`](https://git-scm.com/docs/git-clone/fr) d'un dépôt Git, l'option [`--filter`](https://git-scm.com/docs/git-clone/fr#git-clone-code--filterltspcdufiltregtcode) vous permet de créer un _clone partiel_. Dans ce type de clonage, le serveur n'envoie qu'un sous-ensemble des objets accessibles, en fonction du filtre d'objets spécifié. Par exemple, la création d'un clone avec ` --filter=blob:none` signifie que Git ne récupérera pas les blobs (ou contenus de fichiers) auprès du serveur et créera ainsi un _clone blobless_.\n\nLes *clones blobless* sont des clones très légers qui contiennent l'ensemble des commits et des arbres accessibles, mais aucun blob. Lorsque vous effectuez une opération comme [`git-checkout(1)`](https://git-scm.com/docs/git-checkout/fr), Git télécharge les blobs manquants pour exécuter la commande. Cependant, certaines opérations comme [`git-blame(1)`](https://git-scm.com/docs/git-blame/fr) peuvent entraîner un téléchargement séquentiel des objets, ce qui ralentit considérablement leur exécution. Cette dégradation des performances se produit parce que la commande `git-blame(1)` doit parcourir l'historique des commits pour identifier les blobs spécifiques requis, puis les demander un par un au serveur.\n\nPour remédier à cela, Git 2.49.0 introduit une nouvelle sous-commande : `git-backfill(1)`. Elle permet de télécharger les blobs manquants dans un clone partiel blobless.\n\nEn arrière-plan, la commande `git-backfill(1)` tire parti de la nouvelle API path-walk, qui est différente de la méthode traditionnelle d'itération de Git sur les commits. Plutôt que d'itérer sur les commits en les parcourant un par un et de consulter de façon récursive les arbres et les blobs associés à chaque commit, l'API path-walk procède par chemin d'accès. Pour chaque chemin de fichier, elle accumule la liste des objets d'arbre associés à une pile, et cette dernière est ensuite traitée en suivant un parcours en profondeur. Ainsi, plutôt que de traiter chaque objet du commit `1` avant de passer au commit `2`, elle traite toutes les versions du fichier `A` à travers tous les commits avant de passer au fichier `B`. Cette approche améliore considérablement les performances dans les scénarios où le regroupement par chemin est essentiel.\n\nEn guise d'exemple, nous allons créer un clone blobless du dépôt [`gitlab-org/git`](https://gitlab.com/gitlab-org/git) :\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.\nResolving deltas: 100% (161482/161482), done.\n```\n\nDans l'exemple ci-dessus, nous utilisons l'option `--bare` pour nous assurer que Git n'a pas besoin de télécharger de blobs pour effectuer\nle checkout d'une branche initiale. Nous pouvons ensuite vérifier que ce clone ne contient effectivement aucun blob :\n\n```\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\nSi vous souhaitez afficher le contenu d'un fichier dans le dépôt, Git doit le télécharger :\n\n```\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\nComme vous pouvez le voir ci-dessus, Git interroge d'abord le dépôt distant pour télécharger le blob avant de pouvoir l'afficher.\n\nMais si vous souhaitez effectuer une opération `git-blame(1)` sur ce fichier, Git devra télécharger de nombreux autres fichiers :\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\nNous avons tronqué la sortie, mais comme vous pouvez le constater, Git interroge le serveur séparément pour chaque révision de ce fichier. Ce processus est loin d'être optimal. Avec la commande `git-backfill(1)`, nous pouvons demander à Git de télécharger tous les blobs en une seule fois :\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\nCette commande permet de télécharger l'ensemble des blobs, transformant ainsi le clone blobless en un clone complet :\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\nCe [projet](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/)\na été mené par [Derrick Stolee](https://stolee.dev/) et a été fusionné via le commit\n[e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae).\n\n## Intégration de zlib-ng\n\nTous les objets contenus dans le dossier `.git/` sont compressés par Git à l'aide de [`zlib`](https://zlib.net/), la bibliothèque de référence implémentant la spécification [RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950) : ZLIB Compressed Data Format. Créée en 1995, `zlib` bénéficie d'une longue histoire et d'une portabilité incroyable. Elle prend même en charge de nombreux systèmes antérieurs à Internet. En raison de sa compatibilité étendue avec une grande diversité d'architectures et de compilateurs, elle s'accompagne de certaines limites techniques.\n\nPour pallier ces contraintes, une bifurcation nommée [`zlib-ng`](https://github.com/zlib-ng/zlib-ng) a été créée. `zlib-ng` est une version optimisée pour les systèmes modernes. Cette bifurcation abandonne la prise en charge d'anciens systèmes au profit d'optimisations Intel, de certaines optimisations Cloudflare et de quelques autres correctifs plus ciblés.\n\nLa bibliothèque `zlib-ng` elle-même inclut une couche de compatibilité avec `zlib`, permettant \nd'utiliser `zlib-ng` en remplacement immédiat de `zlib`. Toutefois,\ncette couche de compatibilité n'est pas encore disponible sur toutes les distributions Linux. Dans Git 2.49.0 :\n\n- Une couche de compatibilité a été intégrée directement au projet Git.\n- Des options de compilation ont été ajoutées à la fois au fichier [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187) et au [fichier de compilation Meson](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811).\n\nGrâce à ces ajouts, il est plus facile de tirer parti des gains de performances procurés par\n`zlib-ng`.\n\nLors de benchmarks en local, nous avons constaté une accélération d'environ 25 % en utilisant `zlib-ng` au lieu de `zlib`. Nous sommes d'ailleurs en train de déployer progressivement ces améliorations sur\nGitLab.com.\n\nSi vous souhaitez bénéficier des améliorations apportées par `zlib-ng`, vérifiez d'abord si Git\nsur votre machine l'utilise déjà en exécutant la\ncommande `git version --build-options` :\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\nSi la dernière ligne contient `zlib-ng`, votre instance Git est déjà créée\nà l'aide de la variante optimisée de `zlib`. Sinon, vous pouvez :\n\n- Soit demander au chargé de maintenance du paquet Git que vous utilisez d'inclure la prise en charge de `zlib-ng`.\n- Soit compiler Git vous-même à partir de la source.\n\nCes [améliorations](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0)\nont été [introduites](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/)\npar [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Améliorations itératives autour de Meson\n\nDans notre article sur la [version 2.48.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/#syst%C3%A8me-de-compilation-meson \"version 2.48.0 de Git\"), nous avons évoqué l'introduction du système de compilation Meson. [Meson](https://fr.wikipedia.org/wiki/Meson_(logiciel)) est un outil d'automatisation de compilation utilisé par le projet Git qui, à terme, pourrait remplacer [Autoconf](https://fr.wikipedia.org/wiki/Autoconf), [CMake](https://fr.wikipedia.org/wiki/CMake) et peut-être même [Make](https://fr.wikipedia.org/wiki/Make).\n\nAu cours du cycle de développement de la version 2.49.0, nous avons poursuivi notre travail sur l'utilisation de Meson, en ajoutant diverses fonctionnalités manquantes\net des correctifs de stabilisation :\n\n  - [L'amélioration de la couverture de test dans le cadre des\n\tpratiques CI](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/) a été fusionnée dans le commit [72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709).\n  - [Des ajustements pour permettre l'utilisation de Meson dans `contrib/`](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/)\n\tont été fusionnés dans le commit [2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace).\n  - [Des correctifs et améliorations diverses de la procédure de compilation basée sur\n\tMeson](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/) ont été fusionnées dans le commit [ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f).\n  - [La prise en charge par Meson de la compilation\n\tde `git-subtree(1)`](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/) a été fusionnée dans le commit [3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7).\n  - [L'apprentissage par Meson de la génération des pages de la documentation \n\tHTML](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/)\n\ta été fusionné dans le commit [1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694).\n\nL'ensemble de ces contributions a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Retrait définitif des sous-répertoires .git/branches/ et .git/remotes/\n\nVous connaissez probablement l'existence du répertoire `.git` et de son\ncontenu. Mais avez-vous déjà entendu parler des sous-répertoires `.git/branches/` et\n`.git/remotes/` ? Comme vous le savez peut-être, les références aux branches sont stockées dans\n`.git/refs/heads/`, ce n'est donc pas à cela que sert `.git/branches/`, et qu'en est-il de\n`.git/remotes/` ?\n\nEn 2005, le sous-répertoire [`.git/branches/`](https://git-scm.com/docs/git-fetch/fr#_fichier_nomm%C3%A9_dans_git_dirbranches) a été introduit afin de stocker le nom abrégé de dépôts distants, et quelques mois plus tard, ces informations ont été déplacées vers [`.git/remotes/`](https://git-scm.com/docs/git-fetch/fr#_fichier_nomm%C3%A9_dans_git_dirremotes).\nPuis, en [2006](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/),\nà l'aide de la commande [`git-config(1)`](https://git-scm.com/docs/git-config), il a été possible de gérer\nles [dépôts distants](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl) de la même façon que les paramètres de configuration,\nce qui est devenu la méthode standard de configuration des dépôts distants. En 2011, les\nsous-répertoires `.git/branches/` et `.git/remotes/` ont été\n[documentés](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124)\ncomme étant obsolètes. Ils ne sont plus utilisés dans les dépôts modernes.\n\nEnfin en 2024, la documentation [BreakingChanges](https://git-scm.com/docs/BreakingChanges) a été créée pour répertorier les changements cassants de la prochaine version majeure de Git (v3.0). Bien que cette nouvelle version ne soit pas encore planifiée dans un avenir proche, cette documentation permet de suivre les modifications significatives à venir.\n\nDans le commit [8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674), l'utilisation des sous-répertoires `.git/branches/` et `.git/remotes/` a été ajoutée à cette liste, en les marquant officiellement comme obsolètes et voués à être supprimés dans Git 3.0.\n\nMerci à [Patrick Steinhardt](https://gitlab.com/pks-gitlab)\n[d'avoir formalisé ce retrait définitif](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/).\n\n## Ajout de liaisons en Rust pour libgit\n\nLors de la compilation de Git, une bibliothèque interne nommée `libgit.a` est créée. Elle contient certaines des fonctionnalités centrales de Git.\n\nBien que cette bibliothèque (comme la majeure partie de Git) soit écrite en C, la version Git 2.49.0 introduit des liaisons\npour que certaines de ces fonctions deviennent disponibles en langage Rust. Pour ce faire, deux\nnouveaux paquets Cargo ont été créés : `libgit-sys` et `libgit-rs`. Ils\nse trouvent dans le sous-répertoire [`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib) de l'arbre source de Git.\n\nC'est une pratique assez\n[courante](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages)\nde diviser une bibliothèque en deux paquets lorsqu'une [interface de fonction\nétrangère](https://en.wikipedia.org/wiki/Foreign_function_interface) est utilisée.\nLe paquet `libgit-sys` fournit l'interface directe et minimaliste vers les fonctions en C et effectue le lien avec la bibliothèque native `libgit.a`. Le paquet `libgit-rs` fournit une interface de haut niveau plus idiomatique pour Rust vers les fonctions de `libgit-sys`.\n\nJusqu'à présent, les fonctionnalités de ces paquets Rust sont très limitées : ils fournissent uniquement\nune interface d'interaction avec la commande `git-config(1)`.\n\nCette initiative a été menée par [Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/) et a été fusionnée via le commit [a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd).\n\n## Nouvel algorithme de hachage de noms\n\nLa base de données d'objets Git dans `.git/` stocke la plupart de ses données sous forme d'archives empaquetées («packfile»). Ces derniers  sont également utilisés pour transférer des objets entre le serveur et le client Git par le biais du réseau.\n\nPour en savoir plus sur le format de ces fichiers, consultez la documentation [`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack). D'autre part, les archives empaquetées\nutilisent une technique de compression qui a son importance, appelée la compression delta. Avec ce type de compression, tous les objets ne sont pas stockés dans leur intégralité : certains sont enregistrés en tant que _delta_ d'une autre _base_. Ainsi, au lieu d'enregistrer le contenu complet des objets, ce sont les modifications par rapport à un autre objet de référence qui sont stockées.\n\nSans détailler la façon dont ces deltas sont calculés ou stockés, vous vous doutez bien qu'il est essentiel de regrouper les fichiers très similaires pour optimiser la compression. Jusqu'à la \nversion v2.48.0, Git examinait les 16 derniers caractères du nom du chemin d'accès au fichier pour déterminer si les blobs semblaient similaires, à l'aide d'un algorithme nommé « version `1` ».\n\nDans Git 2.49.0, l'algorithme « version `2` » a été introduit. Il s'agit d'une itération de l'algorithme version `1`, mais modifié, de sorte que l'impact du répertoire parent dans le calcul est réduit. Vous pouvez spécifier la version de l'algorithme de hachage de noms à utiliser à l'aide de l'option `--name-hash-version` de la commande [`git-repack(1)`](https://git-scm.com/docs/git-repack/fr).\n\n[Derrick Stolee](https://stolee.dev/), qui a mené ce projet, a effectué une\ncomparaison de la taille des archives empaquetées après exécution de `git repack -adf\n--name-hash-version=\u003Cn>` :\n\n| Dépôt                                          \t| Taille avec la version 1   | Taille avec la version 2 |\n|---------------------------------------------------|-----------|---------|\n| [fluentui](https://github.com/microsoft/fluentui) | 440 Mo \t| 161 Mo   |\n| Dépôt B                                        \t| 6 248 Mo   | 856 Mo   |\n| Dépôt C                                        \t| 37 278 Mo  | 6 921 Mo |\n| Dépôt D                                        \t| 131 204 Mo | 7 463 Mo |\n\nPour en savoir plus, consultez l'[ensemble de\ncorrectifs](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/),\nqui a été fusionné dans le commit\n[aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51).\n\n## Capacité de promisor remote\n\nIl est de notoriété publique que Git ne sait pas très bien gérer les fichiers volumineux. Des solutions comme [Git LFS](https://git-lfs.com/) existent pour résoudre ce problème, mais celles-ci comportent malgré tout certaines lacunes. En voici quelques exemples :\n\n- Avec Git LFS, l'utilisateur doit configurer les fichiers à placer dans LFS. Le serveur n'a\n  aucun contrôle sur ce choix et doit donc servir tous les fichiers.\n- Chaque fois qu'un fichier est validé dans le dépôt, il est impossible de l’enlever du dépôt sans réécrire l'historique. C'est un vrai problème, surtout pour les fichiers volumineux qui sont bloqués pour toujours.\n- Les utilisateurs ne peuvent pas changer d'avis sur quels fichiers sont à placer dans Git LFS.\n- Configurer, apprendre et utiliser de manière optimale un outil comme Git LFS est\n  fastidieux.\n\nDepuis un certain temps, Git a adopté le concept de « promisor remotes ». Cette fonctionnalité pouvant être utilisée pour gérer des fichiers volumineux a été améliorée dans Git 2.49.0.\n\nL'idée de la capacité « promisor remote » est relativement simple : au lieu d'envoyer lui-même tous les objets, un serveur Git peut indiquer au client Git de télécharger ces\nobjets à partir d'un « promisor remote ».\n\nGit 2.49.0 permet désormais au serveur de transmettre les informations du « promisor remote »\nau client. Cette amélioration est une extension du protocole\n[`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2). Pendant l'échange\nde données, le serveur peut ainsi envoyer au client les noms et les URL des « promisor remotes » dont il a connaissance.\n\nJusqu'à présent, le client n'utilise pas les informations du « promisor remote » qu'il reçoit du serveur lors d'un clonage, de sorte que tous les objets sont toujours transmis depuis le dépôt distant à partir duquel le clonage a été initié. Nous envisageons de poursuivre l'optimisation de cette fonctionnalité pour faire en sorte de permettre au client d'utiliser les informations du « promisor remote » du serveur, ainsi que pour simplifier son utilisation.\n\nCet [ensemble de correctifs](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/) a été soumis par [Christian Couder](https://gitlab.com/chriscool) et fusionné via le commit [2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c).\n\n## Clone léger utilisant `--revision`\n\nUne nouvelle option `--revision` a été ajoutée à la commande [`git-clone(1)`](https://git-scm.com/docs/git-clone/fr). Elle vous permet de créer un clone léger d'un dépôt ne contenant que l'historique associé à une révision donnée. Elle fonctionne de manière similaire à `--branch`, mais accepte un nom de référence (comme `refs/heads/main`, `refs/tags/v1.0` et `refs/merge-requests/123`) ou un ID d'objet en hexadécimal d'un commit. La différence avec `--branch` est qu'elle ne crée pas de branche de suivi et le pointeur `HEAD` est détaché. Cette option n'est donc pas adaptée si vous souhaitez contribuer à cette branche.\n\nVous pouvez combiner `--revision` avec `--depth` pour créer un clone minimal, par exemple dans le cadre de tests automatisés. Lorsque vous disposez d'un système CI qui doit effectuer le checkout d'une branche (ou toute autre référence) pour exécuter des tests autonomes sur le code source, un clone minimal suffit largement.\n\nCe [changement](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a) a été [mené](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/) par [Toon Claes](https://gitlab.com/toon).\n\n# En savoir plus\n- [Nouveautés de Git 2.48.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-48-0/)\n- [Nouveautés de Git 2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/)\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)",[272,683,682],"2025-04-10",{"slug":814,"featured":93,"template":685},"whats-new-in-git-2-49-0","content:fr-fr:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","fr-fr/blog/whats-new-in-git-2-49-0.yml","fr-fr/blog/whats-new-in-git-2-49-0",{"_path":820,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":821,"content":827,"config":836,"_id":838,"_type":16,"title":839,"_source":18,"_file":840,"_stem":841,"_extension":21},"/fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":822,"description":823,"ogTitle":822,"ogDescription":823,"noIndex":6,"ogImage":824,"ogUrl":825,"ogSiteName":740,"ogType":741,"canonicalUrls":825,"schema":826},"Comment utiliser les images OCI comme source unique de vérité pour vos déploiements continus","Découvrez les avantages d'intégrer les images OCI (Open Container Initiative) dans vos workflows GitOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment utiliser les images OCI comme source unique de vérité pour vos déploiements continus\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":822,"description":823,"authors":828,"heroImage":824,"date":830,"body":831,"category":14,"tags":832,"updatedDate":835},[829],"Daniel Helfand","2025-02-19","Est-il encore approprié d'employer le terme [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/) si vous ne déployez plus directement depuis un dépôt Git ? Git reste au cœur des workflows GitOps, c'est indéniable. Pourtant, de plus en plus d'équipes de développement choisissent de stocker leurs configurations d'infrastructure sous forme d'artefacts OCI (Open Container Initiative) dans des registres de conteneurs. Cette pratique gagne du terrain en tant que nouvelle source unique de vérité pour les déploiements GitOps. Découvrez dans cet article les raisons qui motivent cette tendance et comment les fonctionnalités de GitLab soutiennent cette amélioration des workflows GitOps. \n\n## Qu'est-ce que la pratique GitOps ?\n\nLe projet [OpenGitOps](https://opengitops.dev/) définit [quatre principes](https://opengitops.dev/#principles) qui encadrent la pratique GitOps :\n- Un [système géré par GitOps](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system) doit [exprimer son état désiré de manière déclarative](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description).\n- Cet état désiré doit être stocké dans un système garantissant l'immuabilité et la gestion des versions, et conserver un historique complet des versions.\n- Des agents logiciels doivent pouvoir effectuer automatiquement un pull des déclarations de l'état désiré depuis la source.\n- Ils doivent surveiller [en continu](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) l'état réel du système et [tenter de le faire converger vers l'état désiré](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nUn exemple concret de pratique GitOps consiste à stocker les manifestes [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \") d'un microservice dans un projet GitLab. Ces ressources Kubernetes sont ensuite continuellement synchronisées par un [contrôleur](https://kubernetes.io/docs/concepts/architecture/controller/) s'exécutant sur le cluster Kubernetes hébergeant le microservice. Ainsi, les équipes de développement sont en mesure de gérer l'infrastructure avec les mêmes workflows que pour du code applicatif : ouverture de merge requests afin d'examiner et de valider les modifications et gestion des versions. La pratique GitOps présente également de nombreux avantages opérationnels. Par exemple, elle permet de [prévenir la dérive de configuration](https://about.gitlab.com/fr-fr/topics/gitops/#cicd) et facilite l'audit des modifications ayant conduit à un certain état du système ou à un incident lors des déploiements. \n\n## Avantages et limites de Git dans les workflows GitOps\n\nGit est sans conteste un composant essentiel des workflows GitOps. Cependant, les dépôts Git n'ont pas été conçus pour être utilisés directement par des contrôleurs GitOps lors des déploiements. Git offre aux équipes de développement la possibilité de collaborer sur les modifications d'infrastructure et d'auditer ces dernières ultérieurement, mais les contrôleurs GitOps n'ont pas besoin de récupérer l'intégralité d'un dépôt Git pour réussir un déploiement. Il leur suffit d'accéder aux définitions d'infrastructure spécifiques à un environnement donné. \n\nDe plus, un autre aspect important du processus de déploiement consiste à [signer et vérifier les déploiements](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing) pour garantir que les modifications en lien avec un déploiement, apportées à un environnement, proviennent d'une source de confiance. Bien que les commit Git puissent effectivement être signés et vérifiés par les contrôleurs GitOps, ils peuvent également inclure des éléments sans lien direct avec le déploiement (par exemple, des modifications de documentation, des mises à jour pour d'autres environnements, ou une restructuration du dépôt Git) ou offrir une image de déploiement incomplète, car un déploiement peut être constitué de plusieurs commits. Là encore, il semble que cette fonctionnalité Git ne soit pas en adéquation avec les exigences spécifiques du déploiement continu.  \n\nLes workflows GitOps basés sur Git peuvent parfois conduire à un excès d'automatisation, ce qui peut être problématique. Par exemple, dès qu'une modification est fusionnée dans une branche surveillée, elle est déployée immédiatement. Il n'y a aucun mécanisme de contrôle dans le processus en dehors de Git. Comment avoir la certitude d'empêcher le déclenchement d'un déploiement un vendredi en fin d'après-midi ? Que se passe-t-il si les équipes responsables du déploiement ne disposent pas des autorisations nécessaires pour fusionner les modifications dans certains projets GitLab ? L'utilisation d'images OCI ajoute une étape intermédiaire au processus : un pipeline intégré au workflow. Celui-ci inclut toutes les fonctionnalités nécessaires au contrôle de la livraison, telles que des [approbations ou le gel des déploiements](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## Les images OCI\n\nL'[Open Container Initiative](https://opencontainers.org/) a contribué à définir des normes relatives aux formats de conteneurs. Bien que la plupart des équipes de développement aient l'habitude de créer des images de conteneurs à partir d'un fichier Dockerfiles, beaucoup ne sont peut-être pas aussi familiers avec le stockage des manifestes Kubernetes dans un registre de conteneurs. Étant donné que le [registre de conteneurs de GitLab](https://docs.gitlab.com/ee/user/packages/container_registry/) est conforme à la norme OCI, il permet aux utilisateurs d'effectuer le push des manifestes Kubernetes liés à un environnement particulier directement dans le registre de conteneurs. Au lieu de cloner un dépôt Git complet, les contrôleurs GitOps, tels que [Flux CD](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), peuvent désormais récupérer uniquement l'artefact OCI contenant les manifestes nécessaires au déploiement. \n\nDans de nombreux workflows GitOps, un même dépôt Git regroupe les configurations d'infrastructure pour tous les environnements cibles dans lesquels un [microservice](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ? \") sera déployé. En empaquetant uniquement les manifestes Kubernetes liés à un environnement spécifique dans une image OCI, Flux CD télécharge les fichiers strictement nécessaires au déploiement dans cet environnement spécifique. \n\n### Les atouts sécurité des artefacts OCI\n\nComme mentionné précédemment, signer et vérifier les artefacts à déployer dans un environnement ajoutent une couche de sécurité supplémentaire aux projets de développement logiciel. Une fois que les manifestes Kubernetes font l'objet d'un push dans un registre de conteneurs, un outil comme [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) peut être utilisé pour signer l'image OCI avec une clé privée, stockée en toute sécurité dans un projet GitLab en tant que [variable CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/ \"Variables CI/CD\"). Flux CD peut ensuite utiliser une clé publique stockée sur un cluster Kubernetes pour vérifier et garantir que le déploiement provient d'une source fiable. \n\n## Push et signature des images OCI avec GitLab \n\nGitLab offre de nombreuses fonctionnalités qui simplifient le processus d'empaquetage, de signature et de déploiement d'images OCI dans des workflows GitOps. Une pratique courante consiste à structurer les projets GitLab en séparant le code des microservices d’un côté, et le dépôt de l’infrastructure de déploiement de l’autre. Ainsi, pour une application composée de `n` microservices, il est fréquent d'avoir `n +1` projets GitLab.\n\nLe projet de code produit généralement un artefact sous forme d'image de conteneur qui sera utilisée pour empaqueter l'application. Le projet d'infrastructure (aussi appelé projet de livraison) contient, quant à lui, les manifestes Kubernetes définissant toutes les ressources nécessaires pour que chaque microservice puisse monter en charge, recevoir et traiter le trafic des utilisateurs. L'artefact découlant de ce projet est généralement une image OCI servant à déployer l'application et d'autres manifestes sur Kubernetes. \n\nDans cette configuration, la séparation des environnements est gérée en définissant des manifestes Kubernetes dans des dossiers distincts représentant les environnements (par exemple, de développement, de préproduction et de production) qui hébergeront l'application. Lorsque des modifications sont apportées au code d'un microservice et qu'une nouvelle image de conteneur fait l'objet d'un push, il suffit alors de mettre à jour la référence de cette image dans le manifeste situé dans le dossier correspondant à l'environnement cible, puis de créer une merge request pour déployer ces modifications via l'intégration de GitLab avec Flux CD. Une fois cette merge request examinée, approuvée et fusionnée, le job CI/CD du projet de livraison déclenche le push d'une nouvelle image OCI que Flux CD récupérera et déploiera dans le nouvel environnement.\n\n![Images OCI - schéma du workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nPour signer une image OCI, il vous suffit d'intégrer Cosign dans le job CI/CD de votre projet et de générer une nouvelle paire de clés publique/privée avec Cosign en exécutant localement les commandes ci-dessous. Veillez simplement à vous connecter à votre instance GitLab via l'[interface de ligne de commande glab](https://gitlab.com/gitlab-org/cli/#installation) et remplacez la variable [`PROJECT_ID`] dans la commande Cosign par l'[ID de votre projet de livraison](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id).   \n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nUne fois la commande Cosign exécutée avec succès, les clés Cosign seront ajoutées à votre projet dans la section des variables CI/CD, sous les noms de clés `COSIGN_PUBLIC_KEY` et `COSIGN_PRIVATE_KEY`.\n\n### Exemple de job CI/CD\n\nVoici à quoi ressemblera un job GitLab CI/CD permettant d'effectuer un push d'une image OCI :\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\nLe [catalogue GitLab CI/CD](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) comprend un [composant CI/CD maintenu par GitLab pour travailler avec les artefacts OCI et Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). Ce composant permet aux équipes de développement d'effectuer un push des manifestes Kubernetes sous forme d'images OCI vers le registre de conteneurs de GitLab ou dans un registre de conteneurs externe, de signer ces image OCI à l'aide de Cosign et d'en déclencher immédiatement la synchronisation via Flux CD. \n\nDans l'exemple ci-dessus, le `component` Flux CD est inclus dans un fichier `.gitlab-ci.yml` d'un projet GitLab. À l'aide aux paramètres `inputs` du composant, les utilisateurs peuvent définir le registre de destination pour l'image (`registry_image_url` et `image tag`), le chemin d'accès aux manifestes Kubernetes qui feront l'objet d'un push (`manifest_path`), la clé privée Cosign utilisée pour signer l'image (`signing_private_key`), ainsi que l'espace de nommage Kubernetes et le nom de l'[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/) de Flux CD nécessaires pour synchroniser les mises à jour vers l'environnement de déploiement (`flux_oci_namespace_name` et `flux_oci_repo_name`).\n\nLa variable `kubernetes_agent_reference` permet aux jobs GitLab CI/CD d'hériter automatiquement de la variable `kubeconfig` nécessaire pour accéder à un cluster Kubernetes, sans avoir à stocker manuellement une variable CI/CD `kubeconfig` dans chaque projet GitLab. En configurant [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/), vous pouvez configurer les jobs CI/CD de tous les projets GitLab dans un [groupe GitLab](https://docs.gitlab.com/ee/user/group/) et faire en sorte qu'ils héritent des autorisations nécessaires pour déployer sur le cluster Kubernetes. \n\nVous pouvez configurer le contexte de GitLab Agent for Kubernetes au même endroit que la configuration de GitLab Agent for Kubernetes dans votre groupe GitLab. Il est toutefois recommandé d'effectuer ces modifications dans le projet qui gère Flux CD. Pour en savoir plus sur la configuration de GitLab Agent pour l'accès CI/CD, consultez notre [documentation dédiée au workflow CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nPar ailleurs, les variables `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME`, et `$FRONTEND_DEV_NAMESPACE` sont des variables CI/CD qui contiennent des données sensibles. Elles sont stockées tout en masquant leur contenu dans les logs CI/CD. Enfin, la variable `$CI_REGISTRY_IMAGE` est disponible par défaut dans tous les jobs GitLab et spécifie le registre de conteneurs associé au projet GitLab. \n\n### Déploiement des images OCI\n\nEn intégrant [Flux CD à vos projets GitLab](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html), vous pouvez automatiser les déploiements ainsi que la vérification des signatures pour les environnements de vos microservices. Une fois que Flux CD est configuré pour se synchroniser avec un projet GitLab, vous pouvez simplement ajouter les [définitions de ressources personnalisées](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) Kubernetes suivantes à votre projet pour synchroniser votre image OCI dont le push a été effectué. \n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n```   \n\nLa ressource [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) permet de personnaliser davantage les manifestes Kubernetes, tout en spécifiant l'espace de nommage dans lequel déployer les ressources. La ressource `OCIRepository` de Flux CD, quant à elle, permet de spécifier la référence et le tag du dépôt d'images OCI à synchroniser régulièrement. Vous remarquerez également les champs `verify.provider` et `verify.secretRef` : ils permettent de vérifier que l'image OCI déployée sur le cluster a bien été signée avec la clé privée Cosign correspondante, utilisée précédemment dans le job CI/CD. \n\nLa clé publique correspondante doit être stockée dans un [secret Kubernetes](https://kubernetes.io/fr/docs/concepts/configuration/secret/) qui doit être présent dans le même espace de nommage que la ressource `OCIRepository`. Pour que ce secret soit géré par Flux CD et non stocké en texte brut, vous pouvez utiliser [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) pour chiffrer sa valeur et la faire déchiffrer côté cluster par un contrôleur. \n\nSi vous souhaitez opter pour une approche plus simple sans SealedSecrets, vous pouvez [déployer le secret via un job GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) à l'aide de l'[interface de ligne de commande `kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). Il vous suffit alors de supprimer le SealedSecret inclus dans la configuration ci-dessus et d'exécuter un job CI/CD pour déployer le secret de clé publique avant de lancer le job qui effectuera un push de la nouvelle image OCI. Cette opération permet de stocker le secret en toute sécurité dans GitLab et d'y accéder sur le cluster par le biais de la ressource OCIRepository. Cependant, bien qu'elle soit moins complexe, cette approche ne permet pas de gérer les secrets en environnement de production. \n\n## Les avantages combinés des artefacts OCI, de GitLab et de GitOps\n\nLes artefacts OCI permettent aux équipes GitOps d'affiner leurs déploiements avec un niveau de sécurité renforcé et une approche plus minimaliste, sans priver les utilisateurs des atouts de Git, notamment une source unique de vérité et une collaboration efficace. Les images OCI introduisent une méthode d'empaquetage optimisée qui améliore le déploiement au sein des workflows GitOps.\n\nGitLab continue de s'améliorer grâce aux retours de ses clients et de la communauté cloud-native dans le but de simplifier les workflows GitOps. Pour tester les fonctionnalités présentées dans cet article, vous pouvez commencer par un [essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/). Nous serions ravis de connaître votre avis suite à l'utilisation de ces outils. Alors, n'hésitez pas à nous faire part de vos retours d'expérience sur le [forum de la communauté GitLab](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965).\n",[111,683,833,539,682,834],"kubernetes","tutorial","2025-05-09",{"slug":837,"featured":6,"template":685},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:fr-fr:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":843,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":844,"content":850,"config":857,"_id":859,"_type":16,"title":860,"_source":18,"_file":861,"_stem":862,"_extension":21},"/fr-fr/blog/what-is-a-hackathon",{"title":845,"description":846,"ogTitle":845,"ogDescription":846,"noIndex":6,"ogImage":847,"ogUrl":848,"ogSiteName":740,"ogType":741,"canonicalUrls":848,"schema":849},"Hackathon : les clés pour une organisation réussie","Découvrez les tenants et aboutissants d'un hackathon et obtenez des astuces pour le mettre en place avec efficacité. Découvrez notre guide détaillé.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663517/Blog/Hero%20Images/hackathon.jpg","https://about.gitlab.com/blog/what-is-a-hackathon","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hackathon : les clés pour une organisation réussie\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2025-02-05\",\n      }",{"title":845,"description":846,"authors":851,"heroImage":847,"date":852,"body":853,"category":14,"tags":854,"updatedDate":856},[745],"2025-02-05","Au fil des années, les hackathons ont gagné en popularité en tant que catalyseurs d'innovation et de collaboration. Dans cet article, nous aborderons l'organisation des hackathons, ainsi que les avantages qu'ils offrent aux participants et aux organisateurs. Explorons ensemble l'univers des hackathons.\n\n> [Participez au prochain hackathon GitLab qui se déroulera du 10 au 17 avril 2025](https://about.gitlab.com/community/hackathon/ \"Hackathon GitLab\"). \n\n## Qu'est-ce qu'un hackathon ?\n\nUn hackathon est un événement collaboratif où des individus se réunissent pour travailler ensemble sur des projets innovants pendant une période définie, allant généralement de quelques heures à quelques jours. Durant un hackathon, les participants forment des équipes pour concevoir, développer et présenter des solutions concrètes à des problèmes spécifiques ou pour explorer de nouvelles idées. \n\n## Quel est l'objectif d'un hackathon ?\n\nL'objectif principal d'un hackathon est de favoriser la créativité, l'apprentissage et l'innovation. C'est un environnement propice à l'expérimentation et à la collaboration entre des personnes aux compétences variées. Mais alors qui organisent généralement les hackathons ? Une multitude d'acteurs peuvent être à l'origine de l'organisation d'un hackathon. Cela peut être des entreprises, des universités, des organisations à but non lucratif ou encore des communautés technologiques.\n\n## Pourquoi organiser un hackathon ?\n\nVous l'avez peut-être déjà remarqué, mais l'intérêt pour les hackathons a connu une croissance significative ces dernières années. Pas étonnant lorsque l'on sait que ces événements offrent aux participants et aux organisateurs un nombre d'avantages importants tant sur le plan de l'innovation que du développement des compétences ou des communautés de professionnels. \n\nEn définitive, que ce soit pour développer de nouvelles idées, identifier des talents émergents ou renforcer les relations professionnelles, un hackathon représente un certain nombre d’avantages. \n\n- **Résolution de problèmes concrets** : les hackathons abordent souvent des défis auxquels sont confrontées les entreprises. Les projets développés lors des hackathons peuvent avoir un impact réel et contribuer à résoudre des problèmes importants qu'elles rencontrent.\n\n- **Stimulation de l'innovation** : de par leur nature, les hackathons encouragent la créativité et l'innovation en offrant un cadre où les personnes participantes peuvent explorer de nouvelles idées, développer des solutions originales et innover. \n\n- **Création de prototypes** : les hackathons fournissent une occasion unique de développer rapidement des prototypes fonctionnels ou des démonstrations de concept. Ainsi, les entreprises gagnent un temps précieux en matière de recherche et de développement, ce qui leur permet d'accélérer la création de logiciels.  \n\n- **Levier marketing** : véritables leviers marketing, les hackathons contribuent à améliorer la notoriété des entreprises. Ces événements permettent de mettre en avant leur expertise, leurs valeurs et leur engagement en faveur de l'innovation. \n\n- **Networking** : les hackathons sont idéaux pour échanger entre professionnels. Ces interactions favorisent l'établissement de contacts précieux et l'ouverture de portes vers des collaborations futures et de potentielles opportunités de recrutement.  \n\nLes participants ne sont pas en reste non plus. Ces derniers tirent également des bénéfices significatifs de leur participation aux hackathons. Bien que les participants ne soient généralement pas rémunérés, les hackathons leur offrent l'opportunité de développer leurs compétences, de se familiariser avec la collaboration interdisciplinaire, d'élargir leur réseau professionnel ou encore de remporter des prix et dotations pour leur participation. \n\n## Comment organiser un hackathon ?\n\nOrganiser un hackathon nécessite une planification minutieuse et une gestion efficace pour garantir le succès de votre événement. Mais alors, comment faire en pratique ? \n\n**Préparation initiale**\n- Une bonne organisation commence toujours par une bonne préparation. Prenez le temps de définir clairement le thème et les objectifs de votre hackathon. Définissez-les de manière simple et concise.\n- Constituez une équipe organisatrice et assurez-vous de définir les rôles et responsabilités de chacun.\n- Définissez un budget précis pour l'organisation du hackathon et prospectez des sponsors potentiels afin de garantir le financement et le rayonnement de votre événement.\n\n**Campagne de communication**\n- Concevez une stratégie de communication pour promouvoir l'événement et recruter les participants. Assurez-vous de mettre en avant à la fois vos valeurs, mais aussi les gains que peuvent ressortir du hackathon pour toutes les parties prenantes.\n- Identifiez les cibles de votre campagne de communication et comment les atteindre. \n- Créez du contenu attrayant sur vos réseaux sociaux pour promouvoir votre évènement et maximiser le recrutement de participants.\n- Contactez des communautés de développeurs pour leur faire savoir que vous organisez un hackathon. Les membres de ces groupes sont très actifs et feront d’excellents alliés pour relayer votre événement. \n\n**Gestion de l'événement et logistique**\n\nPour les hackathons en ligne : \n- Sélectionnez une plateforme adaptée aux hackathons en ligne qui puisse permettre aux candidats de soumettre leur projet et aux juges de suivre l’avancement et l'évaluation des projets.\n- Pensez à choisir et mettre en place des outils de communication efficaces pour faciliter la communication entre les candidats mais aussi les organisateurs. Discord et Slack sont de bons exemples.\n- Fournissez aux participants les ressources nécessaires et assurez vous qu'ils ont bien accès à tous les outils et logiciels requis pour le développement de leurs projets.\n- Mettez en place un support disponible 24/7 pour répondre aux questions et aider les équipes participantes en cas de problème. \n\nPour les hackathons en présentiels : \n- Sélectionnez et aménagez un lieu approprié en fonction du nombre de participants prévus. Définissez clairement vos besoins en termes d'espace et d'équipements pour accueillir confortablement tous les participants.\n- Assurez-vous de fournir une infrastructure technique fiable et adaptée aux besoins du hackathon, comprenant notamment un accès internet robuste, des équipements informatiques nécessaires, et tout autre matériel requis pour les projets.\n- N'oubliez pas de ravitailler les troupes ! Prévoyez des repas et des collations pour les équipes participantes afin de garantir leur confort et leur concentration tout au long de l'événement. \n\n**Suivi des candidats et des projets**\n- Gérez les inscriptions de manière rigoureuse et transparente, en veillant à ce que le processus de sélection des participants soit équitable et bien organisé.\n- Organisez les projets et les sessions de travail en équipe de manière à maximiser la productivité et la créativité des équipes participantes. \n- Définissez clairement les objectifs de chaque projet et assurez-vous que les équipes disposent des ressources nécessaires pour réussir.\n- Fournissez un soutien technique et des conseils professionnels tout au long de l'événement. Soyez disponible pour répondre aux questions, résoudre les problèmes techniques et offrir des idées pour optimiser les résultats des projets.\n\n**Organisation de la finale**\n- Sélectionnez avec soin les projets finalistes qui seront présentés devant un jury d'experts. Qui d'autres de mieux que des experts reconnus pour juger de la qualité des propositions des équipes ?\n- Assurez-vous que les critères de sélection soient clairs et transparents pour garantir l'équité du processus.\n- Planifiez minutieusement la présentation des projets lors de la finale. Définissez un ordre de passage optimal et prévoyez suffisamment de temps pour que chaque équipe puisse présenter son travail de manière complète et convaincante.\n- Animez la finale de manière dynamique. Cela aura pour effet de maintenir un haut niveau d'engagement et d'enthousiasme parmi les équipes participantes, mais aussi les juges et le public. \n\n**Remise des prix**\n- Offrez des prix attrayants qui motivent et récompensent les participants, tels que des bons d’achat, des opportunités de mentorat avec des experts du domaine, ou des ressources matérielles et logicielles pour concrétiser leurs idées.\n- Planifiez et organisez une cérémonie de remise des prix pour mettre en valeur les réalisations des gagnants. \n\n**Suivi post-projet** \n- Faites le plein de feedbacks pertinents. Collectez des retours d'expérience et analysez les résultats pour améliorer vos prochaines éditions. \n\n> Participez au prochain hackathon GitLab qui aura lieu le 10 avril prochain. [Inscrivez-vous dès maintenant](https://about.gitlab.com/community/hackathon/) !   \n\n## FAQ sur les hackathons\n\n### Pourquoi faire un hackathon ?\n\nLes hackathons offrent une opportunité unique de stimuler l'innovation en réunissant des personnes aux compétences diverses pour résoudre des défis de manière collaborative. Ils favorisent le développement de nouvelles idées, la collaboration et l'apprentissage.\n\n### Quels sont les types de hackathon ?\n\nIl existe de nombreux types de hackathons en fonction de leur objectif et de leur domaine d'application. Pour ne citer que quelques exemples, certains hackathons pourront se spécialiser sur des domaines comme le développement logiciel ou encore le design. Chaque type se concentre sur des défis spécifiques et attire des participants ayant des intérêts et des compétences particuliers.\n\n### Un hackathon peut-il être organisé en ligne ?\n\nOui, il est possible de faire un hackathon en ligne en utilisant des plateformes virtuelles et des outils de collaboration. Cette approche permet d'atteindre un public plus large et de faciliter la participation à distance, tout en offrant une expérience similaire à celle d'un hackathon en présentiel.\n",[272,855,683],"collaboration","2025-03-20",{"slug":858,"featured":6,"template":685},"what-is-a-hackathon","content:fr-fr:blog:what-is-a-hackathon.yml","What Is A Hackathon","fr-fr/blog/what-is-a-hackathon.yml","fr-fr/blog/what-is-a-hackathon",{"_path":864,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":865,"content":871,"config":878,"_id":880,"_type":16,"title":881,"_source":18,"_file":882,"_stem":883,"_extension":21},"/fr-fr/blog/whats-new-in-git-2-48-0",{"title":866,"description":867,"ogTitle":866,"ogDescription":867,"noIndex":6,"ogImage":868,"ogUrl":869,"ogSiteName":740,"ogType":741,"canonicalUrls":869,"schema":870},"Nouveautés de Git 2.48.0","Découvrez la dernière version de Git, y compris un nouveau système de compilation ainsi que des optimisations dans le nouveau backend « reftable ».","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.48.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }",{"title":866,"description":867,"authors":872,"heroImage":868,"date":874,"body":875,"category":14,"tags":876,"updatedDate":877},[873],"Christian Couder","2025-01-10","Le projet Git a récemment publié la [version 2.48.0 de Git](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Système de compilation Meson\n\nPendant longtemps, [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") pouvait être compilé en utilisant un système de compilation basé sur des [Makefile](https://fr.wikipedia.org/wiki/Make) ou sur [Autoconf](https://fr.wikipedia.org/wiki/Autoconf). Les équipes de développement Git utilisaient principalement le système de compilation basé sur des Makefile.\n[Le système de compilation basé sur Autoconf a donc pris du retard](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/) en termes de fonctionnalités et de maintenance. Autre problème : de nombreux développeurs Windows utilisaient des environnements de développement intégrés (IDE) qui ne\nprenaient pas correctement en charge les systèmes de compilation basés sur des Makefile et Autoconf.\n\nDepuis 2020, il est possible de compiler Git à l'aide de [CMake](https://cmake.org/). CMake a permis une meilleure prise en charge de Windows et une meilleure intégration avec les IDE, en particulier Visual Studio. Il a également apporté certaines fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.\n\nRécemment, il est apparu que la prise en charge de CMake était également à la traîne\net que cette option pourrait ne jamais remplacer les deux autres\nsystèmes de compilation de manière satisfaisante. C'est pourquoi [Patrick Steinhardt](https://gitlab.com/pks-gitlab), Git Engineering Manager chez GitLab, a mis en œuvre la prise en charge du système de compilation [Meson](https://mesonbuild.com/)\ndans le but de remplacer à terme les systèmes de compilation basés sur Autoconf, CMake et peut-être même les Makefile.\n\nLe nouveau système de compilation basé sur Meson présente les avantages suivants :\n* Il permet aux utilisateurs de trouver facilement les options de compilation disponibles, ce qui est difficile avec les Makefile et CMake.\n* Sa syntaxe est plus simple que celles d'Autoconf et de CMake.\n* Il prend en charge de nombreux systèmes d'exploitation, compilateurs et IDE différents.\n* Il prend en charge les fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.\n\nVoici un exemple qui montre comment l'utiliser pour compiler Git :\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\nPlusieurs répertoires de compilation peuvent être configurés à l'aide de `meson setup \u003Cbuild_dir>`. La configuration de la compilation dans un répertoire de compilation peut être affichée ou modifiée en exécutant `meson configure` à l'intérieur de ce répertoire.\n\nVous trouverez plus d'informations sur la façon de compiler Git à l'aide de Meson en haut du [fichier `meson.build`](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build) dans le dépôt de code Git. Une\n[comparaison des différents systèmes de compilation](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt) pour Git est disponible dans la documentation technique de Git.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Git est maintenant exempt de fuites de mémoire (tel que vérifié par la suite de tests)\n\nDans notre article présentant la version Git 2.47.0 précédente, nous\navons évoqué nos [efforts constants pour corriger toutes les fuites de mémoire](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/#r%C3%A9usinage-du-code-et-am%C3%A9lioration-de-la-maintenabilit%C3%A9) mises en évidence par les tests existants dans le projet. Comme nous l'avons souligné, avant la version 2.47.0 de Git, le projet comptait 223 fichiers de test contenant des fuites de mémoire.\nCe nombre avait été réduit à seulement 60.\n\nNous avons le plaisir d'annoncer que les fuites de mémoire dans ces 60 fichiers de test restants ont été résolues. En conséquence, Git, tel qu'il est vérifié par la suite de tests, est désormais exempt de fuites de mémoire. Il s'agit d'une étape importante menant vers notre objectif de longue date de partitionner les composants internes de Git en une bibliothèque de composants. Cette amélioration aidera également à optimiser l'utilisation de la mémoire avec Git.\n\nTout test nouvellement ajouté doit désormais être exempt de fuites de mémoire par défaut. Il demeure possible d'exécuter des tests contenant des fuites de mémoire, mais les auteurs devront demander une exception pour cela et justifier pourquoi leur test ne peut pas être exempt de fuites de mémoire.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Amélioration des vérifications du bundle URI\n\nDans notre article présentant la version 2.46.0 de Git, nous avons mentionné\ncertaines [corrections du bundle URI](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/#correction-du-bundle-uri)\napportées par [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/).\nUne fois ces corrections implémentées, le travail de Xing Xin a rendu possible la [vérification complète des récupérations à l'aide de bundles](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/)\nen utilisant le mécanisme [fsck](https://git-scm.com/docs/git-fsck/fr) comme s'il s'agissait de récupérations standard.\n\nLors de la validation des récupérations standard, il est possible de spécifier\n[différents niveaux de gravité](https://git-scm.com/docs/git-fsck/fr) pour [différents problèmes fsck](https://git-scm.com/docs/git-fsck/fr#_messages_fsck).\nLa gestion de ce qui est accepté ou rejeté dans un dépôt spécifique s'en trouve affinée. Cela n'était auparavant pas possible pour les récupérations à l'aide de bundles.\n\nPour renforcer encore l'utilité et la sécurité du [bundle-uri](https://git-scm.com/docs/bundle-uri), nous avons [résolu ce problème](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/). Les différents niveaux de gravité indiqués pour différents problèmes fsck sont désormais\négalement utilisés lors de la vérification des récupérations à l'aide de bundles.\n\nCe projet a été mené par [Justin Tobler](https://gitlab.com/justintobler).\n\n## Ajout des vérifications de cohérence des références\n\nDans notre article présentant la version 2.47.0 de Git, nous avons mentionné\nle travail de Jialuo She sur [l'ajout d'une nouvelle sous-commande « verify »](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/#nouvelle-sous-commande-pour-git-refs(1)) à git-refs(1) dans le cadre du [Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) (GSoC 2024).\n\nNous avions alors déclaré que l'objectif était à terme d'intégrer cette nouvelle sous-commande à git-fsck(1) afin de fournir un moyen unifié d'exécuter les vérifications de cohérence des dépôts. Jialuo She a décidé de travailler sur ce sujet à l'issue du GSoC.\n\nLe résultat de [cet effort](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/)\nest que git-fsck(1) peut maintenant détecter et gérer un certain nombre de problèmes liés aux références, par exemple, lorsque le contenu est de mauvaise qualité, lorsqu'un lien symbolique est utilisé comme référence symbolique ou lorsque la cible d'une référence symbolique ne pointe pas vers une référence valide. Il nous reste toujours à appeler `git refs verify` via git-fsck(1), et demander à la commande d'effectuer toutes les vérifications non spécifiques au backend dans le processus en cours git-fsck(1). Toutefois, nous avons progressé vers notre objectif final qui est de disposer d'un moyen unifié d'exécuter toutes les vérifications de cohérence des références.\n\nCe projet a été mené par Jialuo She.\n\n## Réutilisation des itérateurs dans les « reftables »\n\nDans la version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt), le format « reftable » a été introduit en tant que nouveau backend pour stocker des références (principalement des branches et des tags). Si le backend « reftable » ne vous est pas encore\nfamilier, n'hésitez pas à consulter notre précédent [article de blog consacré à la version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/). Nous y présentons ce nouveau format, ainsi que notre guide intitulé [Format reftable de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nNous avons depuis continué à améliorer ce backend. Récemment, nous nous sommes concentrés sur l'amélioration de ses performances en [réutilisant certains itérateurs internes](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/) lors de la lecture de références aléatoires. Avant ces changements, la lecture d'une seule référence nous obligeait à créer un tout nouvel itérateur, à le déplacer au bon endroit dans les tables respectives, puis à lire la valeur suivante. Cette démarche se révèle assez inefficace lors de la lecture en succession rapide de nombreuses références. Nous ne créons désormais plus qu'un seul itérateur et le réutilisons pour lire plusieurs références, ce qui permet d'alléger le travail effectué.\n\nLes performances dans un certain nombre de cas d'utilisation liés aux « reftables » sont par conséquent améliorées. Nous avons notamment mesuré une accélération de 7 % lors de la création de nombreuses références dans une transaction qui effectue de nombreuses lectures aléatoires. Notre travail ouvre de plus la porte à davantage d'optimisations, car nous pouvons continuer à réutiliser une plus grande quantité d'états conservés dans les itérateurs.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Prise en charge des reflogs dans `git-refs migrate`\n\nSuite à l'introduction du backend « reftable » dans Git 2.45.0, nous avons travaillé sur des outils pour migrer les backends de gestion des références dans Git 2.46.0. Il s'agissait d'ajouter une nouvelle sous-commande `migrate` à git-refs(1).\n\nNotre article consacré à Git 2.46.0 [décrivait cette tâche](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/#outils-pour-migrer-les-backends-de-r%C3%A9f%C3%A9rences) et mentionnait certaines limitations encore présentes. L'article soulignait notamment les points suivants :\n\n« Les reflogs dans un dépôt font partie du backend de gestion des références et nécessitent également une migration lors du changement de format. Malheureusement, l'outil n'est pas encore capable de convertir les reflogs entre les backends « fichiers » et les backends « reftable ». »\n\nNous sommes heureux d'annoncer que nous avons [levé cette limitation dans la version Git 2.48.0](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/).\nLes reflogs peuvent désormais également être migrés avec `git refs migrate`. L'outil de migration n'est pas encore capable de gérer un dépôt contenant des arbres de travail séparés (« worktrees »), mais il s'agit de la dernière limitation restante. Si vous n'utilisez pas d'arbres de travail séparés (« worktrees »), vous pouvez déjà utiliser le backend « reftable » dans vos dépôts existants.\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Optimisation du filtre des références\n\nLe sous-système 'ref-filter' est un code de mise en forme utilisé par des commandes telles que `git for-each-ref`, `git branch` et `git tag` pour trier, filtrer, mettre en forme et afficher les informations relatives aux références Git.\n\nÀ mesure que les dépôts se développent, la quantité de références qu'ils contiennent peut devenir astronomique. C'est pourquoi nous avons du travail à faire non seulement pour améliorer les backends qui stockent des références, comme le backend « reftable » (voir ci-dessus), mais\naussi pour optimiser le code de mise en forme, comme le sous-système 'ref-filter'.\n\nNous avons récemment [trouvé une méthode](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/)\npour éviter de mettre temporairement les références en mémoire tampon et de les traiter chacune plusieurs fois dans le code de filtrage des références. Désormais, celles-ci sont traitées directement dans l'ordre de tri fourni par les backends. Cette amélioration réduit la consommation de mémoire et accélère certaines commandes, pouvant les rendre jusqu'à 770 fois plus rapides dans certains\ncas.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git au sens large pour cette nouvelle version. \n\nVous pouvez approfondir ce sujet en lisant l'annonce officielle du projet Git et en consultant [nos précédents articles de blog sur les nouvelles versions de Git](https://about.gitlab.com/blog/tags/git/).\n\n- [Nouveautés de Git 2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/)\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)\n- [Nouveautés de Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/)\n- [Format reftable de Git : guide pour les débutants](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n",[682,683,272],"2025-01-20",{"slug":879,"featured":93,"template":685},"whats-new-in-git-2-48-0","content:fr-fr:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","fr-fr/blog/whats-new-in-git-2-48-0.yml","fr-fr/blog/whats-new-in-git-2-48-0",{"_path":885,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":886,"content":892,"config":900,"_id":902,"_type":16,"title":903,"_source":18,"_file":904,"_stem":905,"_extension":21},"/fr-fr/blog/how-gitlab-empowers-translators-with-more-context",{"title":887,"description":888,"ogTitle":887,"ogDescription":888,"noIndex":6,"ogImage":889,"ogUrl":890,"ogSiteName":740,"ogType":741,"canonicalUrls":890,"schema":891},"Comment GitLab facilite la compréhension du contexte pour les traducteurs","Découvrez notre nouvelle fonctionnalité d'amélioration du contexte de traduction et rejoignez notre communauté de traducteurs.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment GitLab facilite la compréhension du contexte pour les traducteurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":887,"description":888,"authors":893,"heroImage":889,"date":895,"body":896,"category":14,"tags":897,"updatedDate":899},[894],"Oleksandr Pysaryuk","2024-12-09","Notre communauté mondiale s'investit sans relâche pour traduire GitLab. Les traducteurs et relecteurs utilisent [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html) pour rendre notre produit disponible dans 78 langues. La communauté de traduction GitLab est composée de traducteurs et relecteurs bénévoles, de professionnels qui utilisent GitLab et même d'[étudiants qui contribuent dans le cadre de projets académiques](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### Le modèle open core de GitLab pour la traduction\n\nLa collaboration entre les membres de la communauté a beau porter ses fruits, les traducteurs se heurtent souvent à un défi majeur : comprendre le contexte du texte qu'ils ont sous les yeux.\n\nBien traduire, ce n'est pas seulement remplacer un mot par un autre dans une autre langue. C'est aussi préserver le sens, l'intention et la clarté dans la langue cible. La traduction de logiciels nécessite une combinaison unique de compétences. Les bons traducteurs se spécialisent généralement dans plusieurs domaines linguistiques et maîtrisent également le domaine technique du produit lui-même. \n\nIls effectuent de nombreuses tâches adjacentes à la traduction, telles que :\n* assurer l'exactitude et la cohérence de la terminologie technique\n* ajouter des termes au glossaire pour de nouveaux concepts\n* respecter le style et le ton\n* appliquer correctement les [règles de pluralisation CLDR](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html) complexes\n* comprendre la traductibilité des messages composites et fournir des retours pour améliorer la source afin de faciliter sa localisation\n\nLes traducteurs consacrent une grande partie de leur temps à analyser le contexte, à poser des questions et à consulter la [documentation produit de GitLab](https://docs.gitlab.com/). Sans contexte approprié, même des phrases simples peuvent être mal traduites, ce qui peut dérouter les utilisateurs ou perturber leurs workflows. [GitLab se distingue par son modèle open core](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/) qui permet aux traducteurs d'accéder au contexte de développement du produit directement à la source, dans la plupart des cas. Cette transparence leur permet d'être de véritables [co-créateurs du produit GitLab](https://handbook.gitlab.com/handbook/company/mission/#mission) et de contribuer activement à son amélioration continue.\n\n### Notre nouvelle fonctionnalité d'amélioration du contexte\n\nPour répondre à ces besoins et offrir un contexte précis aux traducteurs, GitLab a développé une nouvelle fonctionnalité : nous [intégrons désormais un lien contextuel dans chaque chaîne traduisible](https://docs.gitlab.com/ee/development/i18n/translation.html#context). Il s'agit plus précisément d'un lien vers notre recherche globale dans le produit. Celui-ci permet aux traducteurs de trouver toutes les instances d'une chaîne dans le code base. Ils ont ainsi la possibilité de s'appuyer sur [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) pour retracer l'historique de chaque chaîne, de son emplacement actuel dans le code et des validations dans les merge requests jusqu'aux discussions de planification initiales.\n\nPrenons par exemple la traduction de **Rotate**. L'[espace de nommage](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) **AccessTokens|** suggère qu'il s'agit dans ce contexte de *jetons d'accès*. Cependant, sans contexte visuel supplémentaire sur la signification de **Rotate**, les traducteurs ne peuvent que s'interroger, deviner et fournir la meilleure hypothèse possible dans la langue cible.\n\nGrâce à la nouvelle fonctionnalité d'amélioration du contexte, les traducteurs peuvent désormais :\n\n1. Cliquer sur l'URL dans la section **See where this string is used in code**.\n\n![voir où cette chaîne est utilisée dans la section du code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Consulter le [résultat de la recherche dans le code](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), puis cliquer sur l'icône **View blame** :\n\n![Écran affichant l'icône View blame](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Cliquer sur le lien pour accéder à la merge request pertinente ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)) :\n\n![Lien amenant à la merge request pertinente](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. Sur la page **Validations**, cliquer sur le lien vers la merge request pertinente :\n\n![Page Validations avec le lien](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Consulter l'enregistrement d'écran que le développeur a ajouté à la merge request :\n\n![enregistrement d'écran dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Poursuivre leur recherche en accédant :  \n   a. Au ticket associé [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) ou à l'epic parent [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563) :\n\n![ticket associé et epic parent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. À la [merge request associée qui met à jour la documentation du produit GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916) :\n\n![merge request associée pour mettre à jour la documentation du produit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nToutes ces étapes de recherche permettent aux traducteurs de mieux comprendre le concept technique de *rotation des jetons d'accès*, ainsi que les raisons pour lesquelles cette fonctionnalité a été ajoutée, son fonctionnement et le problème qu'elle résout.\n\nGrâce à cette piste de recherche approfondie, les traducteurs obtiennent autant de contexte que possible pour fournir une traduction technique précise et linguistiquement correcte du terme **Rotate**, en apparence simple.\n\nCette approche surpasse les aides à la traduction traditionnelles, comme les captures d'écran ou l'accès à l'interface utilisateur du produit. Les traducteurs peuvent désormais comprendre pleinement le contexte en :\n\n* le déduisant des informations à partir des chemins d'accès et des conventions de nommage dans le code\n* consultant les captures d'écran ou enregistrements vidéo ajoutés aux merge requests initiales\n* consultant les discussions initiales de planification et de développement\n* retraçant le processus de prise de décision en matière d'ingénierie, de rédaction et de gestion des produits qui a conduit à une formulation spécifique\n\n### Plus de fonctionnalités contextuelles alimentées par l'IA seront bientôt disponibles\n\nL'équipe Globalization & Localization de GitLab ne compte pas s'arrêter là. Nous développons [d'autres fonctionnalités d'amélioration du contexte](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), y compris des outils basés sur l'IA conçus pour aider les traducteurs à comprendre l'utilisation et le placement des chaînes. Notre objectif est de créer un système interactif dans lequel les traducteurs pourraient dialoguer avec un agent, poser des questions ou recevoir des réponses de manière proactive et immédiate, adaptées au code, sur l'emplacement et l'usage des chaînes dans l'interface utilisateur du produit.\n\n> ##### Rejoignez notre [communauté sur Crowdin](https://docs.gitlab.com/ee/development/i18n/) en tant que traducteur ou [relecteur](https://docs.gitlab.com/ee/development/i18n/#proofreading). Essayez nos nouvelles fonctionnalités contextuelles et dites-nous comment nous pouvons encore améliorer [l'expérience de traduction et notre produit](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[272,855,701,898],"contributors","2025-02-03",{"slug":901,"featured":6,"template":685},"how-gitlab-empowers-translators-with-more-context","content:fr-fr:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","fr-fr/blog/how-gitlab-empowers-translators-with-more-context.yml","fr-fr/blog/how-gitlab-empowers-translators-with-more-context",{"_path":907,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":908,"content":914,"config":919,"_id":921,"_type":16,"title":922,"_source":18,"_file":923,"_stem":924,"_extension":21},"/fr-fr/blog/git-bash",{"title":909,"description":910,"ogTitle":909,"ogDescription":910,"noIndex":6,"ogImage":911,"ogUrl":912,"ogSiteName":740,"ogType":741,"canonicalUrls":912,"schema":913},"Git en ligne de commande sous Windows avec Git Bash","Dans cet article, découvrez Git Bash, son fonctionnement, son installation et les principales commandes à connaître.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665174/Blog/Hero%20Images/git-bash.jpg","https://about.gitlab.com/blog/git-bash","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git en ligne de commande sous Windows avec Git Bash\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-10-24\",\n      }",{"title":909,"description":910,"authors":915,"heroImage":911,"date":916,"body":917,"category":14,"tags":918},[745],"2024-10-24","Les commandes Git permettent aux développeurs de gérer différentes versions du code et de collaborer en équipe. Si vous évoluez dans un environnement Windows, vous avez peut-être déjà entendu parler de Git Bash, un émulateur de terminal Bash comprenant une version de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), adaptée à Windows. Découvrez dans notre article tout ce que vous devez savoir sur l'installation de Git Bash.\n\n## Comment fonctionne Git Bash ?\n\nGit Bash est une application que vous pouvez installer sur les systèmes d'exploitation Windows à l’aide de Git for Windows. Cette application agit comme un émulateur pour utiliser l'[outil de contrôle de version Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"outil de contrôle de version Git\") sur un terminal de commandes Bash. \n\nBash est l'acronyme de Bourne Again Shell. Shell désigne l'application de terminal de commande d'un système d'exploitation (OS). Bourne Again Shell est en réalité une version améliorée de Bourne Shell (aussi désignée comme shell sh), l'interface en ligne de commandes pour UNIX développée par Stephen Bourne en 1977.\n\nBash est le shell par défaut pour les systèmes d'exploitation Linux et MacOS. Grâce à Git Bash, les utilisateurs de Windows peuvent installer Bash, exécuter des commandes Bash et utiliser des commandes Git.\n\n## Comment installer Git Bash ?\n\nPour télécharger Git Bash, il est nécessaire d’installer Git for Windows. Pour ce faire, rendez-vous sur le site officiel de [Git for Windows](https://gitforwindows.org/ \"Git for Windows\") et cliquez sur « Download » pour installer le package Git complet. Lorsque le téléchargement est terminé, ouvrez le fichier en .exe et commencez l'installation.\n\nPour installer Git Bash sur Windows, veuillez suivre ces instructions pas à pas :\n\n1. Ouvrez le fichier .exe puis cliquez sur « Next ». Sélectionnez le dossier adéquat pour l'installation. \n\n2. Acceptez les conditions d'utilisation, puis cliquez sur « Next » pour lancer l'installation.\n\n3. À cette étape, sélectionnez les composants à installer. Les réglages présélectionnés sont pertinents, mais vous pouvez les modifier selon vos préférences. Cliquez à nouveau sur « Next ».\n\n4. Ensuite, choisissez l'éditeur que vous préférez utiliser avec Git. L'outil reconnaît les éditeurs déjà installés sur votre ordinateur.\n\n5. Une fenêtre s'affiche avec trois paramétrages de l'environnement PATH. En fonction de vos besoins, choisissez si Git ne doit être utilisé que par Git Bash ou si vous souhaitez l'utiliser depuis d'autres logiciels tiers.\n\n6. Enfin, conservez les réglages par défaut en cliquant sur « Next » et installez Git Bash en cliquant sur « Install ».\n\n## Quelles sont les commandes Bash ?\n\nTout d'abord, la commande `pwd` (Print Working Directory) permet de visualiser le chemin absolu. Cela signifie qu'elle affiche le chemin d'accès du dossier dans lequel nous nous trouvons au moment de taper la commande. \n\n__À retenir :__ lorsque vous ouvrez le terminal Git Bash, vous vous situez dans un dossier de votre ordinateur. Généralement, il s'agit du dossier portant votre nom d'utilisateur. \n\nLa commande `ls` donne accès à la liste de fichiers présents dans le dossier actuel. Vous pouvez également ajouter des options à la commande `ls` grâce à un tiret `-`. Par exemple, l'option `-l` après `ls` liste le contenu d'un dossier avec plus d'informations sur chaque fichier. \n\nBash dispose aussi d'une commande `cd` (Change Directory) pour se déplacer dans votre ordinateur. Pour indiquer le répertoire dans lequel vous souhaitez vous rendre, veuillez préciser le chemin relatif ou absolu après `cd`. Le chemin relatif correspond à l'emplacement par rapport au répertoire courant tandis que le chemin absolu correspond à son emplacement par rapport au dossier racine. \n\n## Comment utiliser Git Bash avec GitLab ?\n\nUtiliser Git Bash avec [GitLab](https://about.gitlab.com/fr-fr/ \"GitLab\") revient à utiliser l'émulateur de terminal avec une autre plateforme de gestion de code source. Afin de pousser et de récupérer vos modifications depuis GitLab, ajoutez l'URL de votre dépôt distant GitLab grâce à la commande : `git remote add origin \u003Crepository_url>`.\n\nSi votre projet est privé, Git Bash vous demande de vous authentifier. Entrez vos identifiants lorsque le terminal demande votre nom d'utilisateur et votre mot de passe. Si vous rencontrez des problèmes d'identification, vérifiez vos paramètres d'autorisation directement dans GitLab.\n\nUtilisez ensuite les commandes de base Git comme `git clone`, [git commit](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Commits Git\"), `git push`, `git branch` ainsi que `git checkout`, pour n'en citer que quelques-unes. Pour en savoir plus, consultez notre [Git Cheat Sheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf \"Git Cheat Sheet de GitLab \"). \n\n### FAQ sur Git Bash\n\n### Git Bash et GitLab sont-ils compatibles ?\n\nOui. L'utilisation de Git Bash avec GitLab est similaire au fonctionnement avec une autre plateforme de gestion de code source. Veillez à configurer GitLab comme dépôt distant et à vous authentifier lors du paramétrage initial. \n\n### Pourquoi utiliser Git Bash ?\n\nGit Bash agit comme un émulateur de terminal pour utiliser les commandes Git et Bash dans un environnement Windows.\n\n### Quel est l’intérêt d’un shell ?\n\nL’utilisation d’un shell permet d’automatiser des tâches grâce à des scripts, de contrôler efficacement son ordinateur et de bénéficier d’un accès direct aux fonctions du système.\n",[682,683],{"slug":920,"featured":6,"template":685},"git-bash","content:fr-fr:blog:git-bash.yml","Git Bash","fr-fr/blog/git-bash.yml","fr-fr/blog/git-bash",{"_path":926,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":927,"content":933,"config":939,"_id":941,"_type":16,"title":942,"_source":18,"_file":943,"_stem":944,"_extension":21},"/fr-fr/blog/what-is-git",{"title":928,"description":929,"ogTitle":928,"ogDescription":929,"noIndex":6,"ogImage":930,"ogUrl":931,"ogSiteName":740,"ogType":741,"canonicalUrls":931,"schema":932},"Qu'est-ce que Git ? Guide complet sur son rôle et son fonctionnement","Vous voulez réaliser vos projets avec Git ? Découvrez tous ses avantages et son fonctionnement dans notre guide complet, disponible dès maintenant.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687231/Blog/Hero%20Images/Git.jpg","https://about.gitlab.com/blog/what-is-git","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu'est-ce que Git ? Guide complet sur son rôle et son fonctionnement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":928,"description":929,"authors":934,"heroImage":930,"date":936,"body":937,"category":14,"tags":938},[935],"GitLab Team","2024-10-08","Git est un outil incontournable dans le monde du développement logiciel moderne. Dans ce guide complet nous vous expliquons en détail ce qu'est l'outil Git, son rôle dans la gestion des versions d’un code source, et son fonctionnement. Que vous soyez débutant ou expérimenté, ce guide vous fournira une compréhension approfondie de Git et de ses nombreuses fonctionnalités.\n\n__Sommaire__\n- Qu'est-ce que Git ?\n- Quelles sont les fonctionnalités de Git ?\n- Quels sont les avantages de Git ?\n- Quelles sont les principales commandes de Git ?\n- Git et GitLab\n\n## Qu'est-ce que Git ?\n\nGit est un outil de contrôle de version qui est rapidement devenu incontournable dans l'écosystème du développement logiciel. Grâce à sa capacité à conserver un historique minutieux des modifications apportées sur un projet, Git représente un allié précieux pour tout développeur soucieux de gérer efficacement ses projets. Maîtriser Git est, de ce fait, maintenant une compétence essentielle à connaître pour quiconque souhaite exceller dans le domaine du développement logiciel. \n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n### Qu’est-ce que le contrôle de version ?\n\nLe [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Contrôle de version\") permet de suivre les modifications apportées au code source d'un logiciel. Ainsi, la version livrée d’un logiciel, est composée d'un ensemble de versions spécifiques de chacun de ses composants et fichiers de code source. Par exemple, une icône pourrait n’avoir été changée que deux fois, tandis qu’un fichier de code aurait pu subir plusieurs dizaines de modifications au fil du temps.\n\n![Contrôle de version Git](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749688210/Blog/Content%20Images/controle-de-version-git.png)\n\n## Quelles sont les fonctionnalités de Git ?\n\nDans le développement, il est important de maintenir une gestion rigoureuse des modifications apportées au code source d'un logiciel. Sans cela, il est impossible de garantir la cohérence et la fiabilité du travail réalisé par les équipes de développement. Une gestion fine des évolutions peut également permettre d’identifier plus facilement la source d’un problème. De même, elle réduit les risques de conflits et d’écrasement de fichiers. Or, faciliter et fluidifier la gestion des versions d'un logiciel est précisément ce à quoi Git sert.\n\nAfin de mieux comprendre Git et son fonctionnement, nous avons réuni ci-dessous quelques-unes des fonctionnalités clés qui facilitent l'optimisation de la gestion du code source ainsi que la collaboration entre les équipes. \n\n### Une visualisation de l'historique de vos projets\n\nDans l'écosystème de développement logiciel, [l'historique de commits](https://about.gitlab.com/fr-fr/blog/keeping-git-commit-history-clean/ \"Historique de commits Git\") représente un pilier fondamental pour le suivi de l'évolution d'un projet sur Git. C'est pourquoi Git offre aux développeurs et développeuses un historique détaillé de tous les changements apportés au code source. \n\nÀ chaque nouveau commit sont enregistrés :\n\n- les modifications spécifiques effectuées sur les fichiers du projet,\n- un message explicatif de la part du développeur ou de la développeuse à l'origine de la modification,\n\nCes éléments contribuent à améliorer la communication et la mission de l'équipe de développement, qui peut alors comprendre plus rapidement les tenants et les aboutissants de chaque modification apportée au code.\n\nEn plus de suivre les évolutions du projet, cet historique permet de revenir en arrière si nécessaire, d’annuler une partie des modifications ou au contraire de récupérer seulement une partie des modifications d’une branche vers une autre. Cette fonction joue donc un rôle essentiel pour maintenir la transparence, la cohérence et la qualité du code source d'un projet dans Git, mais également la collaboration au sein de l’équipe de développement et l’efficacité opérationnelle pour résoudre des problèmes.\n\nConsultez notre article pour [créer votre premier commit Git](https://docs.gitlab.com/ee/tutorials/make_first_git_commit/ \"Création d'un commit Git\").  \n\n### Une meilleure autonomie des équipes\n\nAutre fonctionnalité essentielle de l'outil Git : le développement distribué (ou [Distributed development](https://git-scm.com/about/distributed \"Développement distribué de Git\") en anglais). Grâce à sa structure décentralisée, Git permet aux équipes de développement de travailler simultanément sur un même projet. Chaque membre d’une équipe dispose de sa propre copie du projet, où chacune de ses modifications peuvent être versionnées. Ce qui leur permet de travailler de manière autonome sur des fonctionnalités spécifiques, tout en réduisant les risques de conflit ou d'écrasement. Cette approche offre une grande flexibilité aux développeurs et développeuses qui peuvent alors explorer différentes idées ou expérimenter de nouvelles fonctionnalités sans interférer avec le travail de leurs collègues. \n\nLe développement distribué permet aussi d'être plus résilient face aux pannes de serveur. Ainsi, même en cas de défaillance, chaque personne dispose d'une copie sur laquelle il peut continuer de travailler hors ligne. Les modifications pourront ensuite être synchronisées une fois le serveur de nouveau disponible, réduisant de fait les risques d’interruption de travail pour les équipes de développement et les contraintes de mise à jour pour les équipes opérationnelles.\n\n### Une optimisation des workflows de développement\n\nLes fonctionnalités de [gestion des branches et de leurs fusions](https://git-scm.com/about/branching-and-merging \"Gestion des branches et de leurs fusions\") (branching et merging) sont parmi les caractéristiques les plus puissantes de Git. Elles permettent aux équipes de travailler en parallèle de manière collaborative et organisée. Chaque nouvel ajout de code ou correction de bug peut être développé et testé indépendamment pour s'assurer de leur fiabilité. Les développeurs et développeuses n'ont ensuite qu'à fusionner les modifications apportées dans la branche principale du projet.\n\nEn adoptant cette approche, les équipes peuvent suivre l'évolution du code, collaborer facilement et efficacement, réduire les conflits entre les différentes versions et assurer une intégration continue des fonctionnalités développées.\n\nEn utilisant ces deux fonctionnalités, les équipes sont en mesure de développer des projets en continu et de manière agile, tout en déployant régulièrement de nouvelles versions de code. Cette pratique facilite grandement la gestion des modifications tout en réduisant les risques d'erreurs.\n\n## Quels sont les avantages de Git ?\n\nPour bien comprendre Git, il est important de saisir pleinement les avantages que son utilisation apporte à vos équipes de développement :\n\n- __Une gestion décentralisée des versions :__ avec Git, chaque développeur dispose d'une copie complète de l'historique du projet, ce qui permet de travailler en parfaite autonomie.\n\n- __Un outil conçu autour de la sécurité :__ contrairement à d’autres outils de contrôle de version, Git a été conçu dès sa création pour garantir l’intégrité de tous les éléments du dépôt avec un algorithme de hachage de sécurité cryptographique (SHA1 et SHA-256 à ce jour). Cet algorithme a pour objectif de protéger le code et l’historique d’un projet contre toute modification, qu’elle soit malveillante ou non. En complément, chaque commit (création d’une nouvelle version) peut être signé automatiquement (GPG) pour garantir la traçabilité des modifications. Cela fait de Git un outil particulièrement sécurisé et sécurisant, qui garantit l’intégrité et l’authenticité de votre code source et de son historique.\n\n- __Un outil rapide et efficace :__ l'outil Git a été conçu pour maximiser l'efficacité au cours du développement. Sa rapidité permet aux développeurs et développeuses d'exécuter des opérations complexes, telles que les commits, le branching et le merging, en un temps minimal, même sur des bases de code volumineuses. Il assure également une empreinte minimale sur le disque dur et lors des échanges réseaux. Cette efficacité se traduit alors par un temps de réponse rapide lors des sauvegardes, des consultations et des modifications de l'historique du projet.\n\n- __Une plus grande flexibilité de travail :__ Git prend en charge une grande variété de workflows de développement. Que vous préfériez des modèles de développement centralisés ou des approches plus linéaires, Git s'adapte facilement. Cette capacité à gérer différents workflows laisse aux équipes un large choix quant à la méthode de travail à adopter.\n\n- __Facilité d'intégration :__ Git se distingue par sa capacité à s'intégrer avec une multitude d'outils et de plateformes de développement existants. L'étendue de cette compatibilité permet aux équipes de gérer plus efficacement leurs projets en tirant parti des meilleurs outils et pratiques DevSecOps.\n\n- __Un projet open source très suivi :__ autre avantage non négligeable de Git, c'est un projet open source qui bénéficie d'une communauté dynamique et engagée veillant à son évolution constante. Cette participation active des personnes, mais également des entreprises membres de la communauté Git garantit l'ajout régulier de nouvelles fonctionnalités et améliorations grâce à des mises à jour régulières.\n\n## Quelles sont les principales commandes de Git ?\n\nLe projet [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu’est-ce que l’open source ?\") Git propose une grande variété de commandes pour faciliter le travail des équipes. \n\nVoici quelques-unes des commandes les plus couramment utilisées.\n\n- `git init` : initialiser un nouveau dépôt Git.\n- `git clone [url]` : cloner un dépôt existant.\n- `git add [fichier]` : ajouter un fichier à l'index.\n- `git commit` : valider les modifications apportées.\n- `git commit -m \"message\"` : valider les changements avec un message.\n- `git status` : afficher l'état des fichiers dans le répertoire de travail.\n- `git push` : envoyer les modifications vers le dépôt distant.\n- `git pull` : récupérer les modifications du dépôt distant et les fusionner avec le dépôt local.\n\nBien que ces commandes soient essentielles pour démarrer avec Git, il est important de noter qu'il existe beaucoup d'autres commandes. Consultez la [liste des commandes Git](https://git-scm.com/docs/git/fr#_commandes_git \"Liste des commandes Git\").\n\n## Git et GitLab\n\nGitLab est une plateforme collaborative de développement open source qui couvre toutes les étapes du cycle de vie DevSecOps et offre un serveur Git permettant aux équipes de collaborer ensemble et efficacement. \n\nAu delà de la gestion du code source, GitLab offre une suite complète, permettant d’exécuter l’intégration et la distribution en continue, la gestion des livrables, la gestion de la sécurité et des incidents, ainsi que toute la traçabilité associée, la planification et le suivi des tâches en temps réel, le monitoring des déploiements, la gestion des versions logicielles et l’espace documentaire associé.\n\n> [Essayez GitLab Ultimate gratuitement.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial \"Essai gratuit de GitLab.\") \n\n## FAQ sur Git\n\n### Pourquoi utiliser Git ?\n\nGit est entièrement axé sur l'efficacité. Grâce au système décentralisé de Git, reposant sur des fonctionnalités de branching et de merging, les équipes de développement travaillent sur un même projet sans interférer avec le travail des autres, et surtout sans créer de conflits de versions.\n\n### Est-ce que Git est un logiciel ?\n\nGit est un projet open source. À ce titre, son accès est gratuit et ouvert à tous. Il convient cependant d'[installer Git](https://docs.gitlab.com/ee/topics/git/how_to_install_git/ \"Installation de Git\") au préalable sur votre machine pour pouvoir commencer à travailler.\n\n### Qu'est ce qu'une branche dans Git ?\n\nDans Git, une branche représente un pointeur vers un historique de modifications. Ainsi, chaque branche principale pointe vers le dernier commit effectué sur celle-ci. Il est donc possible d’avoir une multitude de branches en parallèle, chacune ayant son propre historique, mais toutes ayant la même racine.\n\n### Qu'est-ce qu'un commit ?\n\nDans Git, un commit correspond à un enregistrement des modifications apportées au code source d'un logiciel. Chaque commit est accompagné d'un message explicatif qui trace l'historique de toutes les modifications. Le suivi d'évolution d'un projet devient plus facile, et il existe toujours la possibilité de revenir à des versions antérieures fonctionnelles en cas de problème.\n\n### Quel est l'intérêt des branches dans Git ?\n\nLe développement de fonctionnalités dans des branches autorise les développeurs et développeuses à travailler simultanément sur plusieurs fonctionnalités distinctes. De plus, cela évite de compromettre la branche principale (main) avec du code instable. L'implémentation des branches dans Git est, par ailleurs, nettement plus légère que dans d'autres systèmes de contrôle de version.\n",[682,683],{"slug":940,"featured":93,"template":685},"what-is-git","content:fr-fr:blog:what-is-git.yml","What Is Git","fr-fr/blog/what-is-git.yml","fr-fr/blog/what-is-git",{"_path":946,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":947,"content":952,"config":958,"_id":960,"_type":16,"title":961,"_source":18,"_file":962,"_stem":963,"_extension":21},"/fr-fr/blog/whats-new-in-git-2-47-0",{"title":948,"description":949,"ogTitle":948,"ogDescription":949,"noIndex":6,"ogImage":868,"ogUrl":950,"ogSiteName":740,"ogType":741,"canonicalUrls":950,"schema":951},"Nouveautés de Git 2.47.0","Découvrez les contributions de l'équipe Git de GitLab et de la communauté Git au sens large à la dernière version de Git.","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.47.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":948,"description":949,"authors":953,"heroImage":868,"date":954,"body":955,"category":14,"tags":956,"updatedDate":957},[724],"2024-10-07","Le projet Git a récemment publié la [version 2.47.0 de Git](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/). Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Nouvelles options de configuration globales\n\nSi vous suivez les dernières versions de Git, vous avez sûrement entendu parler du nouveau backend « reftable » introduit dans la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/). \n\nAuparavant, pour initialiser un dépôt au [format « reftable »](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable de Git\"), il fallait transmettre l'option `--ref-format` à git-init(1) :\n\n```sh\n$ git init --ref-format reftable\n```\n\nAvec la nouvelle version 2.47, Git dispose désormais de l'option de configuration `init.defaultRefFormat`,\nlaquelle indique à Git quel backend de gestion des références utiliser lors de l'initialisation d'un\ndépôt. Cette dernière peut être utilisée pour remplacer le backend « fichiers » par défaut et commencer à utiliser le backend « reftable ». Pour la configuration, procédez comme suit :\n\n```sh\n$ git config set --global init.defaultRefFormat reftable\n```\n\nComme certains d'entre vous le savent peut-être déjà, le format de hachage d'objets utilisé par les dépôts Git est\négalement configurable. Par défaut, les dépôts sont initialisés pour utiliser le\nformat d'objet SHA-1. Il existe toutefois une alternative, le format SHA-256, qui offre davantage de sécurité et qui est plus évolutif. Pour en savoir plus, consultez notre \n[article dédié à la prise en charge de SHA-256 dans Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F). Pour créer un dépôt SHA-256, vous devez transmettre l'option `--object-format` à git-init(1) :\n\n```sh\n$ git init --object-format sha256\n```\n\nCette nouvelle version de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") inclut une autre option de configuration : `init.defaultObjectFormat` qui indique à Git le format d'objet à utiliser par défaut lors de l'initialisation d'un dépôt. Pour la configuration, procédez comme suit :\n\n```sh\n$ git config set --global init.defaultObjectFormat sha256\n```\n\nIl convient de noter que les dépôts SHA-256 ne sont pas interopérables avec les dépôts SHA-1\net que toutes les forges logicielles ne prennent pas en charge l'hébergement de dépôts SHA-256. GitLab\na récemment annoncé une [prise en charge expérimentale pour les dépôts SHA-256](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) pour celles et ceux qui souhaitent l'essayer.\n\nCes options fournissent un mécanisme utile pour commencer à utiliser ces fonctionnalités\nde dépôt plus simplement lors de l'initialisation d'un nouveau dépôt.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Nouvelle sous-commande pour git-refs(1)\n\nLa précédente version de Git avait introduit la commande [git-refs(1)](https://git-scm.com/docs/git-refs) afin d'offrir un accès plus direct aux références d'un\ndépôt et fournissait la sous-commande « migrate » pour basculer d'un backend de gestion des références à un autre. Cette nouvelle version 2.47.0 introduit une nouvelle sous-commande « verify », qui permet à l'utilisateur de vérifier la cohérence de la base de données qui gère les références. Pour procéder à cette vérification dans un dépôt, il est courant d'utiliser la commande [git-fsck(1)](https://git-scm.com/docs/git-fsck/fr).\n\nCette commande ne vérifie cependant pas explicitement la base de données qui gère les références du dépôt. Avec l'introduction du format de référence « reftable », lequel est un format binaire et donc plus difficile à inspecter manuellement, il est désormais encore plus important de mettre en place des outils pour combler cette lacune. Démontrons ce fait en configurant un dépôt avec une référence invalide :\n\n```sh\n# The \"files\" backend is used so we can easily create an invalid reference.\n$ git init --ref-format files\n$ git commit --allow-empty -m \"init\"\n# A lone '@' is not a valid reference name.\n$ cp .git/refs/heads/main .git/refs/heads/@\n$ git refs verify\nerror: refs/heads/@: badRefName: invalid refname format\n```\n\nNous constatons effectivement que la référence invalide a été détectée et qu'un message d'erreur a été envoyé à l'utilisateur. Bien que cet outil ne soit probablement pas destiné à être utilisé par l'utilisateur final, il est particulièrement utile côté serveur pour garantir la cohérence des dépôts. À terme, l'objectif est d'intégrer cette commande à git-fsck(1) afin de fournir un moyen unifié d'exécuter les contrôles de cohérence des dépôts.\n\nCe projet a été mené par Jialuo She dans le cadre du programme Google Summer of Code. Pour\nen savoir plus, consultez le [rapport du GSoC de Jialuo She](https://luolibrary.com/2024/08/25/GSoC-Final-Report/).\n\n## Améliorations relatives aux reftables\n\nCette nouvelle version inclut également des corrections pour certains bogues détectés dans le backend « reftable ». L'un d'entre eux est particulièrement intéressant et concerne la manière dont le compactage des tables était effectué.\n\nComme vous vous en souvenez peut-être, le backend « reftable » consiste en une série de tables\ncontenant l'état de toutes les références dans le dépôt. Chaque opération atomique de modifications de références entraîne l'écriture d'une nouvelle table, laquelle est alors enregistrée dans le fichier « tables.list ». Pour réduire le nombre de tables présentes, les tables sont compactées pour suivre une séquence géométrique en fonction de la taille du fichier après chaque mise à jour des références. Une fois les tables compactées, le fichier « tables.list » est mis à jour pour refléter le nouvel état des reftables sur le disque.\n\nPar conception, l'écriture et le compactage simultanés des tables sont autorisés. La synchronisation à certains moments est contrôlée par l'utilisation de fichiers de verrouillage. Par exemple, lorsque le compactage commence, le fichier « tables.list » est d'abord verrouillé afin qu'il puisse être lu de manière cohérente, et les tables nécessitant un compactage peuvent également être verrouillées. Comme le compactage des tables peut prendre un certain temps, le verrouillage est levé et les écritures simultanées peuvent alors commencer. Cette méthode est sûre, car les processus d’écriture simultanés savent qu'ils ne doivent pas modifier les tables verrouillées sur le point d'être compactées. Une fois que les nouvelles tables compactées ont été écrites, le fichier « tables.list » est à nouveau verrouillé et est, cette fois-ci, mis à jour pour refléter le nouvel état des tables.\n\nUn problème subsiste cependant : que se passe-t-il si une mise à jour de référence simultanée écrit une nouvelle table dans le fichier « tables.list » à mi-chemin du compactage des tables après que le verrouillage initial a été levé, mais avant que le nouveau fichier « tables.list » n'ait été écrit ? Dans ce cas, le processus de compactage ignore alors l'existence de la nouvelle table et réécrit donc le fichier « tables.list » sans inclure la nouvelle table. Cette situation a pour effet d'ignorer la mise à jour de l'écriture simultanée et d'empêcher l’ajout, la mise à jour ou la suppression des références.\n\nHeureusement, la solution pour remédier à ce problème est assez simple. Lorsque le processus de compactage obtient le verrou pour écrire dans le fichier « tables.list », il doit d'abord vérifier si des mises à jour du fichier ont eu lieu et recharger le fichier. Cela permet de s'assurer que les mises à jour simultanées des tables sont également reflétées correctement. Pour plus d'informations sur cette correction, consultez ce\n[fil de discussion](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/).\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Corrections pour git-maintenance(1)\n\nAu fur et à mesure qu'un dépôt évolue, il est important qu'il soit correctement maintenu. Par\ndéfaut, Git exécute\n[git-maintenance(1)](https://git-scm.com/docs/git-maintenance) après certaines\nopérations pour maintenir le dépôt fonctionnel. Afin d'éviter une maintenance\ninutile, l'option `--auto` est spécifiée et utilise une heuristique définie pour déterminer si les tâches de maintenance doivent être exécutées. Bien que la commande puisse être\nconfigurée pour effectuer différentes tâches de maintenance, elle exécute simplement par défaut [git-gc(1)](https://git-scm.com/docs/git-gc/fr) en arrière-plan, permettant ainsi à l'utilisateur de poursuivre ses activités.\n\nTout fonctionne comme prévu jusqu'à ce que la maintenance soit configurée pour effectuer des tâches supplémentaires, différentes de celles prévues par défaut. Dans ce cas, les tâches de maintenance configurées s'exécutent au premier plan et le processus de maintenance initial ne s'interrompt pas tant que toutes les tâches ne sont pas terminées. Seule la tâche « gc » s'exécute en arrière-plan comme prévu. En effet, git-gc(1) se détache malencontreusement lorsqu'elle est exécutée avec `--auto`, tandis que les autres tâches de maintenance n'ont aucun mécanisme pour le faire. Résultat ? Un ralentissement de certaines commandes Git, la maintenance automatique devant s'exécuter entièrement avant qu'elles ne puissent se terminer.\n\nCette nouvelle version résout ce problème en ajoutant à git-maintenance(1) l'option `--detach`, qui permet à l'ensemble du processus git-maintenance(1) de s'exécuter en arrière-plan à la place des tâches individuelles. La maintenance automatique effectuée par Git a également été mise à jour pour utiliser cette nouvelle option. Pour plus d'informations sur cette correction, consultez ce [fil de discussion](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/) pour en savoir plus.\n\nIl a été mentionné précédemment que l'auto-maintenance utilise un ensemble\nd'heuristiques pour déterminer si certaines opérations de maintenance doivent être effectuées ou non. Malheureusement, pour le backend « fichiers » de gestion des références, lorsque\n[git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs/fr) s'exécute avec\nl'option `--auto`, il n'y a pas de telle heuristique, et toutes les références non compactées sont inconditionnellement compactées dans un fichier « packed-refs ». Pour les dépôts avec de nombreuses références, la réécriture du fichier « packed-refs » peut prendre beaucoup de temps.\n\nCette nouvelle version introduit également une heuristique qui décide s'il faut compacter\nles références non compactées dans le backend « fichiers ». Cette heuristique prend en compte la taille du fichier « packed-refs » existant et le nombre de références non compactées présentes dans le dépôt. Plus le fichier « packed-refs » est volumineux, plus le seuil du nombre de références non compactées est élevé avant que le compactage des références ne se produise. Cela permet de rendre moins agressif le compactage des références dans le backend « fichiers » tout en maintenant le dépôt dans un état correct. Consultez ce [fil de discussion](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/)\npour plus d'informations.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Refactorisation du code et amélioration de la maintenabilité\n\nEn plus des changements fonctionnels, un travail de refactorisation et de nettoyage du code est également en cours. Très précieuses, ces améliorations aident le projet à se rapprocher de son objectif de longue date qui est de créer une bibliothèque de librairies de ses composants internes. Pour en savoir plus, consultez cette récente\n[mise à jour du fil de discussion](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/) sur la création d'une bibliothèque de librairies.\n\nL'un des domaines d'amélioration concerne la résolution des fuites de mémoire. Le projet Git présente en effet un certain nombre de fuites de mémoire. Ces fuites ne posent généralement pas de problème puisqu'un processus Git ne s'exécute que pendant une courte période et qu'un nettoyage est effectué par le système par la suite. Dans un contexte de création d'une bibliothèque de librairies, il s'agit cependant d'un problème qu'il convient de résoudre. Les tests du projet peuvent être compilés à l'aide d'un outil conçu pour détecter les fuites. Cependant, en raison de la présence de fuites existantes, il est difficile de valider et de garantir que les nouveaux changements n'introduisent pas d'autres fuites. Des efforts continus ont été déployés pour corriger toutes les fuites de mémoire détectées par les tests existants dans le projet. Les tests qui n'ont détecté aucune fuite sont ensuite mis en évidence avec la mention `TEST_PASSES_SANITIZE_LEAK=true` afin d'indiquer qu'ils sont supposés être exempts de fuites à l'avenir. Le projet compte aujourd'hui 60 fichiers de test contenant des fuites de mémoire, contre 223 auparavant.\n\nUne autre initiative en cours a pour but de réduire l'utilisation de variables globales\ndans l'ensemble du projet. L'une de ces fameuses variables globales est `the_repository`, laquelle contient l'état du dépôt en cours d’utilisation et est référencée dans l'ensemble du projet. La nouvelle version Git 2.47.0 s'accompagne d'un certain nombre de correctifs qui suppriment l'utilisation de `the_repository` en faveur d'une transmission directe de la valeur là où c'est nécessaire. Les sous-systèmes du projet Git qui dépendent encore de `the_repository` définissent la variable `USE_THE_REPOSITORY_VARIABLE`, permettant ainsi d'utiliser la variable globale. De cette manière, les sous-systèmes refs, config et path ne dépendent plus de son utilisation.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab)\navec l'aide de [John Cai](https://gitlab.com/jcaigitlab) et\n[Jeff King](https://github.com/peff).\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git au sens large pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/)\ndu projet Git et en consultant les ressources suivantes :\n\n- [Nouveautés de Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/)\n- [Nouveautés de Git 2.45.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/)\n- [Guide pour les débutants sur le format reftable Git](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?](https://about.gitlab.com/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference/)",[682,683,272],"2024-10-21",{"slug":959,"featured":93,"template":685},"whats-new-in-git-2-47-0","content:fr-fr:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","fr-fr/blog/whats-new-in-git-2-47-0.yml","fr-fr/blog/whats-new-in-git-2-47-0",{"_path":965,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":966,"content":972,"config":978,"_id":980,"_type":16,"title":981,"_source":18,"_file":982,"_stem":983,"_extension":21},"/fr-fr/blog/what-is-gitflow",{"title":967,"description":968,"ogTitle":967,"ogDescription":968,"noIndex":6,"ogImage":969,"ogUrl":970,"ogSiteName":740,"ogType":741,"canonicalUrls":970,"schema":971},"GitFlow et GitLab Flow : quelle différence ? ","Découvrez ce qu'est GitFlow, son fonctionnement, ses avantages, ainsi que les différences avec GitLab Flow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","https://about.gitlab.com/blog/what-is-gitflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitFlow et GitLab Flow : quelle différence ? \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }",{"title":967,"description":968,"authors":973,"heroImage":969,"date":974,"body":975,"category":14,"tags":976,"updatedDate":977},[935],"2024-09-27","[GitFlow](https://jeffkreeftmeijer.com/git-flow/) permet aux équipes de développement de créer une branche séparée develop (pour le développement) en plus de la branche principale main (pour la production) et la définissent comme branche par défaut.\n\nAvec [GitLab Flow](https://about.gitlab.com/fr-fr/topics/version-control/what-is-gitlab-flow/), en revanche, le développement s'organise principalement dans la branche principale (`main`). GitLab Flow intègre également des branches de préproduction, utilisée pour tester et corriger les bogues avant de fusionner les modifications apportées au code dans la branche `main`. Cette étape précède directement le passage en production, garantissant un code plus fiable. Les équipes peuvent créer autant de branches intermédiaires que nécessaire. Par exemple, un workflow plus structuré peut compter plusieurs niveaux de validation : de la branche `main` vers une branche de test, de la branche test vers une branche de validation, de la branche de validation vers la branche de production. \n\nDans cet article, découvrez ce qu'est GitFlow, son fonctionnement, ses avantages, ainsi que les différences entre GitFlow et GitLab Flow.\n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas)\n\n## Sommaire\n- Qu'est-ce que GitFlow ?\n- Comment fonctionne GitFlow ? \n- Quelles sont les différences entre GitFlow et GitLab Flow ?\n- Quels sont les avantages de GitFlow ? \n- Exemples d'utilisation de GitFlow\n\n## Qu'est-ce que GitFlow ?\n\nGitFlow est un workflow Git, c’est-à-dire un modèle de gestion des branches au sein d'un système de [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Qu'est-ce que le contrôle de version ? \") décentralisé pour les dépôts Git. Conçu pour organiser efficacement le développement logiciel, il a été [introduit par Vincent Driessen en 2010](https://nvie.com/posts/a-successful-git-branching-model/). Il est adapté aux projets nécessitant une gestion rigoureuse des versions. Il est particulièrement populaire auprès des grandes équipes de développement. \n\n## Comment fonctionne GitFlow ? \n\nContrairement au développement basé sur le tronc, c'est-à-dire sur une seule branche principale, GitFlow repose sur des branches persistantes plutôt que des branches temporaires. GitFlow est particulièrement adapté aux projets ayant des cycles de sorties de nouvelles versions bien définis et aux bonnes pratiques de [livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ? \") de l'approche [DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/). \n\nÉtant donné que le workflow est structuré avec des branches spécifiques dans GitFlow, vous pouvez ajouter, par exemple, des branches de fonctionnalité (\"feature branches\") aux branches `develop` et `main`, ainsi que des branches `release`. GitFlow permet à votre équipe de comprendre plus facilement la structure du workflow et de savoir où ajouter les modifications dans le pipeline de développement. \n\n## Quelles sont les différences entre GitFlow et GitLab Flow ?\n\nGitFlow est un modèle de gestion des branches pour les dépôts [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") qui utilise plusieurs branches principales en plus des branches de fonctionnalité. [GitLab Flow](https://about.gitlab.com/fr-fr/topics/version-control/what-is-gitlab-flow/), par ailleurs, vise à résoudre certains problèmes que pose GitFlow. Il simplifie le workflow, optimise le processus de développement, permettant ainsi à l'équipe de développement logiciel de travailler de manière plus efficace. Voici les principales différences entre les deux types de workflows. \n\n### Le workflow GitFlow\n\nLe workflow GitFlow comporte les cinq types de branches suivantes : \n\n1. main (branche de production)\n2. develop (branche de développement)\n3. feature (branche de fonctionnalité)\n4. release (branche de nouvelle version)\n5. hotfix (branche de correction urgente de bogue)\n\nSi vous utilisez GitFlow pour le développement de code, vous disposez d'une branche principale et de branches intermédiaires. Il y a deux principales branches de longue durée : la branche `main` pour le code prêt pour être mis en production, et la branche `develop` pour intégrer le code en cours de développement. Dans GitFlow, la branche `develop` est utilisée pour stabiliser le code avant de le fusionner avec la branche `main` lorsqu’il est prêt. Les branches intermédiaires sont des branches dédiées à d'autres tâches. Vous pouvez par exemple créer des branches `feature`, `release` et `hotfix`, chacune ayant sa propre fonction.  \n\n### Le workflow de GitLab Flow\n\nGitLab Flow permet une intégration continue plus efficace en réduisant la complexité de GitFlow, notamment pour les tâches liées à la sortie des versions, à l'ajout de tags, au merge des branches, et bien plus encore. \n\nGitLab Flow est une alternative simple à GitFlow qui allie un développement axé sur les fonctionnalités à une gestion de projets via des tickets. Il est conçu pour être plus simple, facile à comprendre et plus efficace, et inclut des bonnes pratiques pour les équipes de développement logiciel qui souhaitent livrer leurs fonctionnalités de manière fluide et de façon collaborative. \n\nGitLab Flow est le workflow utilisé pour le développement de GitLab. Il est structuré autour des branches suivantes : la branche principale (`main`) ; la branche de préproduction (`pre-production`), autrement dit la branche de test avant la sortie de la nouvelle version ; la branche de production pour la gestion du code déployé ; les branches pour le développement des fonctionnalités (`feature`) et les corrections de bogues (`hotfix`). Les équipes peuvent ajouter autant de branches de préproduction qu'elles le souhaitent. Par exemple, il est possible de créer un flux depuis la branche `main` vers la branche de test, puis de la branche de test vers la branche de validation, et enfin, de la branche de validation vers la branche de production. \n\nLes équipes gèrent ainsi des branches de fonctionnalité et des branches de production. Lorsque le code de la branche `main` est prêt pour le déploiement, il est fusionné dans la branche de production, puis déployé. GitLab Flow peut également inclure des branches `release`. Les équipes qui ont besoin d'une API publique doivent parfois gérer différentes versions simultanément. Avec GitLab Flow, elles peuvent créer et maintenir séparément des branches comme `v1` et `v2`. Ainsi, il est facile de repasser sur la branche `v1` si des bogues sont détectés lors d'une [revue de code](https://about.gitlab.com/fr-fr/topics/version-control/what-is-code-review/ \"Qu'est-ce que la revue de code ? \").\n\n## Quels sont les avantages de GitFlow ? \n\n### Correction rapide des bogues\n\nL'un des principaux avantages de GitFlow est que vous pouvez rapidement gérer les corrections de bogues dans l'environnement de production. Le workflow GitFlow est particulièrement utile pour les grandes équipes de développement logiciel travaillant sur des projets complexes. \n\n### Garantie des tests\n\nLors de la sortie d'une nouvelle version à partir d'une branche `release`, il vous est possible de configurer une période de test pendant laquelle les utilisateurs peuvent la tester dans un environnement de simulation. Cette phase peut être réalisée indépendamment du développement de code. En outre, les validations suivent un flux downstream pour s'assurer que chaque ligne de code est testée dans tous les environnements. \n\n### Optimisation du processus de développement logiciel\n\nGitFlow vous permet de tirer le meilleur parti de Git. Vous pourrez ainsi rendre vos processus de développement logiciel bien plus efficaces. \n\n### Collaboration renforcée et résolution des conflits de merge\n\nL'utilisation de GitFlow facilite la collaboration au sein d'une équipe, accélère la résolution des conflits de merge et assure une livraison continue bien plus efficace. \n\n## Exemples d'utilisation de GitFlow\nVoici une représentation schématique du workflow avec un exemple de configuration de GitFlow. Elle illustre la manière dont les branches sont organisées et interconnectées au sein du workflow. \n\n![Exemple de workflow GitFlow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\n## FAQ sur GitLab Flow et GitFlow \n\n### Qu'est-ce que Git Feature Flow ? \n\nGit Feature Flow est une variante simplifiée de GitFlow, spécialement conçue pour faciliter le développement basé sur les fonctionnalités. \n\n### GitLab Flow est-il un choix judicieux ? \n\nTout à fait. GitLab Flow permet de réduire la charge de travail liée à la sortie des nouvelles versions, à l'ajout de tags et le merge de branches, ces tâches représentant un défi courant rencontré avec les workflows Git traditionnels. Pour en savoir plus, [cliquez ici](https://about.gitlab.com/fr-fr/topics/version-control/what-are-gitlab-flow-best-practices/). \n\n### Que choisir entre GitLab Flow et GitFlow ? \n\nGitFlow est structurellement mieux adapté aux grands projets avec des étapes de développement bien définies. GitLab Flow est plus flexible et convient aux projets nécessitant une livraison continue et une mise en production rapide pour un lancement fréquent de nouvelles versions. \n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas)",[682,683],"2025-06-04",{"slug":979,"featured":6,"template":685},"what-is-gitflow","content:fr-fr:blog:what-is-gitflow.yml","What Is Gitflow","fr-fr/blog/what-is-gitflow.yml","fr-fr/blog/what-is-gitflow",{"_path":985,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":986,"content":992,"config":1000,"_id":1002,"_type":16,"title":1003,"_source":18,"_file":1004,"_stem":1005,"_extension":21},"/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference",{"title":987,"description":988,"ogTitle":987,"ogDescription":988,"noIndex":6,"ogImage":989,"ogUrl":990,"ogSiteName":740,"ogType":741,"canonicalUrls":990,"schema":991},"Git fetch vs git pull : quelle différence ?","Git pull est une commande Git qui exécute simultanément git fetch et git merge. Cet article décrit les caractéristiques et les utilisations de chaque commande.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?  \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-09-24\",\n      }",{"title":993,"description":988,"authors":994,"heroImage":989,"date":996,"body":997,"category":14,"tags":998,"updatedDate":999},"Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?",[995],"GitLab","2024-09-24","[Git est un outil de contrôle de version](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") très populaire et utilisé lorsque la synchronisation avec un dépôt distant est nécessaire. Les équipes de développement doivent ainsi choisir les commandes appropriées en fonction des besoins de leurs projets. \n\nDécouvrez dans cet article les caractéristiques et les différences entre les commandes git fetch et git pull, ainsi qu’une explication détaillée de leurs cas d'utilisation respectifs.\n\n## Qu’est-ce que git fetch et git pull ?\n\nGit fetch et git pull sont deux [commandes Git](https://git-scm.com/book/fr/v2/Commandes-Git-Partage-et-mise-%C3%A0-jour-de-projets \"commandes Git\") utilisées pour récupérer des informations de mise à jour à partir d'un dépôt distant. Alors, en quoi diffèrent-elles ? \n\nLa __[commande git fetch](https://git-scm.com/docs/git-fetch/fr \"commande git fetch\")__ télécharge les modifications du dépôt distant vers le dépôt local, mais n'apporte aucune modification au répertoire de travail en cours. Étant donné que les modifications ne sont pas fusionnées dans la branche locale, vous pouvez les vérifier à partir du dépôt distant sans interrompre votre travail. \n\nLa __commande git pull__, quant à elle, récupère les modifications les plus récentes du dépôt distant comme git fetch, mais elle fusionne également automatiquement ces modifications dans la branche actuelle. Contrairement à git fetch, git pull applique directement les modifications du dépôt distant au répertoire de travail local.\n\nPour en savoir plus sur Git, [consultez notre documentation](https://docs.gitlab.com/ee/topics/git/ \"Documentation GitLab sur Git\"). \n\n## Git fetch \nLa commande git fetch récupère l'historique des validations les plus récentes du dépôt distant, mais elle n'affecte pas le répertoire de travail local. Même après avoir récupéré les modifications à distance, celles-ci ne sont pas reflétées dans la branche locale. Cette commande est principalement utilisée lorsque vous souhaitez récupérer le dernier statut du dépôt distant et examiner les modifications avant qu'elles ne soient reflétées dans le dépôt local. Pour appliquer les modifications récupérées à la branche locale, vous devez exécuter manuellement git merge ou [git rebase](https://about.gitlab.com/blog/take-advantage-of-git-rebase/).\n\n### Quand utiliser git fetch ? \nLa commande git fetch permet de récupérer les informations les plus récentes d'un dépôt distant. Les informations récupérées ne sont pas directement reflétées dans la branche locale. Tandis que l'utilisation de git pull reflète toutes les branches distantes, y compris les branches incorrectes ou problématiques, dans la branche locale. \n\nLorsque des modifications sont apportées simultanément sur des branches distantes et locales, ou lorsque de nouveaux utilisateurs intègrent l'équipe, il est plus sûr d'utiliser git fetch pour récupérer dans un premier temps le contenu de la branche distante, puis d'effectuer un merge ou un rebasage. \n\n## Git pull \nLa commande git pull combine `git fetch` et `git merge` (ou `git rebase`) en une seule commande. Cela vous permet de récupérer les modifications depuis le dépôt distant et de les intégrer automatiquement dans la branche locale actuelle. \n\nAlors que git fetch récupère les modifications du dépôt distant sans les appliquer à la branche locale, l'exécution de git pull intègre automatiquement les modifications du dépôt distant dans la branche locale. \n\nLa commande git pull convient pour refléter rapidement les modifications à distance dans la branche locale, mais elle peut conduire à des conflits. Il est donc recommandé de faire très attention, en particulier lorsque vous travaillez avec plusieurs personnes. \n\n### Quand utiliser git pull ?\nLa commande git pull exécute plus de processus que git fetch. Git pull peut exécuter à la fois git fetch en plus de git merge ou git rebase. Pour cette raison, la commande git pull est recommandée lorsque vous souhaitez refléter rapidement les modifications du dépôt distant dans la branche locale. \n\n## FAQ sur git fetch vs git pull\n\n### Quelle est la différence entre git pull et git fetch ? \nLa commande git pull exécute la commande git fetch suivie de git merge ou git rebase. Alors que git fetch n'affecte pas le dépôt local, git pull synchronise automatiquement les modifications du dépôt distant avec le dépôt local. \n\n### Quelles sont les précautions à prendre lors de l'utilisation de git pull ? \nLors de l'exécution de git pull, il peut y avoir des conflits entre les modifications distantes et locales. Des conflits de merge sont particulièrement susceptibles de se produire. Par conséquent, si des conflits surviennent, ils doivent être résolus manuellement. De plus, l'utilisation de git pull --rebase vous permet d'intégrer les dernières modifications lors de l'exécution du rebasage. \n\n### À quoi sert git fetch ? \nGit fetch permet de vérifier et de récupérer le statut le plus récent du dépôt distant. Cependant, les modifications récupérées ne sont pas automatiquement reflétées dans la branche locale ; git fetch est utilisé pour synchroniser les dépôts locaux et distants.",[682,683],"2024-10-15",{"slug":1001,"featured":6,"template":685},"git-pull-vs-git-fetch-whats-the-difference","content:fr-fr:blog:git-pull-vs-git-fetch-whats-the-difference.yml","Git Pull Vs Git Fetch Whats The Difference","fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference.yml","fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference",{"_path":1007,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":1008,"content":1012,"config":1018,"_id":1020,"_type":16,"title":1021,"_source":18,"_file":1022,"_stem":1023,"_extension":21},"/fr-fr/blog/whats-new-in-git-2-46-0",{"title":1009,"description":949,"ogTitle":1009,"ogDescription":949,"noIndex":6,"ogImage":989,"ogUrl":1010,"ogSiteName":740,"ogType":741,"canonicalUrls":1010,"schema":1011},"Nouveautés de Git 2.46.0","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.46.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":1009,"description":949,"authors":1013,"heroImage":989,"date":1014,"body":1015,"category":14,"tags":1016,"updatedDate":1017},[724],"2024-07-29","Le projet Git a récemment publié la [version 2.46.0 de Git](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u). Jetons un coup d'œil aux points forts de cette version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.\n\n## Outils pour migrer les backends de références\n\nDans la version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)\nprécédente, le format « reftable » est devenu le nouveau backend pour le stockage\ndes références. Ce nouveau format de référence vise à améliorer les performances et l'efficacité des dépôts Git,\nen particulier lorsque le nombre de références devient très élevé. Si le backend « reftable » ne vous est pas encore\nfamilier, n'hésitez pas à consultez notre précédent [article de blog consacré à la version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/) dans lequel nous présentons ce nouveau format, ainsi que notre guide du débutant pour [en savoir plus sur le fonctionnement des reftables](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/ \"Format reftable de Git\").\n\nLe backend « reftable » offre un format de stockage sur disque différent de l'ancien format de backend basé sur les fichiers. Par conséquent, l’utilisation du format « reftable » avec un dépôt existant, nécessite une conversion entre les différents formats. Pour cela, une nouvelle commande git-refs(1) a été introduite, incluant la sous-commande `migrate` pour effectuer les migrations de backend de référence. Voici un exemple illustrant l'utilisation de cette commande :\n\n```shell\n# Initialize a new repository as “bare” so it does not contain reflogs.\n$ git init --bare .\n$ git commit --allow-empty -m \"init\"\n# Populate repository with references in the files backend.\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# Perform reference migration to reftables format.\n$ git refs migrate --ref-format=reftable\n# Check that reftables backend is now in use.\n$ tree .git/reftable\n.git/reftable\n├── 0x000000000001-0x000000000001-a3451eed.ref\n└── tables.list\n# Check the repository config to see the updated `refstorage` format.\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\nUne fois qu'un dépôt est migré, le format de stockage sur disque est mis à jour, permettant ainsi\nl'utilisation du backend « reftable ». Les opérations Git dans le dépôt continuent de\nfonctionner normalement et d'interagir avec les dépôts distants comme elles le faisaient auparavant. La migration n'a d'incidence que\nsur la manière dont les références sont stockées en interne pour le dépôt. Si vous souhaitez revenir au backend « fichiers », vous pouvez le faire avec la même commande en spécifiant à la place `--ref-format=files`.\n\nL'outil de migration présente actuellement certaines limitations notables. Les reflogs dans un dépôt font partie du backend de gestion des références et nécessitent également une migration lors du changement de format. Malheureusement, l'outil n'est pas encore capable de convertir les reflogs entre les backends « fichiers » et les backends « reftable ». De plus, un dépôt avec des [arbres de travail](https://git-scm.com/docs/git-worktree/fr \"Arbres de travail Git\") dispose en réalité de plusieurs ref stores et l'outil de migration ne prend pas encore en charge ce scénario. Par conséquent, si un dépôt contient des reflogs ou des arbres de travail, la migration des références n'est actuellement pas possible. Ces limitations pourraient être résolues dans les futures versions.\n\nLes dépôts Git « bare » ne contiennent pas de reflogs, ce qui facilite leur migration. Pour migrer un dépôt « non bare » standard, les reflogs doivent d'abord être supprimés. Ainsi, il est possible de migrer tout dépôt dépourvu de reflog et d'arbre de travail. En tenant compte de ces limitations, cet outil de migration peut être très utile pour profiter des avantages du backend « reftable » dans vos dépôts existants.\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Mises à jour des références symboliques transactionnelles\n\nLa commande [git-update-ref(1)](https://git-scm.com/docs/git-update-ref)\npermet de mettre à jour les références dans un dépôt Git. Ces mises à jour de références peuvent également être effectuées de manière atomique en bloc via des transactions, en utilisant la commande\n`git update-ref --stdin` pour transmettre les informations de mise à jour de références à stdin. Voici un exemple :\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# Retrieve the object ID of the two commits created.\n$ git rev-parse main~ main\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n# Start transaction, provide update-ref instructions, and commit.\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\nDans cet exemple, une fois la transaction validée, une nouvelle branche est créée et pointe vers le commit « bar » tandis que la branche principale est mise à jour et pointe vers le commit « foo » précédent. La validation de la transaction exécute les mises à jour des références spécifiées de manière atomique. Si une mise à jour concernant une référence particulière échoue, la transaction est abandonnée et aucune mise à jour de références n'est effectuée.\n\nIl convient de noter ici qu'aucune instruction quant à la prise en charge des mises à jour des références symboliques n'est disponible pour ces\ntransactions. Si un utilisateur souhaite mettre à jour une référence symbolique en même temps que d'autres références\nde manière atomique dans une seule transaction, il n'existe pas d'outil pour le faire. Dans la\nnouvelle version de Git, les instructions `symref-create`, `symref-update`, `symref-delete` et\n`symref-verify` sont introduites pour fournir cette fonctionnalité.\n\n```shell\n# Create a symref that will be updated during the next operation.\n$ git symbolic-ref refs/heads/symref refs/heads/main\n# The --no-deref flag is required to ensure the symref itself is updated.\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\nL'exemple ci-dessus illustre la création d'une nouvelle référence symbolique et la mise à jour d'une autre\nau cours d'une transaction. Ces nouvelles instructions pour les références symboliques peuvent désormais être\ncombinées avec les instructions existantes afin de réaliser toutes sortes de\nmises à jour de références dans une seule transaction. Pour en savoir plus\nsur chacune de ces nouvelles instructions, consultez la [documentation](https://git-scm.com/docs/git-update-ref).\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Améliorations de l'expérience utilisateur pour git-config(1)\n\nLa commande git-config(1) est utilisée dans Git pour visualiser et modifier les options de configuration, tant au niveau local (pour un dépôt spécifique) qu'au niveau global (pour l'ensemble de l'interface utilisateur). Les modes d'interaction avec la configuration peuvent être choisis explicitement à l'aide d'indicateurs spécifiques ou déterminés implicitement en fonction du nombre d'arguments fournis à la commande. Voici un exemple :\n\n```shell\n$ git config --list\n# Explicit retrieval of username configuration\n$ git config --get user.name\n# Implicit retrieval of username configuration\n$ git config user.name\n# Explicit setting of username configuration\n$ git config --set user.name \"Sidney Jones\"\n# Implicit setting of username configuration\n$ git config user.name \"Sidney Jones\"\n# An optional third argument is also accepted. What do you think this does?\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n```\n\nGlobalement, l'interface utilisateur de [git-config(1)](https://git-scm.com/docs/git-config)\nn'est pas cohérente avec le fonctionnement d'autres commandes Git plus récentes, où l'on utilise généralement des sous-commandes. Par exemple, `git remote list`. Cette nouvelle version Git introduit les sous-commandes `list`, `get`, `set`, `unset`, `rename-section`, `remove-section` et `edit` pour la commande config, tout en conservant l'ancienne syntaxe. Ce changement vise à améliorer l'expérience utilisateur en adaptant la commande config pour qu'elle suive des pratiques plus modernes et soit davantage alignée avec les autres commandes de Git. Par exemple :\n\n```shell\n$ git config list\n$ git config get user.name\n$ git config set user.name \"Sidney Jones\"\n```\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## Correction de la régression des performances\n\nLes opérations Git qui utilisent des attributs reposent sur la lecture des fichiers `.gitattributes` présents dans l'arbre de travail du dépôt. Cela pose un problème pour les dépôts Git « bare » qui sont, par définition, dépourvus d'un arbre de travail. Pour contourner ce problème, Git dispose de la configuration `attr.tree`, qui permet de définir un arbre source et de l'utiliser pour en extraire des attributs.\n\nDans la version 2.43.0 de Git, Git a commencé à utiliser par défaut l'arborescence de `HEAD` comme source des attributs Git dans le cas de dépôts « bare  ». Malheureusement, cette charge de travail supplémentaire liée à la recherche de fichiers d'attributs Git a eu de graves impacts sur les performances. En effet, à chaque recherche d'attribut, l'arbre source est parcouru dans son ensemble pour rechercher un fichier `.gitattributes` associé, si `attr.tree` est défini. Plus l'arbre source du dépôt est grand et profond, plus la régression des performances est évidente. Par exemple, des tests de performance réalisés sur le dépôt linux.git ont montré que\ngit-pack-objects(1) mettait 1,68 fois plus de temps à s'exécuter. Cela peut entraîner des ralentissements lors d'opérations de clonage ou de récupération.\n\n```\n# attr.tree set to HEAD as done by default in Git version 2.43.0.\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 is set to an empty tree to disable attribute lookup as done in Git versions prior to 2.43.0.\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\nLes commandes Git les plus impactées étaient `clone`, `pull`, `fetch` et `diff`, particulièrement lorsqu'elles étaient utilisées sur des dépôts avec des arborescences volumineuses ou profondes. Par conséquent, dans Git 2.46.0, la configuration `attr.tree` a été partiellement modifiée pour ne plus être définie sur `HEAD` par défaut afin de remédier à la régression des performances. Pour en savoir plus, consultez ce [fil de discussion](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/).\n\n## Migration des tests unitaires\n\nHistoriquement, pour tester Git, les développeurs utilisaient des scripts shell\npour réaliser des tests de bout en bout. Un framework de tests unitaires écrit en C a été récemment\nintégré au projet Git. Ce nouveau framework\npermet de tester en détail les implémentations à un niveau granulaire,\ntel que chaque appel de fonction, et complète les tests de bout en bout existants. Certains tests de bout en bout existants sont plus adaptés aux tests unitaires et sont donc de bons candidats pour le portage de tests.\n\nCette année, GitLab continu d'aider les contributeurs du [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) qui travaillent sur le projet Git. Grâce aux efforts déployés dans le cadre de ces projets GSoC et à la contribution de la communauté Git au sens large, certains tests existants sont révisés et migrés vers le framework de tests unitaires. Pour la sortie de la nouvelle version Git 2.46.0, plusieurs contributions ont été apportées dans le but d'améliorer les tests dans le projet Git. Pour suivre l'avancement de ces projets de contributeurs GSoC, consultez les blogs de [Chandra](https://chand-ra.github.io/) et [Ghanshyam](https://spectre10.github.io/posts/).\n\n## Correction du bundle URI\n\nEn général, lorsqu'un client récupère des données à partir d'un dépôt distant, tous les objets nécessaires\nsont envoyés dans un fichier groupé généré par le serveur distant. Pour éviter une partie de ce\ntraitement, les serveurs peuvent choisir de proposer des bundles prêts à l'emploi, stockés séparément du serveur distant, qui contiennent des ensembles de références et d'objets dont le client peut avoir besoin. Le client peut d'abord récupérer ces bundles grâce à un mécanisme appelé [bundle-uri](https://git-scm.com/docs/bundle-uri).\n\nGrâce à [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/), un problème a été identifié et corrigé : Git, malgré le téléchargement de certains bundles, continuait de télécharger tous les objets et les références depuis le dépôt distant, comme si aucun bundle n'avait été récupéré. La raison de ce problème était que Git ne découvrait pas correctement l'ensemble des bundles téléchargés, ce qui entraînait la nécessité de récupérer les bundles suivants depuis le dépôt distant. Grâce à cette correction, les dépôts distants utilisant le mécanisme bundle-uri peuvent éviter d'avoir à effectuer un travail redondant et ainsi améliorer les performances.\n\n## En savoir plus\n\nCet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et\nla communauté Git au sens large pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant [l'annonce officielle](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) du projet Git. Consultez également nos [précédents articles de blog sur les nouvelles versions de Git](https://about.gitlab.com/blog/tags/git/) pour en découvrir davantage sur les contributions de l'équipe GitLab.",[682,683,272],"2024-08-15",{"slug":1019,"featured":93,"template":685},"whats-new-in-git-2-46-0","content:fr-fr:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","fr-fr/blog/whats-new-in-git-2-46-0.yml","fr-fr/blog/whats-new-in-git-2-46-0",{"_path":1025,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":1026,"content":1032,"config":1037,"_id":1039,"_type":16,"title":1040,"_source":18,"_file":1041,"_stem":1042,"_extension":21},"/fr-fr/blog/kubernetes-the-container-orchestration-solution",{"title":1027,"description":1028,"ogTitle":1027,"ogDescription":1028,"noIndex":6,"ogImage":1029,"ogUrl":1030,"ogSiteName":740,"ogType":741,"canonicalUrls":1030,"schema":1031},"Kubernetes : tout savoir sur la solution d’orchestration des conteneurs","Kubernetes, également connue sous son diminutif K8s, est une solution open source incontournable pour déployer et maintenir des applications, notamment dans le cloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660215/Blog/Hero%20Images/kubernetes-container-orchestration-solution.jpg","https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes : tout savoir sur la solution d’orchestration des conteneurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":1027,"description":1028,"authors":1033,"heroImage":1029,"date":1034,"body":1035,"category":14,"tags":1036},[935],"2024-07-25","Ce logiciel permet d'automatiser les tâches de déploiement et de gestion d'applications conteneurisées à grande échelle. \n\nKubernetes est devenu au fil du temps un outil essentiel en développement d'applications dans de nombreux domaines, comme les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que sont les microservices ? \"), les applications web et les bases de données. Ses performances et son évolutivité en font aujourd’hui un standard reconnu en gestion de conteneurs.\n\nDécouvrez dans cet article tout ce que vous devez savoir sur Kubernetes. \n\n- [Qu'est-ce que Kubernetes ?](#quest-ce-que-kubernetes)\n- [Comment fonctionne une architecture Kubernetes ?](#comment-fonctionne-une-architecture-kubernetes)\n- [Quels sont les avantages de Kubernetes ?](#quels-sont-les-avantages-de-kubernetes)\n- [Quelles sont les limites de Kubernetes ?](#quelles-sont-les-limites-de-kubernetes)\n- [Utiliser Kubernetes au sein de vos équipes](#utiliser-kubernetes-au-sein-de-vos-equipes)\n- [Kubernetes, Git et GitLab](#kubernetes-git-et-gitlab)\n\n## Qu'est-ce que Kubernetes ?\n\nKubernetes est un système [__open source__](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") qui permet d’orchestrer efficacement les conteneurs d'une application informatique. La __conteneurisation__ est une approche largement plébiscitée en développement d'applications TIC, particulièrement dans les domaines de la transformation digitale et du cloud.\n\nSi la notion de conteneurs ne vous est pas familière, sachez qu'il s'agit d'une méthode de développement d'application qui consiste à regrouper les composants d'une application dans des unités standardisées – des conteneurs – qui sont indépendants des appareils et des systèmes d'exploitation sur lesquels ils se trouvent. En isolant les applications de leur environnement, cette technologie __facilite leur déploiement, leur portabilité, et limite des conflits d'interopérabilité.__\n\nC'est à ce niveau que nous utilisons le logiciel Kubernetes. Certes, les conteneurs permettent de découper les applications en modules plus petits et autonomes, facilitant ainsi leur déploiement. Mais pour que les conteneurs puissent interagir au sein d'une application, un système de gestion englobant ces modules est nécessaire. C'est précisément ce que Kubernetes permet de faire ! Kubernetes fournit une plateforme pour contrôler où et comment les conteneurs s'exécutent, de façon à orchestrer et à planifier leur exécution pour gérer des applications conteneurisées à grande échelle. \n\n## Comment fonctionne une architecture Kubernetes ?\n\nPour comprendre comment fonctionne une __architecture Kubernetes__, il est essentiel de se familiariser avec certaines notions, à commencer par celle du cluster, qui est l'échelle la plus large de l'architecture. \n\n### Cluster Kubernetes\n\nUn __cluster Kubernetes__ se définit comme l'ensemble des __machines virtuelles__ ou physiques sur lesquelles est installée une __application conteneurisée__.\n\n![Components of Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673941/Blog/Content%20Images/components-of-kubernetes.png)\n*Source: [Kubernetes](https://kubernetes.io/docs/concepts/overview/components/ \"Kubernetes website\")*.\n\nCe cluster comprend différents éléments :\n\n- __Nœud (Node) :__ c'est une unité de travail dans un cluster Kubernetes. Il s'agit d'une machine virtuelle (VM) ou physique (bare-metal) qui exécute des tâches pour le compte de l'application.\n- __Pod :__ un pod est la plus petite unité déployable dans Kubernetes. Il représente un groupe de conteneurs fonctionnant ensemble sur un même nœud. Les conteneurs à l'intérieur d'un pod partagent le même réseau et peuvent communiquer entre eux via localhost.\n- __Service :__ un service Kubernetes permet d'exposer un pod au réseau ou à d'autres pods. Il offre un point d'accès stable et bien défini vers les applications hébergées par les pods.\n- __Volume :__ une abstraction de dossier qui permet de résoudre des problèmes de partage et de récupération des fichiers au sein d'un conteneur.\n- __Namespace (espace de nommage) :__ un namespace permet de grouper et d’isoler des ressources afin de former un cluster virtuel.\n\nL'architecture de Kubernetes repose sur deux principaux types de nœuds : le __nœud maître__ *(master)* et les nœuds ouvriers ou nœuds de travail *(__worker nodes__)*. Le nœud maître est responsable de la gestion globale du cluster Kubernetes et de la communication avec les __nœuds de travail__. Parmi ses composantes clés, l'API est le point de contact central pour toutes les communications entre les utilisateurs et le cluster. L'[Etcd](https://kubernetes.io/fr/docs/concepts/overview/components/#etcd \"Etcd\") est la base de données clé-valeur où sont stockées les configurations, l'état du système et les métadonnées des objets. Le controller manager coordonne les opérations d'arrière-plan telles que la réplication des pods, et le scheduler place les pods sur les nœuds en fonction des ressources disponibles.\n\nLes nœuds de travail, quant à eux, sont les machines qui exécutent et gèrent les applications contenues dans les pods. En leur sein, le [kubelet](https://kubernetes.io/fr/docs/concepts/overview/components/#kubelet \"Kubelet\") est l'agent qui s'exécute sur chaque nœud et communique avec le maître pour recevoir les commandes et transmettre l'état des pods. Le proxy réseau ou [kube-proxy](https://kubernetes.io/fr/docs/concepts/overview/components/#kube-proxy \"Kube-proxy\") maintient les règles réseau sur les nœuds pour permettre l'accès aux services depuis l'extérieur du cluster Kubernetes. Enfin, le container runtime est le logiciel responsable de l'exécution et la gestion des conteneurs au sein des pods.\n\n### Boucles de réconciliation\n\nLes __boucles de réconciliation (ou control loops)__ de K8s sont un mécanisme qui permet au système de maintenir un état cohérent et fiable. Kubernetes suit un __modèle déclaratif__, où l'utilisateur spécifie l'__état désiré__ d'un cluster à travers des manifestes YAML, comme le nombre de réplicas d’un déploiement, la configuration réseau, les volumes attachés, et plus encore. L’__état courant__, en revanche, est la représentation en temps réel de l’état effectif des ressources dans le cluster. \n\nLa __boucle de réconciliation__ est un processus continu dans lequel les __contrôleurs Kubernetes__ (comme le Deployment Controller, le Node Controller ou le ReplicaSet Controller) surveillent l’état actuel et tentent de l’ajuster pour qu’il corresponde à l’état souhaité. Lorsqu’une divergence est détectée (ex. un pod est supprimé ou un nœud devient indisponible), Kubernetes agit automatiquement pour restaurer la conformité en appliquant les correctifs nécessaires. Ce mécanisme permet à Kubernetes d'être __auto-réparateur__ et de garantir la haute disponibilité et la stabilité des applications déployées.\n\n### Manifestes\n\nPour décrire et gérer les ressources dans Kubernetes, nous utilisons des manifestes, c'est-à-dire des fichiers de configuration au format YAML ou JSON. Ces fichiers définissent l’état désiré d’un objet Kubernetes, comme un Pod, un Service ou un Déploiement. Un manifeste spécifie des paramètres essentiels tels que l’image du conteneur, le __nombre de réplicas__, les volumes ou les règles de mise en réseau. Une fois appliqué avec la commande `kubectl apply -f`, Kubernetes compare cet état désiré à l’état courant du cluster et ajuste les ressources pour garantir leur conformité. \n\n### Et Docker dans tout ça ?\n\nParmi tous les composants d'un cluster K8s, le choix du runtime au sein des nœuds de travail est important. Différents logiciels sont disponibles pour cela, comme rkt ou CRI-O, mais Docker est l'outil le plus couramment utilisé. Alors, qu'est-ce que Docker ? Et quelle est la différence entre Docker et Kubernetes ?\n\nDocker est une solution open source qui s'utilise spécifiquement au niveau des conteneurs. Il permet de __packager les conteneurs__ dans un format standardisé et léger, ce qui augmente leur portabilité dans différents environnements. C'est donc un outil complémentaire à K8s qui facilite la gestion des conteneurs en eux-mêmes, tandis que Kubernetes simplifie leur intégration et communication au sein de l'application.\n\n## Quels sont les avantages de Kubernetes ?\n\nLancée par Google en 2014, la première version stable de Kubernetes est apparue en juillet 2015. Depuis lors, la popularité de ce logiciel ne se dément pas, faisant de K8s une référence dans le domaine de l'orchestration de conteneurs, particulièrement pour les architectures orientées microservices. Mais alors, pourquoi utiliser Kubernetes ? Ce succès s'explique avant tout par les excellentes performances de ce logiciel en __orchestration de conteneurs__. \n\nLes avantages de Kubernetes sont nombreux : \n\n- __Automatisation :__  Kubernetes facilite l'automatisation des tâches liées au déploiement, au dimensionnement et à la mise à jour des applications conteneurisées.\n- __Flexibilité :__ le logiciel s'adapte à différentes technologies de conteneurs, diverses architectures matérielles et systèmes d'exploitation.\n- __Scalabilité :__  K8s permet de déployer et de gérer facilement des milliers de conteneurs, quel que soit leur état : en cours d'exécution, en pause, ou arrêtés.\n- __Migration :__  il est possible de migrer facilement des applications vers Kubernetes, sans avoir à modifier le code source.\n- __Support multi-cluster :__ Kubernetes permet de gérer de manière centralisée plusieurs clusters de conteneurs répartis sur différentes infrastructures.\n- __Gestion des mises à jour :__ Le logiciel prend en charge les déploiements rolling-update pour mettre à jour les applications sans interruption de service. \n\n### Un écosystème robuste et évolutif\n\nKubernetes se distingue ainsi par sa capacité à gérer les conteneurs de manière performante et sûre, tout en maintenant une indépendance vis-à-vis des fournisseurs d'infrastructures cloud. Son architecture modulaire s'adapte aux besoins spécifiques de chaque entreprise, et supporte un très large éventail d'applications et de services (services Web, traitement de données, applications mobiles, etc.).\n\nDans la course à la transformation digitale, Kubernetes convainc aussi grâce à son écosystème riche et extensible au sein de la communauté open source. Géré par la *__Cloud Native Computing Foundation (CNCF)__*, K8s est porté par des milliers de développeurs et développeuses partout dans le monde. Ils contribuent au développement du projet et à l'amélioration continue de ses fonctionnalités. \n\n## Quelles sont les limites de Kubernetes ?\n\nLes avantages de Kubernetes en font un choix sûr pour de nombreuses équipes de développement dans le domaine des applications [cloud-native](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Qu'est-ce que l'approche cloud-native ?\"). Néanmoins, il convient de souligner certaines limites. Kubernetes demande un solide bagage technique et de se former à de nouveaux concepts et méthodes de développement. Le logiciel peut être complexe à configurer en début de projet. La configuration est cependant cruciale, notamment pour sécuriser la plateforme. Disposer d'une équipe de développement expérimentée en __projet K8s__ constitue donc un sérieux atout. \n\nAutre difficulté, la mise en place et la maintenance d'une architecture K8s requièrent aussi du temps et des ressources, notamment pour mettre à jour ses différents composants et logiciels. Cela pose la question d'un possible surdimensionnement. Dans le cas d'une petite application, ou d'un projet sans challenge particulier en termes de scalabilité, une architecture plus basique peut suffire tout en se montrant plus économe. \n\n## Utiliser Kubernetes au sein de vos équipes\n\nDes dizaines de milliers d'entreprises ont adopté une architecture Kubernetes pour mener à bien leur transition digitale. K8s est utilisé par des sociétés de toutes tailles, des startups aux multinationales. \n\nLes exemples d'intégrations réalisées avec succès sont nombreux, comme pour la société Haven Technologies. Haven Technologies a migré ses services SaaS vers K8s et mise notamment sur une stratégie Kubernetes avec la plateforme DevSecOps de GitLab afin d’aider ses équipes à améliorer l'efficacité, la sécurité et la vitesse de développement logiciel. Consultez [notre cas client](https://about.gitlab.com/customers/haven-technologies/ \"Cas client Haven Technologies\") pour en savoir plus !   \n\n## Kubernetes, Git et GitLab\n\nKubernetes, Git et GitLab sont des éléments essentiels du paysage [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ? \"). Kubernetes offre une grande flexibilité pour déployer et gérer les différents composants d’une application. De son côté, GitLab construit autour de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") et de son système de contrôle de version natif, permet un suivi rigoureux et précis du code source et des changements, tout en fournissant une suite d'outils complète pour gérer l'ensemble du cycle de vie du développement logiciel. \n\nCette combinaison, associée à une [approche GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Approche GitOps\"), dont l’objectif est d’automatiser le provisionnement des infrastructures cloud modernes, crée un environnement agile de développement et déploiement des applications et permet ainsi de fournir des logiciels puissants, flexibles et évolutifs. Pour aller plus loin, [découvrez toutes les solutions de GitLab pour lancer une application avec Kubernetes](https://about.gitlab.com/fr-fr/solutions/kubernetes/ \"Solutions GitLab pour lancer une application avec Kubernetes\"). \n\n## FAQ sur Kubernetes\n\n### Quelles sont les solutions concurrentes à K8s ?\n\nIl existe plusieurs alternatives à Kubernetes, parmi lesquelles Docker Swarm ou Marathon. Cependant, Kubernetes est considérée comme la solution la plus mature et la plus populaire sur le marché. Sa large base d'utilisateurs, sa documentation abondante et son support actif par la communauté font de Kubernetes un excellent choix pour ceux qui cherchent à adopter un système d'orchestration de conteneurs.\n\n### Qu’est-ce qu’un cluster Kubernetes ?\n\nUn cluster Kubernetes est composé d'un nœud maître et de plusieurs nœuds de travail. Le nœud maître est responsable de la coordination des tâches dans le cluster, tandis que les nœuds de travail exécutent ces tâches d'orchestration et hébergent les conteneurs. Les clusters K8s sont hautement évolutifs - on peut ajouter ou supprimer des nœuds pour adapter les ressources du cluster aux besoins de l'application.\n\n### Quelle est la différence entre Kubernetes et Docker ?\n\nDocker permet de créer, exécuter et gérer des conteneurs individuellement, tandis que Kubernetes orchestre ces conteneurs sur un cluster en automatisant leur déploiement, mise à l’échelle et maintenance. Docker gère l’environnement d’exécution, Kubernetes assure la coordination et la résilience des applications conteneurisées.\n\n### Comment débuter avec Kubernetes ?\n\nPour commencer, il est nécessaire d'installer le logiciel Kubernetes sur un environnement compatible (Linux, macOS ou Windows). Kubernetes peut être installé au sein d'un hébergement classique mais aussi dans un environnement cloud ([Google Kubernetes Engine](https://about.gitlab.com/fr-fr/partners/technology-partners/google-cloud-platform/ \"Google Kubernetes Engine\") ou [Amazon EKS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/ \"Amazon EKS\") par exemple). Les utilisateurs peuvent télécharger et installer Kubernetes directement depuis leur site officiel, puis procéder à la configuration initiale nécessaire pour connecter les nœuds maître et de travail. Une fois cette étape réalisée, l'utilisateur est prêt à déployer une première application en utilisant Kubernetes.\n\n### Pourquoi choisir Kubernetes ?\n\nKubernetes offre une grande flexibilité et une portabilité totale entre différentes plateformes cloud ou infrastructures sur site. Grâce à l'automatisation des tâches d'orchestration, K8s permet d'optimiser les ressources, de réduire les coûts d'exploitation et de libérer du temps pour les développeurs et les administrateurs systèmes. Enfin, l'écosystème Kubernetes est vaste et continuellement développé par une large communauté open source, ce qui permet d'innover rapidement.\n",[833,683],{"slug":1038,"featured":6,"template":685},"kubernetes-the-container-orchestration-solution","content:fr-fr:blog:kubernetes-the-container-orchestration-solution.yml","Kubernetes The Container Orchestration Solution","fr-fr/blog/kubernetes-the-container-orchestration-solution.yml","fr-fr/blog/kubernetes-the-container-orchestration-solution",{"_path":1044,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":1045,"content":1051,"config":1058,"_id":1060,"_type":16,"title":1061,"_source":18,"_file":1062,"_stem":1063,"_extension":21},"/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1046,"description":1047,"ogTitle":1046,"ogDescription":1047,"noIndex":6,"ogImage":1048,"ogUrl":1049,"ogSiteName":740,"ogType":741,"canonicalUrls":1049,"schema":1050},"Format reftable de Git : guide pour les débutants","Dans la version 2.45.0 de Git, GitLab a introduit le backend « reftable », révolutionnant ainsi le stockage des références. Découvrez en détail le fonctionnement de ce nouveau format.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Format reftable de Git : guide pour les débutants\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }",{"title":1046,"description":1047,"authors":1052,"heroImage":1048,"date":1053,"body":1054,"category":14,"tags":1055,"updatedDate":1057},[767],"2024-05-30","Jusqu'à récemment, Git ne pouvait stocker des références qu'au format « fichiers ». Avec la [version 2.45.0 de Git](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-45-0/), Git peut désormais stocker des références au format « reftable ». Ce nouveau format binaire est un peu plus complexe, mais c'est précisément cette complexité qui lui permet de corriger plusieurs lacunes du format « fichiers ». Les objectifs du format « reftable » sont les suivants :\n\n- Rendre la recherche d'une référence unique et l'itération à travers des plages de références aussi efficaces et rapides que possible.\n- Prendre en charge des lectures cohérentes des références afin que Git ne lise jamais un état intermédiaire lorsqu'une mise à jour de plusieurs références n'a été appliquée que partiellement.\n- Prendre en charge des écritures atomiques de sorte que la mise à jour de plusieurs références peut être effectuée comme une opération tout ou rien.\n- Stocker efficacement des références et des journaux de référence (« reflog »).\n\nDans cet article, nous allons examiner le format « reftable » pour comprendre son fonctionnement.\n\n## Stockage des références dans Git\n\nAvant d'entrer dans les détails, récapitulons rapidement la façon dont [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \") stockait les références jusqu'à présent. Si le sujet vous est familier, vous pouvez passer cette section.\n\nUn dépôt Git contient deux structures de données importantes :\n\n- [Les objets](https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Les-objets-de-Git), qui contiennent les données réelles de votre dépôt. Ils incluent les validations (« commits »), la structure d'arborescence des répertoires (« tree ») et les blobs qui contiennent votre code source. Les objets sont organisés de manière à ce qu'ils pointent les uns vers les autres, formant ainsi un graphe des objets. En outre, chaque objet est associé à un identifiant unique, appelé ID d'objet.\n\n- Les références, telles que les branches et les étiquettes (« tags »). Ces pointeurs sur des objets du graphe vous permettent de donner des noms à des objets qui sont plus faciles à mémoriser et de suivre les différentes étapes et directions de votre historique de développement. Par exemple, un dépôt peut contenir une branche `main` : il s'agit d'une référence nommée `refs/heads/main` qui pointe vers une validation spécifique.\n\nLes références sont stockées dans la base de données des références. Jusqu'à la version 2.45.0 de Git, le format « fichiers » constituait le seul format de base de données disponible. Ce format stocke chaque référence en tant que fichier normal contenant l'un des éléments suivants :\n\n- Une référence standard qui contient l'ID d'objet de la validation vers laquelle elle pointe.\n- Une référence symbolique qui contient le nom d'une autre référence, de la même manière qu'un lien symbolique pointe vers un autre fichier.\n\nCes références sont régulièrement empaquetées dans un seul fichier `packed-refs` afin de faciliter les recherches.\n\nLes exemples suivants illustrent le fonctionnement du format « fichiers » :\n\n```shell\n$ git init .\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 6917c17] Initial commit\n\n# HEAD is a symbolic reference pointing to refs/heads/main.\n$ cat .git/HEAD\nref: refs/heads/main\n\n# refs/heads/main is a regular reference pointing to a commit.\n$ cat .git/refs/heads/main\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n# git-pack-refs(1) packs these references into the packed-refs file.\n$ git pack-refs --all\n$ cat .git/packed-refs\n# pack-refs with: peeled fully-peeled sorted\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n```\n\n## Vue d'ensemble de la structure « reftable » \n\nSi vous avez installé la version 2.45.0 de Git ou une version plus récente, vous pouvez créer un dépôt au format « reftable » en utilisant l'option `--ref-format=reftable` :\n\n```shell\n$ git init --ref-format=reftable .\nInitialized empty Git repository in /tmp/repo/.git/\n$ git rev-parse --show-ref-format\nreftable\n\n# Irrelevant files have been removed for ease of understanding.\n$ tree .git\n.git\n├── config\n├── HEAD\n├── index\n├── objects\n├── refs\n│   └── heads\n└── reftable\n\t├── 0x000000000001-0x000000000002-40a482a9.ref\n\t└── tables.list\n\n4 directories, 6 files\n```\n\nRegardez la configuration du dépôt. Remarquez tout d'abord sa clé de configuration `extension.refstorage` :\n\n```shell\n$ cat .git/config\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\nCette configuration indique à Git que le dépôt a été initialisé avec le format « reftable » et que Git doit utiliser le backend « reftable » pour y accéder.\n\nCurieusement, le dépôt contient encore des fichiers qui semblent utilisés par le backend « fichiers » :\n\n- `HEAD` est une référence symbolique dans Git qui indique généralement la branche sur laquelle vous travaillez actuellement. Bien que le format « reftable » n'utilise pas HEAD, la présence de cette référence est nécessaire pour qu'un répertoire soit reconnu comme un dépôt Git par les clients Git. Par conséquent, lorsque vous utilisez le format « reftable », `HEAD` est juste une entité fictive et temporaire dont le contenu est `ref: refs/heads/.invalid`.\n\n- `refs/head` est un fichier dont le contenu est : `this repository uses the reftable format`. Les clients Git qui ne connaissent pas le format « reftable » s'attendent généralement à ce que le chemin d'accès soit un répertoire. Par conséquent, la création de ce chemin d'accès en tant que fichier entraîne intentionnellement l'échec des anciens clients Git s'ils tentent d'accéder au dépôt par le biais du backend « fichiers ».\n\nLes références réelles sont stockées dans le répertoire `reftable/` :\n\n```shell\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000001-794bd722.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000001-794bd722.ref\n```\n\nIl y a ici deux fichiers :\n\n- `0x000000000001-0x000000000001-794bd722.ref` est une table contenant des références et des données de reflog dans un format binaire.\n\n- `tables.list` est, comme son nom l'indique, une liste de tables. Dans l'état actuel du dépôt, le fichier contient une seule ligne, qui est le nom de la table. Ce fichier suit l'ensemble actuel des tables actives dans la base de données « reftable ». Il est mis à jour chaque fois que de nouvelles tables sont ajoutées au dépôt.\n\nLa mise à jour d'une référence crée une nouvelle table :\n\n```shell\n$ git commit --allow-empty --message \"Initial commit\"\n[main (root-commit) 1472a58] Initial commit\n\n$ tree .git/reftable\n.git/reftable/\n├── 0x000000000001-0x000000000002-eb87d12b.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000002-eb87d12b.ref\n```\n\nComme vous pouvez le constater, la table précédente a été remplacée par une nouvelle. En outre, le fichier `tables.list` a été mis à jour pour contenir la nouvelle table.\n\n## Structure d'une table\n\nComme mentionné précédemment, les données réelles de la base de données des références sont contenues dans des tables. Pour faire simple, une table se divise en plusieurs sections :\n\n- L'en-tête contient des métadonnées sur la table. En plus d'autres informations, il inclut la version du format, la taille des blocs de données et la fonction de hachage utilisée par le dépôt (par exemple, SHA1 ou SHA256).\n- La section « ref » contient vos références. Ces enregistrements ont une clé identique au nom de la référence et pointent soit vers un ID d'objet pour les références standards, soit vers une autre référence pour les références symboliques.\n- La section « obj » contient la correspondance inverse entre les ID d'objet et les références qui pointent vers eux. Celle-ci permet à Git de rechercher efficacement les références qui pointent vers un ID d'objet spécifique.\n- La section « log » contient vos éléments reflog. Ces enregistrements ont une clé identique au nom de la référence, plus un index qui représente le numéro de l'élément du journal. Ils contiennent en outre les anciens et nouveaux ID d'objet, ainsi que le message pour cet élément reflog.\n- Le « footer » contient des offsets pour les différentes sections.\n\n![table longue avec toutes les sections reftable](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\nChaque type de section est structuré de manière similaire. Les sections contiennent un ensemble d'enregistrements qui sont classés en fonction de la clé de chaque enregistrement. Par exemple, lorsque vous avez ces deux enregistrements de références : `refs/heads/aaaaa` et `refs/heads/bbb`, vous avez deux enregistrements de références dont les noms de référence sont les clés respectives, et `refs/heads/aaaaa` vient avant `refs/heads/bbb`.\n\nChaque section est par ailleurs divisée en blocs d'une longueur fixe. La longueur d'un bloc est encodée dans l'en-tête et remplit deux fonctions :\n\n- En se basant sur le début de la section ainsi que la taille des blocs de données, le processus qui lit les tables sait implicitement où chacun des blocs commence. Git peut ainsi facilement effectuer une recherche au milieu d'une section sans lire les blocs précédents, ce qui permet d'effectuer des recherches par dichotomie sur des blocs pour accélérer la recherche d'enregistrements.\n- Elle permet au processus qui lit les tables de savoir combien de données lire sur le disque à la fois. Par conséquent, la taille des blocs de données est par défaut définie à 4 KiB, ce qui correspond à la taille de secteur la plus courante pour les disques durs. La taille maximale des blocs de données est de 16 Mo.\n\nIntéressons-nous à une section « ref » : elle ressemble à peu près au graphique suivant. Notez comment ses enregistrements sont ordonnés lexicographiquement à l'intérieur des blocs, mais aussi entre différents blocs.\n\n![bloc de référence non compressé](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\nMaintenant que vous disposez de ces informations, vous pouvez localiser un enregistrement en suivant les étapes suivantes :\n\n1. Effectuez une recherche par dichotomie sur les blocs en regardant les clés de leurs premiers enregistrements respectifs, ce qui permet d'identifier le bloc qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche linéaire sur les enregistrements de ce bloc.\n\nCes deux étapes sont encore quelque peu inefficaces. S'il y a beaucoup de blocs, vous devrez peut-être effectuer une lecture logarithmique d'un bon nombre d'entre eux au cours de la recherche par dichotomie pour trouver celui que vous recherchez. Et lorsque les blocs contiennent de nombreux enregistrements, une recherche linéaire doit potentiellement tous les lire.\n\nLe format « reftable » intègre des mécanismes supplémentaires pour résoudre ces problèmes de performance. Nous les mentionnerons dans les prochaines sections.\n\n### Compression de préfixe\n\nComme vous l'avez peut-être remarqué, toutes les clés d'enregistrement partagent le même préfixe `refs/`. C'est une norme établie dans Git :\n\n- Toutes les branches commencent par `refs/heads/`.\n- Toutes les étiquettes (« tags ») commencent par `refs/tags/`.\n\nPar conséquent, il est très probable que les enregistrements suivants partagent une partie importante du préfixe de leur clé. C'est une bonne occasion d'économiser de l'espace de stockage précieux. Comme nous savons que la plupart des clés partagent un préfixe commun, il est logique d'utiliser ce dernier à des fins d'optimisation.\n\nCelle-ci passe par la compression de préfixe. Chaque enregistrement encode une longueur de préfixe qui indique au processus qui lit les tables le nombre d'octets à réutiliser à partir de la clé de l'enregistrement précédent. Si vous avez deux enregistrements, `refs/heads/a` et `refs/heads/b`, ce dernier peut être encodé en spécifiant une longueur de préfixe de 11, puis en stockant uniquement le suffixe `b`. Le processus qui lit les tables prendra alors les 11 premiers octets de `refs/heads/a`, c'est-à-dire `refs/heads/`, et y ajoutera le suffixe `b`.\n\n![compression de préfixe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n### « Restart points »\n\nComme expliqué précédemment et d'après vos connaissances actuelles du format « reftable », une recherche linéaire constitue la meilleure façon de chercher une référence dans un bloc, car la longueur des enregistrements n'est pas fixe. Il est donc impossible de savoir où les enregistrements devraient commencer sans parcourir l'intégralité du bloc depuis le début. En outre, même si les enregistrements étaient de longueur fixe, il ne serait pas possible de rechercher au milieu d'un bloc, car la compression de préfixe nous oblige également à lire les enregistrements précédents.\n\nUne recherche linéaire serait assez inefficace, dans la mesure où les blocs peuvent contenir des centaines, voire des milliers d'enregistrements. Pour résoudre ce problème, le format « reftable » encode des « restart points » dans chaque bloc. Les « restart points » sont des enregistrements non compressés où la compression de préfixe est réinitialisée. Par conséquent, les enregistrements des « restart points » contiennent toujours leur clé complète. Il devient donc possible de rechercher et de lire directement l'enregistrement, sans avoir à lire les enregistrements précédents. Ces « restart points » sont répertoriés dans le footer de chaque bloc.\n\nGrâce à ces informations, vous pouvez maintenant éviter d'effectuer une recherche linéaire sur le bloc. Effectuez plutôt une recherche par dichotomie sur les « restart points » en cherchant le premier « restart point » dont la clé est lexicographiquement supérieure à la clé recherchée. Il s'ensuit que l'enregistrement que vous recherchez doit être situé dans la section s'étendant entre le « restart point » _précédent_ et celui identifié.\n\nLa procédure initiale pour rechercher un enregistrement (recherche par dichotomie du bloc, recherche linéaire de l'enregistrement) est donc la suivante :\n\n1. Effectuez une recherche par dichotomie sur les blocs, pour identifier celui qui doit contenir l'enregistrement.\n\n2. Effectuez une recherche par dichotomie sur les « restart points », en identifiant la sous-section du bloc qui doit contenir l'enregistrement.\n\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n![Recherche linéaire pour un enregistrement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n### Index\n\nBien que la recherche d'enregistrements à l'intérieur d'un bloc soit désormais raisonnablement efficace, ce n'est pas le cas pour l'identification du bloc spécifique. Une recherche par dichotomie peut être relativement performante sur quelques blocs, mais les dépôts contenant des millions de références peuvent comporter des centaines, voire des milliers de blocs. En l'absence d'une structure de données supplémentaire visant à minimiser les accès au disque, chaque recherche de bloc pourrait entraîner en moyenne un nombre important d'accès au disque.\n\nPour éviter cette situation, chaque section peut être suivie d'une section d'indexation qui fournit un moyen efficace de rechercher un bloc. Chaque enregistrement d'index contient les informations suivantes :\n\n- L'emplacement du bloc qu'il indexe.\n- La clé du dernier enregistrement du bloc qu'il indexe.\n\nPour trois blocs ou moins, une recherche par dichotomie nécessite toujours, au plus, deux lectures de disque pour trouver le bloc cible souhaité. Le nombre de lectures est le même pour un index : une pour lire l'index et une pour lire le bloc souhaité. Par conséquent, les index ne sont écrits que lorsqu'ils évitent de fait plusieurs lectures, ce qui est le cas lorsque quatre blocs ou plus sont indexés.\n\nLa question se pose alors de savoir ce qu'il se passe lorsque l'index lui-même devient si grand qu'il s'étend sur plusieurs blocs. Vous l'avez peut-être deviné : nous écrivons un nouvel index qui indexe l'index. Ces index à plusieurs niveaux ne deviennent vraiment nécessaires que lorsque vos dépôts contiennent des centaines de milliers de références.\n\nÀ l'aide de ces index, vous pouvez désormais accélérer la recherche d'enregistrements :\n1. Déterminez s'il existe un index en consultant le footer de la table.\n\t- Si c'est le cas, effectuez une recherche par dichotomie dans l'index pour trouver le bloc souhaité. Ce bloc peut pointer vers un bloc d'index, auquel cas il vous faut répéter l'opération jusqu'à atteindre un enregistrement du type souhaité.\n\t- Dans le cas contraire, effectuez une recherche par dichotomie dans les blocs comme auparavant.\n2. Effectuez une recherche par dichotomie sur les « restart points » pour identifier la sous-section du bloc qui doit contenir l'enregistrement.\n3. Effectuez une recherche linéaire sur les enregistrements de cette sous-section.\n\n## Tables multiples\n\nJusqu'à présent, nous n'avons discuté que de la façon de lire une table _unique_. Comme l'indique le nom `tables.list`, votre base de données « reftable » peut contenir une liste de tables.\n\nChaque fois que vous mettez à jour une référence dans votre dépôt, une nouvelle table est créée et ajoutée à `tables.list`. Vous obtiendrez donc plusieurs tables, comme suit :\n\n```shell\n$ tree .git/reftable/\n.git/reftable/\n├── 0x000000000001-0x000000000007-8dcd8a77.ref\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n└── tables.list\n\n$ cat .git/reftable/tables.list\n0x000000000001-0x000000000007-8dcd8a77.ref\n0x000000000008-0x000000000008-30e0f6f6.ref\n```\nLa lecture de l'état réel d'un dépôt nous oblige à fusionner ces multiples tables en une seule table virtuelle.\n\nVous vous demandez peut-être comment le format « reftable » connaît la valeur la plus récente d'une référence donnée, si une table est créée pour chaque mise à jour de référence et que la même référence est mise à jour plusieurs fois. Intuitivement, on pourrait supposer que la valeur serait celle de la table la plus récente contenant la référence.\n\nEn réalité, chaque enregistrement a un index de mise à jour qui encode la « priorisation » d'un enregistrement. Par exemple, s'il existe deux enregistrements pour le même nom de référence, celui qui a l'index de mise à jour le plus élevé remplace celui qui a l'index de mise à jour le plus bas.\n\nCes index de mise à jour sont visibles dans la structure de fichiers ci-dessus. Les longues chaînes hexagonales (par exemple `0x000000000001`) sont les index de mise à jour. L'index de mise à jour minimum contenu dans la table se trouve dans la partie gauche de son nom de fichier et l'index de mise à jour maximum dans la partie droite.\n\nLe merge des tables se fait ensuite via une [file d'attente de priorisation](https://fr.wikipedia.org/wiki/File_de_priorit%C3%A9) qui est triée par clé d’enregistrement ainsi que son index de mise à jour. Imaginez que vous voulez parcourir tous les enregistrements de références. Vous devez suivre les étapes suivantes :\n\n1. Pour chaque table, ajoutez son premier enregistrement à la file d'attente de priorisation.\n\n![Ajout du premier enregistrement à la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n2. Récupérez et retirez de la file d'attente l'enregistrement en tête de la file. Comme la file d'attente est triée par index de mise à jour, cet enregistrement doit être la version la plus récente. Ajoutez l'enregistrement suivant de la table de cet enregistrement à la file d'attente de priorisation.\n\n![Définition de la tête de la file d'attente de priorisation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n3. Retirez tous les enregistrements de la file d'attente qui ont la même clé que l’enregistrement récupéré. Ces enregistrements sont dépassés et ne seront pas utilisés. Pour chaque table pour laquelle vous supprimez des enregistrements, ajoutez l'enregistrement suivant à la file d'attente de priorisation.\n\n![Dépôt de tous les enregistrements de la file qui ont le même nom](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\nVous pouvez maintenant répéter les étapes ci-dessus pour lire les enregistrements pour d'autres clés.\n\nLes tables peuvent contenir des enregistrements spéciaux « tombstone » qui marquent un enregistrement supprimé. Vous pouvez ainsi supprimer des enregistrements sans avoir à réécrire toutes les tables afin qu'elles ne contiennent plus ces enregistrements.\n\n### Compactage automatique\n\nLa file d'attente de priorisation a beau être un concept simple, elle ne parviendrait pas à fusionner efficacement des centaines de tables, ni même des dizaines. S'il est vrai que chaque mise à jour de vos références ajoute une nouvelle table à votre fichier `tables.list`, ce n'est pas tout.\n\nLe compactage automatique entre ici en scène : lorsqu'une nouvelle table a été ajoutée à la liste des tables, le backend « reftable » vérifie si certaines des tables doivent être fusionnées. Ce processus utilise une méthode simple : nous vérifions que les tailles de fichiers de la liste des tables forment une [séquence géométrique](https://en.wikipedia.org/wiki/Geometric_progression). Chaque table `n` doit être au moins deux fois plus grande que la table suivante la plus récente `n + 1`. Si cette séquence géométrique n'est pas respectée, le backend compacte les tables afin de restaurer la séquence géométrique.\n\nCe processus aboutit à des structures de ce type :\n\n```shell\n$ du --apparent-size .git/reftable/*\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n1    .git/reftable/tables.list\n```\n\nNotez que la propriété `size(n) > size(n+1) * 2` est respectée pour chaque table.\n\nL'une des conséquences du compactage automatique est la maintenance automatique du backend « reftable ». Il n'est plus nécessaire d'exécuter `git pack-refs` dans un dépôt.\n\n## Vous souhaitez en savoir plus ?\n\nÀ présent, le fonctionnement du nouveau format « reftable » ne devrait plus avoir de secret pour vous. Si vous souhaitez approfondir vos connaissances, vous pouvez consulter la [documentation technique](https://git-scm.com/docs/reftable) fournie par le projet Git.\n\n> Lisez notre [récapitulatif sur Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/), [Git 2.46.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-46-0/ \"Nouveautés Git 2.46.0\") et Git [2.47.0](https://about.gitlab.com/fr-fr/blog/whats-new-in-git-2-47-0/ \"Nouveautés Git 2.47.0\") pour découvrir les autres points forts de cette version.",[682,834,683,1056],"performance","2024-12-19",{"slug":1059,"featured":93,"template":685},"a-beginners-guide-to-the-git-reftable-format","content:fr-fr:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","fr-fr/blog/a-beginners-guide-to-the-git-reftable-format.yml","fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",{"_path":1065,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":1066,"content":1071,"config":1076,"_id":1078,"_type":16,"title":1079,"_source":18,"_file":1080,"_stem":1081,"_extension":21},"/fr-fr/blog/whats-new-in-git-2-45-0",{"title":1067,"description":949,"ogTitle":1067,"ogDescription":949,"noIndex":6,"ogImage":1068,"ogUrl":1069,"ogSiteName":740,"ogType":741,"canonicalUrls":1069,"schema":1070},"Nouveautés de Git 2.45.0","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.45.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":1067,"description":949,"authors":1072,"heroImage":1068,"date":1073,"body":1074,"category":14,"tags":1075},[767],"2024-04-30","Le projet Git a récemment publié la [version 2.45.0 de\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/). Jetons un\ncoup d'œil aux points forts de cette version, comprenant des contributions\nde l'équipe Git de GitLab et de la communauté Git au sens large.\n\n\n## Reftables : un nouveau backend pour le stockage des références\n\n\nChaque dépôt Git doit suivre deux structures de données de base :\n\n- Le graphique qui stocke les données de vos fichiers, la structure de\nrépertoires, les messages de commit et les tags.\n\n- Les références qui sont des pointeurs dans ce graphique pour associer des\nobjets spécifiques à un nom plus accessible. Par exemple, une branche est\nune référence dont le nom commence par un préfixe `refs/heads/`. \n\n\nLe format sur disque de stockage des références dans un dépôt est resté\nlargement inchangé depuis la création de Git et est appelé le format «\nfichiers ». Chaque fois que vous créez une référence, Git crée une «\nréférence libre » qui correspond à un fichier ordinaire dans votre dépôt Git\ndont le chemin d'accès correspond au nom de la référence.\n\n\nPar exemple : \n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose\nref is\n\n# a simple file which contains the object ID of the commit.\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# Creating a second reference will end up with a second loose ref.\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\nIl arrive que Git empaquette ces références dans un format de fichier «\nempaqueté » pour que la recherche de références soit plus efficace. Par\nexemple :\n\n\n```shell\n\n# Packing references will create \"packed\" references, which are a sorted\nlist of\n\n# references. The loose reference does not exist anymore.\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\n\nBien qu'il soit relativement simple, ce format comporte certaines limites :\n\n\n- Dans les mono repos contenant de nombreuses références, nous avons\ncommencé à nous heurter à des problèmes d'évolutivité. La suppression des\nréférences est particulièrement inefficace car l'ensemble du fichier «\npacked-refs » doit être réécrit pour supprimer la référence supprimée. Dans\nnos plus grands dépôts, cela peut entraîner la réécriture de plusieurs\ngigaoctets de données à chaque suppression de référence. \n\n- Il est impossible d'effectuer une lecture atomique des références sans\nbloquer les rédacteurs simultanés, car il est nécessaire de lire plusieurs\nfichiers pour comprendre toutes les références.\n\n- Il est impossible d'effectuer une écriture atomique, car elle nécessite la\ncréation ou la mise à jour de plusieurs fichiers, ce qui est impossible en\nune seule étape. \n\n- La maintenance des références ne s'adapte pas bien, parce que vous devez\nréécrire le fichier « packed-refs » entièrement. \n\n- Étant donné que les références libres utilisent le chemin d'accès du\nsystème de fichiers comme nom, elles sont soumises à un comportement\nspécifique au système de fichiers. Par exemple, les systèmes de fichiers\ninsensibles à la casse ne peuvent pas stocker des références pour lesquelles\nseule la casse diffère.\n\n\nPour résoudre ces problèmes, Git v2.45.0 introduit un nouveau backend «\nreftable », qui utilise un nouveau format binaire pour stocker les\nréférences. Ce nouveau backend est en développement depuis très longtemps.\nIl a été initialement proposé par [Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) en juillet\n2017 et a été mis en place pour la première fois dans\n[JGit](https://www.eclipse.org/jgit/ \"JGit\"). Il est largement utilisé par\nle [projet Gerrit](https://www.gerritcodereview.com/ \"Projet Gerrit\"). En\n2021, [Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/) a intégré la\nbibliothèque dans Git, ce qui lui permet de lire et d'écrire le format\nreftable. \n\n\nLe nouveau backend « reftable » que nous avons introduit dans Git v2.45.0\nrassemble enfin la bibliothèque reftable et Git de sorte qu'il est possible\nd'utiliser le nouveau format comme backend de stockage dans vos dépôts Git. \n\n\nEn supposant que vous exécutez au moins la version 2.45.0 de Git, vous\npouvez créer de nouveaux dépôts au format « reftable » en basculant\n`--ref-format=reftable` sur `git-init(1)` ou `git-clone(1)`. \n\n\nPar exemple :\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\n\nComme vous pouvez le constater, les références sont maintenant stockées dans\n`.git/reftable` au lieu du répertoire `.git/refs.` Les références et les\njournaux de référence (ou « reflogs ») sont stockés dans des « tables », qui\nsont les fichiers se terminant par `.ref`, tandis que le fichier\n`tables.list` contient la liste de toutes les tables actuellement actives. \n\n\nLe backend « reftable » est censé remplacer le backend « fichiers ». Par\nconséquent, du point de vue de l'utilisateur, tout devrait fonctionner de la\nmême manière. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\"). Le mérite revient également à Shawn\nPearce en tant qu'inventeur original du format et à Han-Wen Nienhuys en tant\nqu'auteur de la bibliothèque reftable.\n\n\n## De meilleurs outils pour les références \n\n\nAlors que le format « reftable » résout de nombreux problèmes existants, il\nen introduit également de nouveaux. L'un des problèmes les plus importants\nétant l'accessibilité des données qu'il contient. \n\n\nAvec le backend « fichiers », vous pouvez, dans le pire des cas, utiliser\nvos outils Unix habituels pour inspecter l'état des références. Les\nréférences « empaquetées » et « libres » contiennent toutes deux des données\nlisibles par l'homme et faciles à interpréter. Ce qui est différent avec le\nformat « reftable », qui est un format binaire. Par conséquent, Git doit\nfournir tous les outils nécessaires pour extraire les données du nouveau\nformat « reftable ».\n\n\n### Répertorier toutes les références\n\n\nLe premier problème que nous avons rencontré est qu'il est fondamentalement\nimpossible de connaître toutes les références connues d'un dépôt. Cela\npeut-être quelque peu déroutant au début : comment est-il possible de créer\net modifier des références via Git, qui ne peut pas énumérer de manière\nexhaustive toutes les références dont il a connaissance ?\n\n\nEn effet, le backend « fichiers » en est incapable. Alors qu'il peut\nrépertorier de manière évidente toutes les références « habituelles » qui\ncommencent par le préfixe `refs/`, Git utilise également des [pseudo\nrefs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref\n\"Les pseudo refs de Git\"). Ces fichiers se trouvent directement à la racine\ndu répertoire Git et seraient des fichiers comme, par exemple,\n`.git/MERGE_HEAD`. Le problème ici est que ces pseudo refs se trouvent à\ncôté d'autres fichiers que Git stocke comme, par exemple, `.git/config`.\n\n\nAlors que certaines pseudo refs sont bien connues et donc faciles à\nidentifier, il n'y a en théorie aucune limite aux références que Git peut\nécrire. Rien ne vous empêche de créer une référence appelée « foobar ».\n\n\nPar exemple : \n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\n\nMaintenant, le problème du backend « fichiers » est qu'il ne peut énumérer\nles références qu'en parcourant les répertoires. Donc, pour déterminer si\n`.git/foobar` est effectivement une référence, Git devrait ouvrir le fichier\net vérifier s'il est formaté ou non comme une référence. \n\n\nD'autre part, le backend « reftable » connaît de manière évidente toutes les\nréférences qu'il contient : elles sont encodées dans ses structures de\ndonnées, il lui suffit donc de décoder ces références et de les renvoyer.\nMais en raison des restrictions du backend « fichiers », il n'existe aucun\noutil qui vous permettrait de connaître toutes les références existantes. \n\n\nPour résoudre le problème, nous avons intégré un nouvel élément à\n`git-for-each-ref(1)` appelé `--include-root-refs`, ce qui lui permettra de\nrépertorier également toutes les références qui existent à la racine de la\nhiérarchie de nommage des références.\n\n\nPar exemple : \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\n\nPour le backend « fichiers », ce nouvel élément est géré au mieux et nous y\nincluons toutes les références qui correspondent à un nom de pseudo ref\nconnu. Pour le backend « reftable », nous pouvons simplement lister toutes\nles références qui lui sont connues. \n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl \"Profil\nGitLab de Karthik Nayak\").\n\n\n### Répertorier tous les reflogs \n\n\nChaque fois que vous mettez à jour des branches, Git, par défaut, suit ces\nmises à jour de branche dans un reflog. Ce reflog vous permet de rétablir\nles modifications apportées à cette branche au cas où vous auriez effectué\nune modification involontaire. \n\n\nAvec le backend « fichiers », ces journaux sont stockés dans votre\nrépertoire `.git/logs` :\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\n\nLister les fichiers dans ce répertoire est le seul moyen pour vous de savoir\nquelles références ont un reflog en premier lieu. C'est un problème pour le\nbackend « reftable », qui stocke ces journaux avec les références. Par\nconséquent, il n'existe plus aucun moyen pour vous de savoir quels reflogs\nexistent dans le dépôt lorsque vous utilisez le format « reftable ». \n\n\nIl ne s'agit pas d'une faille imputable au format « reftable », mais d'une\nomission dans les outils fournis par Git. Pour y remédier, nous avons\nintroduit une nouvelle sous-commande `list` à `git-reflog(1)` permettant de\nrépertorier tous les reflogs existants :\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n### Un empaquetage plus efficace des références \n\n\nPour rester efficaces, les dépôts Git nécessitent une maintenance régulière.\nHabituellement, cette maintenance est déclenchée par diverses commandes Git\nqui écrivent des données dans les dépôts Git en exécutant `git maintenance\nrun --auto`. Cette commande optimise uniquement les structures de données\nqui doivent être optimisées afin que Git ne gaspille pas de ressources de\ncalcul.\n\n\nUne structure de données optimisée par la maintenance de Git constitue la\nbase de données de référence, obtenue en exécutant `git pack-refs --all`.\nPour le backend « fichiers », cela signifie que toutes les références sont à\nnouveau regroupées dans le fichier « packed-refs » et que les références\nlibres sont supprimées, tandis que pour le backend « reftable », toutes les\ntables sont fusionnées en une seule table. \n\n\nPour le backend « fichiers », nous ne pouvons pas faire beaucoup mieux.\nÉtant donné que nous devons de toute façon réécrire l'ensemble du fichier «\npacked-refs », il est logique que nous souhaitions regrouper toutes les\nréférences libres. \n\n\nMais pour le backend « reftable », cette démarche est sous-optimale, car le\nbackend « reftable » s'optimise automatiquement. Chaque fois que Git ajoute\nune nouvelle table au backend « reftable », il effectue un compactage\nautomatique et fusionne les tables si nécessaire. Par conséquent, la base de\ndonnées de référence doit toujours être dans un état optimisé et la fusion\nde toutes les tables s'avère donc un effort inutile.\n\n\nDans la version 2.45.0 de Git, nous avons donc introduit un nouveau mode\n`git pack-refs --auto`, qui demande au backend de référence de s'optimiser\nsi nécessaire. Alors que le backend « fichiers » continue de fonctionner de\nla même manière même lorsque l'indicateur `--auto` est défini, le backend «\nreftable » utilise les mêmes heuristiques que celles qu'il utilise pour son\nauto-compactage. Dans la pratique, cela ne devrait pas poser de problème\ndans la plupart des cas. \n\n\nDe plus, `git maintenance run --auto` a été adapté pour transmettre\nl'indicateur `-tauto` à `git-pack-refs(1)` pour utiliser ce nouveau mode par\ndéfaut. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n## En conclusion \n\n\nCet article de blog met l'accent sur le [nouveau backend « reftable\n»](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/\n\"Format reftable de Git \"), qui nous permet de mieux évoluer dans les dépôts\nvolumineux comprenant de multiples références, ainsi que sur les outils\nconnexes que nous avons introduits en parallèle pour le faire fonctionner\ncorrectement. Cette version de Git par la communauté Git, au sens large, a\nbien entendu introduit diverses améliorations de performances, des\ncorrections de bugs et des fonctionnalités plus petites. Vous pouvez en\napprendre davantage à ce sujet dans [l'annonce officielle du projet\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Annonce\nofficielle du projet Git\").\n",[682,272],{"slug":1077,"featured":6,"template":685},"whats-new-in-git-2-45-0","content:fr-fr:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","fr-fr/blog/whats-new-in-git-2-45-0.yml","fr-fr/blog/whats-new-in-git-2-45-0",3,[692,713,733,757,778,798,819,842,863],1758662339036]