[{"data":1,"prerenderedAt":1175},["ShallowReactive",2],{"/en-us/blog/tags/open-source/":3,"navigation-fr-fr":20,"banner-fr-fr":441,"footer-fr-fr":454,"open source-tag-page-fr-fr":666},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/open-source","tags",false,"",{"tag":9,"tagSlug":10},"open source","open-source",{"template":12},"BlogTag","content:en-us:blog:tags:open-source.yml","yaml","Open Source","content","en-us/blog/tags/open-source.yml","en-us/blog/tags/open-source","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/fr-fr/main-navigation","fr-fr",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/fr-fr/","gitlab logo","header",{"text":30,"config":31},"Commencer un essai gratuit",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Contacter l'équipe commerciale",{"href":37,"dataGaName":38,"dataGaLocation":28},"/fr-fr/sales/","sales",{"text":40,"config":41},"Connexion",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"Plateforme",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":53,"config":54},"Découvrir notre plateforme",{"href":55,"dataGaName":48,"dataGaLocation":28},"/fr-fr/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":60,"config":61},"Découvrez GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":68,"config":69},"En savoir plus",{"href":70,"dataGaName":71,"dataGaLocation":28},"/fr-fr/why-gitlab/","why gitlab",{"title":73,"items":74},"Démarrer avec",[75,80,85],{"text":76,"config":77},"Ingénierie de plateforme",{"href":78,"dataGaName":79,"dataGaLocation":28},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Expérience développeur",{"href":83,"dataGaName":84,"dataGaLocation":28},"/fr-fr/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":113,"config":114},"Développement assisté par l'IA",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Gestion du code source",{"href":119,"dataGaLocation":28,"dataGaName":120},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":142,"dataGaLocation":28,"dataGaName":143},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Mesures",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Visibilité et mesures",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Gestion de la chaîne de valeur",{"href":163,"dataGaLocation":28,"dataGaName":164},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Données d'analyse et informations clés",{"href":168,"dataGaLocation":28,"dataGaName":169},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab pour",[173,178,183],{"text":174,"config":175},"Entreprises",{"href":176,"dataGaLocation":28,"dataGaName":177},"/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"PME",{"href":181,"dataGaLocation":28,"dataGaName":182},"/fr-fr/small-business/","small business",{"text":184,"config":185},"Secteur public",{"href":186,"dataGaLocation":28,"dataGaName":187},"/fr-fr/solutions/public-sector/","public sector",{"text":189,"config":190},"Tarifs",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/fr-fr/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Afficher toutes les ressources",{"href":200,"dataGaName":196,"dataGaLocation":28},"/fr-fr/resources/",[202,235,258],{"title":203,"items":204},"Premiers pas",[205,210,215,220,225,230],{"text":206,"config":207},"Installation",{"href":208,"dataGaName":209,"dataGaLocation":28},"/fr-fr/install/","install",{"text":211,"config":212},"Guides de démarrage rapide",{"href":213,"dataGaName":214,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":216,"config":217},"Apprentissage",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Documentation sur le produit",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Vidéos sur les bonnes pratiques",{"href":228,"dataGaName":229,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":231,"config":232},"Intégrations",{"href":233,"dataGaName":234,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":236,"items":237},"Découvrir",[238,243,248,253],{"text":239,"config":240},"Histoires de succès client",{"href":241,"dataGaName":242,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":249,"config":250},"Travail à distance",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":259,"items":260},"Connecter",[261,266,271,276,281],{"text":262,"config":263},"Services GitLab",{"href":264,"dataGaName":265,"dataGaLocation":28},"/fr-fr/services/","services",{"text":267,"config":268},"Communauté",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Événements",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partenaires",{"href":284,"dataGaName":285,"dataGaLocation":28},"/fr-fr/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":291,"config":292},"carte promo The Source",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lire les articles les plus récents",{"href":297,"dataGaName":298,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":300,"config":301,"lists":303},"Société",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"À propos",{"href":309,"dataGaName":310,"dataGaLocation":28},"/fr-fr/company/","about",{"text":312,"config":313,"footerGa":316},"Emplois",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Leadership",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Équipe",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Manuel",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Relations avec les investisseurs",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Centre de confiance",{"href":342,"dataGaName":343,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":345,"config":346},"Centre pour la transparence de l'IA",{"href":347,"dataGaName":348,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Nous contacter",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Aide",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Portail clients GitLab",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Fermer",{"text":381,"link":382},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Suggestions",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Suggestions de code (IA)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab sur AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab sur Google Cloud ",{"href":408,"dataGaName":409,"dataGaLocation":386},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Commencer votre essai gratuit",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"Icône GitLab",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"titleMobile":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":445,"config":446},"Essayer la version bêta",{"href":447,"dataGaName":448,"dataGaLocation":28},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":662,"_type":14,"title":663,"_source":16,"_file":664,"_stem":665,"_extension":19},"/shared/fr-fr/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":653},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":459,"config":460},"Afficher le code source de la page",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Modifier cette page",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Veuillez contribuer",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,557,590,624],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"Plateforme DevSecOps",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Voir les forfaits",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Pourquoi choisir GitLab Premium ?",{"href":496,"dataGaName":497,"dataGaLocation":463},"/fr-fr/pricing/premium/","why premium",{"text":499,"config":500},"Pourquoi choisir GitLab Ultimate ?",{"href":501,"dataGaName":502,"dataGaLocation":463},"/fr-fr/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Solutions",[506,511,514,516,521,526,530,533,536,541,543,545,547,552],{"text":507,"config":508},"Transformation digitale",{"href":509,"dataGaName":510,"dataGaLocation":463},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sécurité et conformité",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Développement agile",{"href":519,"dataGaName":520,"dataGaLocation":463},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Transformation cloud",{"href":524,"dataGaName":525,"dataGaLocation":463},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/fr-fr/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":184,"config":546},{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":548,"config":549},"Formation",{"href":550,"dataGaName":551,"dataGaLocation":463},"/fr-fr/solutions/education/","education",{"text":553,"config":554},"Services financiers",{"href":555,"dataGaName":556,"dataGaLocation":463},"/fr-fr/solutions/finance/","financial services",{"title":194,"links":558},[559,561,563,565,568,570,574,576,578,580,582,584,586,588],{"text":206,"config":560},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":562},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":564},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":566},{"href":223,"dataGaName":567,"dataGaLocation":463},"docs",{"text":244,"config":569},{"href":246,"dataGaName":247},{"text":571,"config":572},"Histoires de réussite client",{"href":573,"dataGaLocation":463},"/customers/",{"text":239,"config":575},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":577},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":579},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":581},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":583},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":585},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":587},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":589},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":591},[592,594,596,598,600,602,604,608,613,615,617,619],{"text":307,"config":593},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":595},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":597},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":599},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":601},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":603},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":605,"config":606},"Sustainability",{"href":607,"dataGaName":605,"dataGaLocation":463},"/sustainability/",{"text":609,"config":610},"Diversité, inclusion et appartenance (DIB)",{"href":611,"dataGaName":612,"dataGaLocation":463},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":614},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":616},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":618},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":620,"config":621},"Déclaration de transparence sur l'esclavage moderne",{"href":622,"dataGaName":623,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":360,"links":625},[626,629,631,633,638,643,648],{"text":627,"config":628},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":630},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":632},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":634,"config":635},"Statut",{"href":636,"dataGaName":637,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":639,"config":640},"Conditions d'utilisation",{"href":641,"dataGaName":642},"/terms/","terms of use",{"text":644,"config":645},"Déclaration de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":463},"/fr-fr/privacy/","privacy statement",{"text":649,"config":650},"Préférences en matière de cookies",{"dataGaName":651,"dataGaLocation":463,"id":652,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,660],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":463},{"text":658,"config":659},"Politique de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":463},{"text":649,"config":661},{"dataGaName":651,"dataGaLocation":463,"id":652,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"allPosts":667,"featuredPost":1153,"totalPagesCount":1173,"initialPosts":1174},[668,693,713,733,755,778,803,823,845,865,885,909,932,953,972,992,1011,1031,1050,1069,1088,1108,1129],{"_path":669,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":678,"config":686,"_id":689,"_type":14,"title":690,"_source":16,"_file":691,"_stem":692,"_extension":19},"/fr-fr/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":671,"description":672,"ogTitle":671,"ogDescription":672,"noIndex":6,"ogImage":673,"ogUrl":674,"ogSiteName":675,"ogType":676,"canonicalUrls":674,"schema":677},"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","https://about.gitlab.com","article","\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":671,"description":672,"authors":679,"heroImage":673,"date":681,"body":682,"category":10,"tags":683,"updatedDate":685},[680],"Patrick Steinhardt","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/)",[9,684],"git","2025-04-22",{"slug":687,"featured":91,"template":688},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","BlogPost","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":694,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":695,"content":698,"config":707,"_id":709,"_type":14,"title":710,"_source":16,"_file":711,"_stem":712,"_extension":19},"/fr-fr/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":696,"description":697},"Trouvez rapidement du code dans vos dépôts GitLab","Découvrez comment trouver des correspondances exactes, utiliser des motifs regex et afficher des résultats contextuels dans des codes sources de plusieurs téraoctets. ",{"title":699,"description":697,"authors":700,"heroImage":702,"date":703,"body":704,"category":705,"tags":706},"Recherche exacte de code : trouvez rapidement du code dans vos dépôts",[701],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-23","Imaginez pouvoir cibler n'importe quelle ligne de code parmi 48 To de dépôts\nen quelques millisecondes. Ceci est désormais possible avec la\nfonctionnalité de [recherche exacte de\ncode](https://docs.gitlab.com/ee/user/search/exact_code_search.html) de\nGitLab qui fournit une précision extrême, une prise en charge avancée des\nexpressions régulières (regex) et des résultats contextuels sur plusieurs\nlignes. En présence de dépôts de code volumineux, cette fonctionnalité\nfacilite considérablement le travail des équipes.\n\n\n## Pourquoi la recherche de code traditionnelle est-elle problématique ?\n\n\nToute personne travaillant avec du code connaît la frustration de devoir chercher du code dans plusieurs dépôts. Qu'il s'agisse de déboguer un problème, d'examiner des fichiers de configuration, de rechercher des vulnérabilités, de mettre à jour une documentation ou de vérifier la mise en œuvre d'un projet, vous savez exactement ce que vous cherchez, mais les outils de recherche traditionnels vous font régulièrement défaut.\n\n\nCes outils renvoient trop souvent des dizaines de faux positifs, manquent cruellement de contexte pour comprendre les résultats obtenus et sont de plus en plus lents à mesure que le code source s’étoffe. Par conséquent, vous perdez un temps précieux à chercher une aiguille dans une botte de foin au lieu de compiler, de sécuriser ou d'améliorer votre logiciel.\n\n\nLa fonctionnalité de recherche de code de GitLab était jusqu'ici prise en charge par Elasticsearch ou OpenSearch. Bien qu'excellents pour rechercher des tickets, des merge requests, des commentaires et d'autres données contenant du langage naturel, ces outils n'ont tout simplement pas été spécifiquement conçus pour le code. Après [avoir évalué de nombreuses options](https://gitlab.com/groups/gitlab-org/-/epics/7404), nous avons développé une meilleure solution.\n\n\n## Qu'est-ce que la recherche exacte de code ?\n\n\nLa **[recherche exacte de code](https://docs.gitlab.com/ee/user/search/exact_code_search.html)** de GitLab est actuellement en phase de test bêta et optimisée par [Zoekt](https://github.com/sourcegraph/zoekt) (prononcé « zookt », qui signifie « recherche » en néerlandais). Zoekt est un moteur de recherche de code open source initialement développé par Google et aujourd'hui maintenu par Sourcegraph. Conçu spécifiquement pour une recherche de code à la fois rapide et précise à grande échelle, nous l'avons enrichi avec des intégrations propres à GitLab, des améliorations avancées et une intégration facilitée du système d'autorisations.\n\n\nCette fonctionnalité révolutionne la manière dont vous recherchez et comprenez le code grâce aux trois éléments clés :\n\n\n**1. Un mode de recherche par correspondance exacte**\n\n\nLorsque vous basculez en **mode de recherche par correspondance exacte**, le moteur de recherche ne renvoie que les résultats qui correspondent exactement à votre requête, éliminant ainsi les faux positifs. Cette précision est inestimable dans les cas de figure suivants :\n\n\n* Vous recherchez des messages d'erreur spécifiques.\n\n* Vous recherchez des signatures de fonctions précises.\n\n* Vous recherchez des instances de noms de variables spécifiques.\n\n\n**2. Un mode de recherche par expression régulière**\n\n\nPour les recherches complexes, ce mode vous permet de créer des motifs de recherche sophistiqués :\n\n\n* Trouvez des fonctions selon des motifs de nommage spécifiques.\n\n* Déterminez l’emplacement des variables qui correspondent à certains critères précis.\n\n* Identifiez les failles de sécurité potentielles à l'aide de la correspondance de motifs.\n\n\n**3. Des correspondances sur plusieurs lignes**\n\n\n![Recherche exacte de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\n\nEn plus de la ligne contenant le code recherché, vous avez accès au contexte environnant qui est indispensable pour bien comprendre le code. Vous n'avez donc plus besoin d'accéder aux fichiers dans le seul but d'obtenir un contexte plus clair, ce qui accélère considérablement votre workflow.\n\n\n## Des fonctionnalités aux workflows : cas d'utilisation et impact associé \n\n\nExaminons maintenant comment ces nouvelles capacités se traduisent dans le quotidien des équipes de développement  :\n\n\n### Débogage en quelques secondes\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez copier un message d'erreur, lancer une recherche, parcourir une longue liste de correspondances partielles dans les commentaires, la documentation et les fragments de code, cliquer sur plusieurs fichiers... avant de trouver enfin la ligne de code que vous recherchiez.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n1. Vous copiez le message d'erreur exact. \n\n2. Vous le collez dans la fonctionnalité de recherche exacte de code en activant le mode de recherche par correspondance exacte.\n\n3. Vous trouvez instantanément l'emplacement précis où l'erreur est présente, avec le contexte environnant nécessaire à sa compréhension.\n\n\n**Impact :** vous réduisez ainsi le temps de débogage de plusieurs minutes à quelques secondes, sans frustration ni faux positifs.\n\n\n### Exploration rapide de codes sources inconnus\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez parcourir les répertoires, deviner l'emplacement probable des fichiers, ouvrir des dizaines de fichiers et élaborer peu à peu une compréhension globale du code source.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n* Vous recherchez directement les méthodes ou classes principales avec le mode de recherche par correspondance exacte.\n\n* Vous examinez plusieurs correspondances de lignes pour comprendre les détails de leur mise en œuvre.\n\n* Vous utilisez le mode de recherche par expression régulière pour identifier des motifs similaires dans l'ensemble du code source.\n\n\n**Impact :** vous bénéficiez d'une vision claire de l'architecture du code en quelques minutes plutôt qu'en quelques heures, ce qui accélère considérablement l'intégration de nouveaux membres au sein de l'équipe ainsi que la collaboration transversale.\n\n\n### Refactorisation sécurisée\n\n\nVoici un exemple de workflow tel qu'il pouvait être envisagé avant que la recherche exacte de code ne soit disponible : vous deviez localiser toutes les occurrences d'une méthode, mais certaines passaient inaperçues, et vous introduisiez des bogues en raison d'une refactorisation incomplète.\n\n\nAvec la recherche exacte de code, le processus est le suivant : \n\n\n* Vous utilisez le mode de recherche par correspondance exacte pour identifier toutes les occurrences de méthodes ou de variables.\n\n* Vous examinez le contexte pour comprendre les motifs d'utilisation.\n\n* Vous planifiez votre refactorisation avec des informations complètes sur son impact.\n\n  **Impact :** vous éliminez les bogues liés aux « occurrences manquées » qui entravent souvent les efforts de refactorisation, vous améliorez la qualité du code et vous réduisez les ajustements nécessaires.\n\n### Audit de sécurité optimisé\n\n\nLes équipes de sécurité peuvent :\n\n\n* Créer des motifs regex ciblant les portions de code présentant des vulnérabilités connues\n\n* Effectuer une recherche dans tous les dépôts d'un espace de nommage\n\n* Identifier rapidement les failles de sécurité potentielles avec un contexte facilitant l'évaluation des risques\n\n\n**Impact :** vous transformez vos audits de sécurité, souvent manuels et sujets aux erreurs, en revues systématiques et exhaustives.\n\n\n### Informations recoupées entre plusieurs dépôts\n\n\nVos équipes peuvent effectuer une recherche dans l'ensemble de votre espace de nommage ou de votre instance pour :\n\n\n* Identifier des implémentations similaires dans différents projets\n\n* Identifier des opportunités de création de bibliothèques partagées ou de standardisation du code\n\n\n**Impact :** vous éliminez les silos entre les projets et identifiez les opportunités de réutilisation et de standardisation du code.\n\n\n## Zoekt : rapidité et précision au service du code\n\n\nAvant de détailler nos réalisations à grande échelle, explorons ce qui distingue Zoekt des moteurs de recherche traditionnels, et pourquoi il peut trouver des correspondances exactes aussi rapidement.\n\n\n### Trigrammes positionnels : le secret d'une correspondance exacte ultra-rapide\n\n\nLa rapidité de Zoekt provient de son utilisation de **trigrammes positionnels**, une technique qui indexe chaque séquence de trois caractères en conservant leur position exacte dans les fichiers. Cette approche résout l'un des plus grands défis que les équipes de développement rencontrent avec la recherche de code basée sur Elasticsearch : les faux positifs.\n\n\nVoici le principe :\n\n\nLes **moteurs de recherche plein texte traditionnels** comme Elasticsearch segmentent le code en mots isolés et perdent ainsi les informations de position. Par exemple, lorsque vous recherchez `getUserId()`, ils peuvent renvoyer des résultats contenant les fragments **user**, **get** et **Id** dispersés dans un même fichier, ce qui génère des faux positifs, source de frustration pour les utilisateurs de GitLab.\n\n\nLes **trigrammes positionnels de Zoekt**, quant à eux, conservent les séquences de caractères exactes ainsi que leurs positions dans le code. Ainsi, lorsque vous recherchez `getUserId()`, Zoekt cible précisément les trigrammes exacts, comme **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(\", \"d()**, dans cette séquence précise et à ces positions exactes. Cette approche garantit que seules les correspondances exactes sont renvoyées.\n\n\nAinsi, des recherches qui renvoyaient auparavant des centaines de faux positifs ne renvoient désormais plus que les correspondances exactes souhaitées. Cette fonctionnalité était [l'une des plus demandées](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) pour une bonne raison : les équipes de développement perdaient beaucoup trop de temps à passer au crible les faux positifs.\n\n\n### Performances des expressions régulières à grande échelle\n\n\nZoekt excelle dans la recherche de correspondances exactes, mais est également optimisé pour les recherches d'expressions régulières. Grâce à des algorithmes sophistiqués, il convertit les motifs regex en requêtes trigrammes efficaces lorsque cela est possible, garantissant ainsi une rapidité constante, même pour les recherches de motifs complexes portant sur plusieurs téraoctets de code.\n\n\n## Une fonctionnalité adaptée aux entreprises\n\n\nLa recherche exacte de code est puissante et conçue pour gérer de très grands volumes de code tout en offrant des temps de réponse remarquables. Il ne s'agit pas du simple ajout d'une nouvelle fonctionnalité à l'interface utilisateur, mais d'une architecture backend entièrement repensée.\n\n\n### Gestion de plusieurs téraoctets de code en toute simplicité\n\n\nRien que sur GitLab.com, notre infrastructure de recherche exacte de code indexe et interroge plus de **48 To** de données de code, tout en offrant des temps de réponse ultra-rapides. Cette volumétrie couvre des millions de dépôts répartis dans des milliers d'espaces de nommage, tous consultables en seulement quelques millisecondes, soit plus de code que l'ensemble des projets du noyau Linux, d'Android et de Chromium combinés. Et pourtant, la recherche exacte de code peut trouver une ligne spécifique dans l'ensemble du code source en quelques millisecondes seulement.\n\n\n### Architecture de nœuds à enregistrement automatique\n\n\nParmi nos améliorations techniques, voici quelques innovations clés : \n\n\n* **Enregistrement automatique des nœuds :** les nœuds Zoekt s'enregistrent automatiquement auprès de GitLab.\n\n* **Attribution dynamique des partitions :** le système attribue automatiquement les espaces de nommage entre les nœuds.\n\n* **Surveillance de l'état :** les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne.\n\n\nCette architecture à configuration automatique simplifie considérablement la montée en charge. Lorsque la capacité doit être augmentée, les administrateurs peuvent tout simplement ajouter de nouveaux nœuds, sans aucune reconfiguration complexe.\n\n\n### Système distribué avec répartition de charge intelligente\n\n\nEn arrière-plan, la recherche exacte de code repose sur un système distribué comprenant les composants clés suivants :\n\n\n* **Nœuds de recherche spécialisés :** serveurs dédiés pour gérer l'indexation et la recherche\n\n* **Partitionnement intelligent :** le code est réparti entre les nœuds en fonction des espaces de nommage\n\n* **Équilibrage automatique de la charge :** le système répartit intelligemment le travail en fonction des capacités disponibles\n\n* **Haute disponibilité :** plusieurs réplicas assurent la continuité du service même en cas de défaillance d'un nœud\n\n\n*Remarque : la haute disponibilité fait partie intégrante de l'architecture, mais n'est pas encore entièrement déployée. Consultez le [ticket 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) pour vous tenir au courant des futures mises à jour.*\n\n\n### Intégration sans accroc de la sécurité\n\n\nLa recherche exacte de code s'intègre automatiquement au système d'autorisation de GitLab :\n\n\n* Les résultats de recherche sont filtrés en fonction des droits d'accès de chaque utilisateur.\n\n* Seul le code des projets auxquels l'utilisateur a accès est affiché.\n\n* La sécurité est intégrée à l'architecture de base, et non ajoutée ultérieurement.\n\n\n### Performances optimisées\n\n\n* **Indexation performante :** les dépôts volumineux sont indexés en quelques dizaines de secondes.\n\n* **Exécution rapide des requêtes :** la plupart des recherches renvoient des résultats en moins d'une seconde.\n\n* **Résultats en streaming :** la nouvelle recherche fédérée basée sur gRPC diffuse les résultats au fur et à mesure de leur découverte.\n\n* **Arrêt anticipé :** dès qu'un nombre suffisant de résultats a été collecté, le système interrompt la recherche.\n\n\n## De la bibliothèque au système distribué : notre réponse aux défis d'ingénierie\n\n\nBien que Zoekt soit très performant pour indexer et rechercher du code localement, son architecture de base était conçue à l'origine comme une bibliothèque minimale, destinée à la gestion des fichiers d'index `.zoekt`, et non comme une base de données distribuée ou un service capable de fonctionner à l'échelle d'une entreprise. \n\n\nVoici les principaux défis techniques que nous avons dû surmonter pour l'adapter pleinement à l'écosystème GitLab.\n\n\n### Défi 1 : création d'une couche d'orchestration\n\n\n**Le problème :** Zoekt a été conçu pour fonctionner avec des fichiers d'index locaux, et non pour être distribué sur plusieurs nœuds desservant de nombreux utilisateurs simultanés.\n\n\n**Notre solution :** nous avons développé une couche d'orchestration complète qui :\n\n\n* crée et gère des modèles de base de données pour suivre les nœuds, les index, les dépôts et les tâches.\n\n* met en œuvre une architecture de nœuds à enregistrement automatique (inspirée du fonctionnement de GitLab Runner).\n\n* gère l'attribution automatique des partitions et l'équilibrage de la charge entre les nœuds.\n\n* fournit une communication bidirectionnelle de l'API entre les nœuds GitLab Rails et Zoekt.\n\n\n### Défi 2 : mise à l'échelle du stockage et de l'indexation\n\n\n**Le problème :** comment gérer efficacement des téraoctets de données d'indexation répartis sur plusieurs nœuds tout en garantissant des mises à jour rapides ?\n\n\n**Notre solution :** nous avons déployé les fonctionnalités suivantes  :\n\n\n* Partitionnement intelligent : les espaces de nommage sont répartis entre les nœuds en tenant compte de leur capacité et de leur charge.\n\n* Réplication indépendante : chaque nœud est indexé indépendamment à partir de [Gitaly](https://gitlab.com/gitlab-org/gitaly) (notre service de stockage Git), évitant ainsi toute synchronisation complexe.\n\n* Gestion avancée des filigranes : un système sophistiqué d'allocation de stockage empêche les nœuds de manquer d'espace.\n\n* Architecture binaire unifiée : un seul binaire `gitlab-zoekt` peut fonctionner à la fois en mode indexeur et en mode serveur web.\n\n\n### Défi 3 : intégration des autorisations\n\n\n**Le problème :** Zoekt n'avait aucune notion du système d'autorisation complexe de GitLab. Les utilisateurs ne doivent voir que les résultats des projets auxquels ils ont accès.\n\n\n**Notre solution :** nous avons intégré un filtrage des autorisations natif directement dans le flux de recherche :\n\n\n* Les requêtes de recherche incluent le contexte des autorisations de l'utilisateur.\n\n* Les résultats sont filtrés pour n’inclure que les éléments auxquels l'utilisateur peut accéder, même dans le cas où les autorisations évoluent avant la fin de l'indexation.\n\n\n### Défi 4 : simplification opérationnelle\n\n\n**Le problème :** gérer un système de recherche distribué ne devrait pas nécessiter une équipe dédiée.\n\n\n**Notre solution :**\n\n\n* Mise à l'échelle automatique : l'ajout de capacité est aussi simple que le déploiement de nœuds supplémentaires. Ces derniers s'enregistrent automatiquement et gèrent immédiatement la charge de travail.\n\n* Auto-réparation : les nœuds qui ne s'enregistrent pas sont automatiquement signalés comme hors ligne, avec redistribution automatique de leurs tâches.\n\n* Partitionnement sans configuration : le système détermine automatiquement les affectations de partitions optimales.\n\n\n## Déploiement progressif : réduire les risques à grande échelle\n\n\nLe déploiement d'un tout nouveau backend de recherche auprès de millions d'utilisateurs a nécessité une planification minutieuse. Voici comment nous avons limité l'impact sur les clients tout en garantissant la fiabilité :\n\n\n### Phase 1 : tests contrôlés (groupe gitlab-org)\n\n\nNous avons commencé par activer la recherche exacte de code uniquement pour le groupe `gitlab-org`, constitué de nos propres dépôts internes. \n\n\nCette étape nous a permis de :\n\n\n* Tester le système avec des charges de travail réelles en production\n\n* Identifier et corriger les goulots d'étranglement liés aux performances\n\n* Rationaliser le processus de déploiement\n\n* Tirer des enseignements concrets sur les workflows grâce aux retours d'utilisateurs\n\n\n### Phase 2 : validation et optimisation des performances\n\n\nAvant d'étendre la fonctionnalité, nous nous sommes assurés que le système pouvait gérer la charge à l'échelle de GitLab.com. Pour cela, nous avons dû :\n\n\n* Mettre en œuvre une surveillance et une gestion des alertes complètes\n\n* Valider la gestion du stockage basée sur la croissance réelle des données en production\n\n\n### Phase 3 : expansion progressive auprès des clients\n\n\nNous avons progressivement ouvert l'accès à la recherche exacte de code aux clients désireux de l'essayer, afin de :\n\n\n* Collecter leurs retours sur les performances et l'expérience utilisateur\n\n* Affiner l'interface utilisateur de recherche en fonction des workflows réels des utilisateurs\n\n* Optimiser les performances d'indexation (par exemple, les grands dépôts comme `gitlab-org/gitlab` sont désormais indexés en environ 10 secondes)\n\n* Ajuster l'architecture en fonction des leçons tirées des premiers essais\n\n* Augmenter massivement le débit d'indexation et améliorer le cycle de vie des transitions d'état\n\n\n### Phase 4 : déploiement à grande échelle\n\n\nAujourd'hui, plus de 99 % des groupes disposant des licences Premium et Ultimate sur GitLab.com ont accès à la recherche exacte de code. \n\n\nLes utilisateurs peuvent :\n\n\n* Basculer facilement entre les modes de recherche par expression régulière et par correspondance exacte\n\n* Tirer parti des avantages sans modifier la configuration\n\n* Revenir à l'ancienne méthode de recherche si nécessaire (bien que peu d'entre eux optent pour cette possibilité)\n\n\nCe déploiement progressif a permis d'éviter toute interruption de service, baisse de performances ou perte de fonctionnalités pendant la transition. Les premiers retours sont très positifs, car les utilisateurs constatent que leurs résultats de recherche sont plus pertinents et qu'ils les obtiennent beaucoup plus rapidement.\n\n\n> Vous souhaitez en savoir plus sur l'architecture et la mise en œuvre de la recherche exacte de code ? Consultez notre [document de conception](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) complet, qui offre une description technique détaillée de ce système de recherche distribué.\n\n\n## Premiers pas : comment lancer une recherche exacte de code ? \n\n\nLa prise en main de la recherche exacte de code est simple, car cette fonctionnalité est déjà activée par défaut pour les groupes Premium et Ultimate sur GitLab.com (accessibles aujourd'hui à plus de 99 % des groupes éligibles).\n\n\n### Guide de démarrage rapide\n\n\n1. Accédez à la recherche avancée depuis votre projet ou groupe GitLab.\n\n2. Saisissez votre terme de recherche dans l'onglet Code.\n\n3. Basculez entre les modes de recherche par correspondance exacte et par expression régulière.\n\n4. Utilisez des filtres pour affiner votre recherche.\n\n\n### Syntaxe de recherche de base\n\n\nQue vous utilisiez le mode de recherche par correspondance exacte ou par expression régulière, vous pouvez affiner votre recherche avec divers modificateurs :\n\n\n| Exemple de requête | Fonction                                                               |\n\n| ------------------ | ---------------------------------------------------------------------- |\n\n| `file:js`          | Recherche uniquement dans les fichiers dont le nom contient « js »     |\n\n| `foo -bar`         | Recherche « foo », mais exclut les résultats contenant « bar »         |\n\n| `lang:ruby`        | Recherche uniquement dans les fichiers Ruby                            |\n\n| `sym:process`      | Recherche « process » dans les symboles (méthodes, classes, variables) |\n\n\n> **Conseil :** pour optimiser votre recherche, commencez par une requête précise, puis élargissez-la si besoin. L'utilisation des filtres `file:` et `lang:` augmente considérablement la pertinence des résultats.\n\n\n### Techniques de recherche avancées\n\n\nCombinez plusieurs filtres pour gagner en précision :\n\n\n```\n\nis_expected file:rb -file:spec\n\n```\n\n\nCette requête recherche « is_expected » dans les fichiers Ruby dont le nom ne contient pas « spec ».\n\n\nTirez parti des expressions régulières pour obtenir des motifs puissants :\n\n\n```\n\ntoken.*=.*[\\\"']\n\n```\n\n\n[Consultez cette recherche effectuée dans le dépôt GitLab Zoekt.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\n\nElle permet de trouver des mots de passe codés en dur qui, s'ils ne sont pas détectés, peuvent constituer un risque de sécurité.\n\n\nPour approfondir la syntaxe, consultez la [documentation dédiée à la recherche exacte de code](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n\n## Disponibilité et déploiement\n\n\n### Disponibilité actuelle\n\n\nLa recherche exacte de code est actuellement disponible en version bêta pour les utilisateurs de GitLab.com disposant de licences Premium et Ultimate :\n\n\n* Elle est accessible à plus de 99 % des groupes éligibles sous licence.\n\n* La recherche dans l'interface utilisateur utilise automatiquement Zoekt lorsqu'il est disponible ; la recherche exacte de code via l'API de recherche est activée par le biais d'un feature flag.\n\n\n### Options de déploiement pour les instances Self-Managed\n\n\nPour les instances Self-Managed, nous proposons plusieurs méthodes de déploiement :\n\n\n* Kubernetes/Helm : notre méthode la mieux prise en charge, basée sur notre [Helm Chart `gitlab-zoekt`](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt).\n\n* Autres méthodes : nous travaillons actuellement sur la simplification du déploiement via Omnibus et d'autres options d'installation.\n\n\nLes exigences en configuration système varient selon la taille de votre code source, mais l'architecture est conçue pour s'adapter horizontalement et/ou verticalement à mesure que vos besoins évoluent.\n\n\n## Prochaines étapes\n\n\nBien que la recherche exacte de code soit déjà performante, nous l'améliorons continuellement avec :\n\n\n* **Des optimisations à grande échelle** pour gérer des instances comptant des centaines de milliers de dépôts\n\n* **Des options de déploiement renforcées pour les instances Self-Managed**, y compris la prise en charge simplifiée d'Omnibus\n\n* **Une prise en charge complète de la haute disponibilité** avec basculement automatique et équilibrage de la charge\n\n\nRestez à l'écoute pour suivre les prochaines mises à jour lorsque nous passerons de la version bêta à la disponibilité générale.\n\n\n## Transformez votre façon de rechercher des lignes de code\n\n\nAvec la recherche exacte de code, GitLab repense en profondeur la manière dont le code est exploré, en fournissant des correspondances exactes, une prise en charge avancée des expressions régulières et des résultats contextuels. \n\n\nCette nouvelle fonctionnalité résout les aspects les plus frustrants de la recherche de code :\n\n\n* Ne perdez plus votre temps avec des résultats non pertinents.\n\n* Ne ratez plus aucune correspondance importante.\n\n* N'ouvrez plus plusieurs fichiers juste pour comprendre le contexte de base.\n\n* Ne subissez plus de problèmes de performances à mesure que la taille de vos dépôts de code augmente.\n\n\nL'impact s'étend même bien au-delà, à la productivité globale des équipes :\n\n\n* **Vos équipes collaborent plus efficacement** avec un référencement clair du code.\n\n* **Le partage des connaissances s'accélère** avec la détection facile des motifs.\n\n* **L'intégration des nouveaux membres d'équipe s'accélère** avec une compréhension rapide du code source.\n\n* **La sécurité est renforcée** avec un audit efficace des motifs.\n\n* **Une réduction de la dette technique** devient réellement envisageable.\n\n\nLa recherche exacte de code est plus qu'une simple fonctionnalité : elle vous permet de mieux comprendre et de gérer le code. Alors, arrêtez de chercher et commencez à trouver ! \n\n\n**Nous serions ravis de connaître votre avis.** Partagez vos expériences, vos questions ou vos commentaires sur la recherche exacte de code dans notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Vos retours nous aident à hiérarchiser nos priorités d'améliorations et à enrichir nos futures fonctionnalités.\n\n\n#### Vous souhaitez tirer parti d'une recherche de code plus intelligente ? Pour en savoir plus, consultez notre [documentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) et essayez dès aujourd'hui notre nouvelle fonctionnalité en effectuant une recherche dans vos espaces de nommage ou vos projets disposant d'une licence Premium ou Ultimate. Vous n'utilisez pas encore GitLab ? Inscrivez-vous pour un [essai gratuit de GitLab Ultimate enrichi des capacités de GitLab Duo](https://about.gitlab.com/fr-fr/free-trial/?hosted=saas) !\n","product",[9],{"featured":6,"template":688,"slug":708},"exact-code-search-find-code-faster-across-repositories","content:fr-fr:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","fr-fr/blog/exact-code-search-find-code-faster-across-repositories.yml","fr-fr/blog/exact-code-search-find-code-faster-across-repositories",{"_path":714,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":715,"content":721,"config":727,"_id":729,"_type":14,"title":730,"_source":16,"_file":731,"_stem":732,"_extension":19},"/fr-fr/blog/git-bash",{"title":716,"description":717,"ogTitle":716,"ogDescription":717,"noIndex":6,"ogImage":718,"ogUrl":719,"ogSiteName":675,"ogType":676,"canonicalUrls":719,"schema":720},"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":716,"description":717,"authors":722,"heroImage":718,"date":724,"body":725,"category":10,"tags":726},[723],"GitLab France Team","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",[684,9],{"slug":728,"featured":6,"template":688},"git-bash","content:fr-fr:blog:git-bash.yml","Git Bash","fr-fr/blog/git-bash.yml","fr-fr/blog/git-bash",{"_path":734,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":735,"content":741,"config":749,"_id":751,"_type":14,"title":752,"_source":16,"_file":753,"_stem":754,"_extension":19},"/fr-fr/blog/git-pull-vs-git-fetch-whats-the-difference",{"title":736,"description":737,"ogTitle":736,"ogDescription":737,"noIndex":6,"ogImage":738,"ogUrl":739,"ogSiteName":675,"ogType":676,"canonicalUrls":739,"schema":740},"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":742,"description":737,"authors":743,"heroImage":738,"date":745,"body":746,"category":10,"tags":747,"updatedDate":748},"Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?",[744],"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.",[684,9],"2024-10-15",{"slug":750,"featured":6,"template":688},"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":756,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":757,"content":763,"config":772,"_id":774,"_type":14,"title":775,"_source":16,"_file":776,"_stem":777,"_extension":19},"/fr-fr/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":758,"description":759,"ogTitle":758,"ogDescription":759,"noIndex":6,"ogImage":760,"ogUrl":761,"ogSiteName":675,"ogType":676,"canonicalUrls":761,"schema":762},"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":758,"description":759,"authors":764,"heroImage":760,"date":766,"body":767,"category":10,"tags":768,"updatedDate":771},[765],"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",[109,9,769,537,684,770],"kubernetes","tutorial","2025-05-09",{"slug":773,"featured":6,"template":688},"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":779,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":780,"content":786,"config":797,"_id":799,"_type":14,"title":800,"_source":16,"_file":801,"_stem":802,"_extension":19},"/fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"ogTitle":781,"schema":782,"ogImage":783,"ogDescription":784,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":785,"title":781,"canonicalUrls":785,"description":784},"Dépôts GitLab : forte diminution des temps de sauvegarde","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Dépôts GitLab : forte diminution des temps de sauvegarde\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karthik Nayak\"},{\"@type\":\"Person\",\"name\":\"Manuel Kraft\"}],\n        \"datePublished\": \"2025-06-05\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","L'optimisation d'une fonction Git vieille de 15 ans a permis d'augmenter la productivité, de renforcer les stratégies de sauvegarde et de réduire les risques.","https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"heroImage":783,"body":787,"authors":788,"updatedDate":791,"date":792,"title":793,"tags":794,"description":784,"category":796},"Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de\nreprise après un sinistre important. Cependant, à mesure que les dépôts\ngrossissent, garantir des sauvegardes fiables devient de plus en plus\ndifficile. Notre propre [dépôt Rails](https://gitlab.com/gitlab-org/gitlab)\nmettait 48 heures à être sauvegardé, ce qui nous obligeait à faire un choix\nimpossible entre la fréquence des sauvegardes et les performances du\nsystème. Nous avons donc décidé de trouver une solution à ce problème pour\nnos clients et pour nos propres équipes internes.\n\n\nAprès investigation, nous avons pu déterminer la cause du problème, qui remontait à une fonction Git vieille de 15 ans dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme et **avons ainsi réduit les temps de sauvegarde de manière exponentielle**. \n\n\nRésultat : des coûts réduits, des risques diminués, et surtout, des stratégies de sauvegarde désormais adaptées à la croissance de votre code source.\n\n\nCe problème d'évolutivité de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") affectait tout utilisateur disposant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.\n\n\n## Sauvegarde à grande échelle : enjeux et solutions\n\n\nÀ mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :\n\n\n* **Sauvegardes trop longues** : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.\n\n* **Utilisation intensive des ressources** : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter d'autres opérations critiques.\n\n* **Fenêtres de sauvegarde** : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes qui fonctionnent 24 h/24 et 7 j/7.\n\n* **Risque accru d'échec** : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, et obligent souvent les équipes à recommencer tout le processus depuis le début.\n\n* **Conditions de concurrence** : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus et peut conduire à une sauvegarde invalide ou à des interruptions liées à des objets devenus indisponibles.\n\n\nCes défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme l'utilisation d'outils externes ou la réduction de la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises.\n\n\nDécouvrez maintenant comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.\n\n\n## Le défi technique\n\n\nLa fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande [`git bundle create`](https://git-scm.com/docs/git-bundle/fr), qui génère un aperçu complet du dépôt avec tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration pour recréer le dépôt dans son état exact.\n\n\nCependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références et entraînait un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.\n\n\n### Analyse des causes profondes\n\n\nPour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.\n\n\n![Flame graph montrant la commande pendant son exécution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\n\nCe graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.\n\n\nLe flame graph de `git bundle create` exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction `object_array_remove_duplicates()`, introduite dans Git par le biais du [commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).\n\n\nPour comprendre ce changement, il est important de savoir que la commande `git bundle create` permet de préciser les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag `--all` compacte toutes les références.\n\n\nCe commit corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que `git bundle create main.bundle main main`, et créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois, ce qui provoquait une erreur. \n\n\nLe code ajouté pour éviter ces duplications utilise des boucles `for` imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) est un goulot d'étranglement majeur en termes de performance dans les dépôts car il contient un grand nombre de références et prolonge considérablement le temps de traitement des données.\n\n\n### La solution : d'O(N²) à un mappage efficace\n\n\nPour résoudre ce problème, nous avons proposé une correction en amont dans Git pour remplacer les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.\n\n\nCe changement améliore considérablement les performances de la commande `git bundle create` et garantit une bien meilleure évolutivité dans les dépôts avec un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.\n\n\n```shell\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\n\nLe correctif a été accepté et [fusionné](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d) dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement sans attendre la prochaine version officielle de Git.\n\n\n## Résultat : des temps de sauvegarde radicalement réduits\n\n\nLes gains de performance qui découlent de cette amélioration sont considérables :\n\n\n* **De 48 heures à 41 minutes** : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.\n\n* **Performances constantes** : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.\n\n* **Efficacité des ressources** : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.\n\n* **Applicabilité étendue** : si le processus de sauvegarde est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets avec un grand nombre de références en profitent également.\n\n\n## Avantages pour nos clients GitLab\n\n\nPour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :\n\n\n* **Transformation des stratégies de sauvegarde**   \n\n  * Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.   \n  * Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans processus longs ni dédiés.  \n* **Continuité des activités améliorée**  \n\n  * Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits, tout comme le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.\n* **Réduction de la charge opérationnelle**   \n\n  * La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.  \n  * Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.\n* **Pérennisation de l'infrastructure**   \n\n  * La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.   \n  * À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.\n\nLes entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un compromis difficile est devenu une pratique opérationnelle simple.\n\n\nÀ partir de la version [GitLab 18.0](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/), tous les clients GitLab, quelle que soit leur version de licence, profitent désormais pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs [sauvegardes](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/), sans aucune autre modification de la configuration.\n\n\n## Et après ?\n\n\nCette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente une étape majeure, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.\n\n\nNous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git afin de profiter non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.\n\n\n> Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Consultez le [replay de notre événement virtuel de lancement de GitLab 18](https://about.gitlab.com/fr-fr/eighteen/) et découvrez les autres améliorations fondamentales que nous proposons.\n",[789,790],"Karthik Nayak","Manuel Kraft","2025-07-09","2025-06-05","Dépôts GitLab : diminution du temps de sauvegarde de 48 h à 41 min ",[684,9,795],"performance","engineering",{"slug":798,"featured":91,"template":688},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","content:fr-fr:blog:how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","How We Decreased Gitlab Repo Backup Times From 48 Hours To 41 Minutes","fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","fr-fr/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"_path":804,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":805,"content":809,"config":817,"_id":819,"_type":14,"title":820,"_source":16,"_file":821,"_stem":822,"_extension":19},"/fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":806,"description":807,"ogDescription":807,"ogTitle":806,"ogImage":808},"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":807,"title":810,"category":10,"tags":811,"heroImage":808,"date":812,"body":813,"authors":814},"Comment nous utilisons GitLab pour développer les communautés open source",[9,270,705],"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",[815,816],"Lee Tickett","Daniel Murphy",{"featured":6,"template":688,"slug":818},"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":824,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":825,"content":831,"config":839,"_id":841,"_type":14,"title":842,"_source":16,"_file":843,"_stem":844,"_extension":19},"/fr-fr/blog/introduction-guide-to-linux-servers",{"ogTitle":826,"schema":827,"ogImage":828,"ogDescription":829,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":830,"title":826,"canonicalUrls":830,"description":829},"Serveur Linux : définition, avantages, usage et installation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab France Team\"}],\n        \"datePublished\": \"2024-12-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663065/Blog/Hero%20Images/serveur-linux.jpg","Le serveur Linux est couramment utilisé dans les entreprises. Découvrez ses fonctionnalités, ses utilisations et ses avantages.","https://about.gitlab.com/blog/introduction-guide-to-linux-servers",{"title":832,"description":829,"authors":833,"heroImage":828,"date":834,"body":835,"category":836,"tags":837},"Guide d'introduction aux serveurs Linux : définition, avantages, usage et installation",[723],"2024-12-04","Lancé en 1991 comme alternative à Minix, il adopte la licence GNU GPL en février 1992. Linux est aujourd’hui le système d'exploitation le plus utilisé pour la gestion des serveurs d'entreprise. Les serveurs Linux répondent aux besoins d'entreprises de toutes tailles, leur fournissant une plateforme performante et économique pour piloter de nombreuses applications informatiques. Qu'est-ce qu'un serveur Linux ? Quels en sont les avantages et les usages ? Comment installer un serveur Linux ? Voici l'essentiel à savoir pour lancer votre projet sous Linux.\n\n## Qu'est-ce qu'un serveur Linux ?\n\nUn serveur Linux est un serveur informatique opéré avec le système d'exploitation Linux. Linux fut créé en 1991 par le Finlandais Linus Torvalds, sous forme de noyau de système d'exploitation de type Unix. Trois décennies plus tard, il se conçoit aujourd'hui comme une suite cohérente de logiciels formant un __système d'exploitation entièrement opérationnel__, appelée une distribution Linux.  \n\nLes distributions GNU/Linux s'utilisent principalement pour gérer des fonctions informatiques côté serveur (backend). Nous pouvons citer l'hébergement Web, la gestion de réseau et le stockage de données. Linux est open source, ainsi les équipes opérationnelles peuvent télécharger gratuitement une distribution Linux et l'adapter à leurs besoins. Le système d'exploitation Linux est disponible sous différentes distributions GNU/Linux, telles que Debian, Ubuntu ou openSUSE offrant aux équipes de développement un surcroît de flexibilité et de personnalisation. \n\n## Quels sont les avantages d’un serveur Linux ?\n\nLe succès des serveurs Linux s'explique en grande partie par leur accessibilité et leur flexibilité. Mais le système d'exploitation Linux est aussi reconnu pour sa stabilité et sa sécurité, des critères cruciaux pour les infrastructures de serveurs d'entreprise. Certifié par la Free Software Fondation, Linux est un logiciel libre dont le code source est ouvert, ce qui facilite la correction des bogues et des failles de sécurité. \n\nSon __écosystème open source__ cimente aussi la popularité de Linux auprès des développeurs et des ingénieurs informatiques. Une communauté très active promeut GNU/Linux et favorise sa sécurisation et son développement. En résumé, gérer un serveur sous Linux comporte de nombreux avantages : \n\n- __Réduction des coûts.__ Vous pouvez télécharger, utiliser et modifier Linux sans frais de licence, ce qui permet de réaliser d'importantes économies sur les dépenses informatiques. De nombreuses applications compatibles avec Linux sont aussi disponibles gratuitement.\n- __Sécurité.__ Linux offre un niveau de protection avancé, avec un logiciel libre, des mises à jour régulières, des correctifs de sécurité rapidement publiés, et un soutien de la communauté des développeurs et développeuses.\n- __Scalabilité.__ Les serveurs Linux peuvent facilement évoluer en fonction des charges de travail et du nombre d'utilisateurs. Cette souplesse est appréciée par les entreprises en croissance, et idéale pour les [projets DevOps des PME](https://about.gitlab.com/fr-fr/small-business/ \"Projets DevOps des PME\").\n- __Flexibilité.__ Linux offre un degré de personnalisation poussé, les équipes de développement pouvant adapter le logiciel aux spécificités de leur architecture et de leurs applications. Ils disposent aussi d'un large choix parmi les nombreuses distributions GNU/Linux disponibles.\n\n## Comment utiliser un serveur Linux ?\n\nPar leur versatilité, les serveurs Linux se révèlent précieux pour un grand nombre d'usages informatiques. Ils excellent dans les applications d'entreprise les plus sensibles et les plus complexes. Voici quelques exemples d'utilisations fréquentes d'un serveur sous Linux : \n\n- __Hébergement Web__, qui nécessite de gérer de fortes charges de trafic. Des outils très performants dans ce domaine comme Apache et Nginx fonctionnent de façon optimale sous Linux.\n- __Administration système et réseau.__ Avec des commandes en ligne puissantes, des fonctionnalités avancées de routage et de contrôle du trafic intégrées dans le noyau, une maintenance simple et un fonctionnement stable et sobre en ressources, Linux est le système d'exploitation de choix des administrateurs réseau. \n- __Gestion de bases de données.__ Linux procure une robustesse et une scalabilité incomparables pour utiliser les solutions de gestion des données les plus performantes, comme PostgreSQL, MongoDB ou MariaDB. \n- __Cloud et virtualisation.__ Les serveurs Linux permettent de maximiser les performances des logiciels et des serveurs virtuels. Ils sont naturellement plébiscités pour les [applications cloud-native des entreprises](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Applications cloud-natives des entreprises\").  \n\nLe champ d'utilisation des serveurs sous Linux ne se limite pas à ces exemples. Analyse de données, jeux en ligne, transferts de fichier, business intelligence, messagerie… Les équipes choisissent souvent GNU/Linux pour des projets informatiques qui nécessitent un haut degré de contrôle et de sécurisation, et font appel à des applications avancées et exigeantes en ressources.\n\n### Conseils pour administrer un serveur Linux\n\nSi vous souhaitez tirer pleinement parti des capacités offertes par Linux, nous vous conseillons de suivre certaines bonnes pratiques dans l'administration d'un serveur Linux en entreprise. Pour assurer un démarrage réussi, il est essentiel de __former votre équipe IT__ aux commandes en ligne, aux configurations de sécurité et aux techniques de dépannage. Utilisez des __outils de surveillance__ compatibles avec Linux, tels que Prometheus, Nagios ou Zabbix, pour maintenir la fiabilité de votre infrastructure à long terme.\n\nLa __planification des sauvegardes__ est un autre point crucial pour assurer la viabilité de votre projet. Vous pouvez utiliser la règle du 3-2-1. Sauvegardez trois copies des données, stockez deux copies sur des supports différents, dont une sera placée hors site. Enfin, une bonne gestion de serveur Linux requiert une attention particulière aux __mesures de sécurité__. Nous recommandons la mise en place de clés SSH pour les mots de passe, de logiciels pare-feu et de détection des intrusions comme Fail2ban, et d'une authentification à deux facteurs.\n\n## Comment installer un serveur Linux ?\n\nProlongeons ce guide d'introduction sur une note plus pratique. Voici un tutoriel sur le serveur Linux qui vous accompagnera dans l'installation de ce logiciel en entreprise. Suivez les principales étapes pour installer un serveur Linux :\n\n1. Choisissez une __distribution Linux__ adaptée. Optez par exemple pour Ubuntu Server, connu pour sa facilité d'utilisation, ou Debian, réputé pour sa robustesse.\n2. Créez une __ISO bootable__ de la distribution Linux. Téléchargez-la sur le site officiel et placez-la sur une clé USB pour lancer l'installation sur le serveur.\n3. __Installez Linux__ à partir de la clé USB. Procédez à la configuration de base, à la partition du disque, à la configuration de l'utilisateur, au redémarrage et la première connexion.\n4. __Effectuez la configuration initiale__ du serveur Linux : sécurisez l’accès par SSH, créez un utilisateur non-root, configurez le pare-feu et mettez à jour le système.\n5. __Configurez le réseau.__ Choisissez une IP statique ou dynamique, configurez les DNS et la redirection des ports.\n\nEnfin, pour terminer l'installation du serveur Linux, veillez à parfaire la sécurisation du serveur avec installation d'un pare-feu, d'un certificat SSL et d'outils de surveillance du réseau. Une fois ces étapes terminées, votre serveur Linux est prêt à fonctionner. \n\n## Lancez un projet avec GitLab et Linux\n\nSi Linux a toujours dominé le secteur des serveurs d'entreprise, il connaît aussi un regain de popularité du côté du grand public. Au succès relatif des distributions adaptées aux utilisateurs sur PC, telles que Linux Mint et Ubuntu, s'ajoute l'essor des systèmes d'exploitation Android et Chrome OS pour mobiles et tablettes, qui sont basés sur le noyau Linux. Investir dans des applications fonctionnant sous Linux apparaît comme une stratégie gagnante à long terme, tant le succès de ce logiciel ne se dément pas.\n\nGitLab et Linux offrent un environnement idéal pour développer vos activités de façon agile et profiter de tous nos outils de collaboration. La plateforme GitLab prend en charge de nombreux paquets Linux officiels, tels que Debian, Ubuntu, AlmaLinux et CentOS 7. Rendez-vous sur notre page d'information pour [installer GitLab avec un serveur Linux](https://about.gitlab.com/fr-fr/install/#official-linux-package \"Installer GitLab avec un serveur Linux\") et mener à bien votre projet.\n\n## Installer une distribution Linux avec GitLab\n\n- [Paquet Ubuntu](https://about.gitlab.com/fr-fr/install/#ubuntu \"Paquet Ubuntu\")\n- [Paquet Debian](https://about.gitlab.com/fr-fr/install/#debian \"Paquet Debian\")\n- [Paque AlmaLinux](https://about.gitlab.com/fr-fr/install/#almalinux \"Paque AlmaLinux\")\n- [Paquet CentOS 7](https://about.gitlab.com/fr-fr/install/#centos-7 \"Paquet CentOS 7\")\n- [Paquet OpenSUSE Leap](https://about.gitlab.com/fr-fr/install/#opensuse-leap \"Paquet OpenSUSE Leap\")\n- [Paquet Amazon Linux 2](https://about.gitlab.com/fr-fr/install/#amazonlinux-2 \"Paquet Amazon Linux 2\")\n- [Paquet Raspberry Pi](https://about.gitlab.com/fr-fr/install/#raspberry-pi-os \"Paquet Raspberry Pi\")\n","devsecops",[838,9],"DevOps",{"slug":840,"featured":6,"template":688},"introduction-guide-to-linux-servers","content:fr-fr:blog:introduction-guide-to-linux-servers.yml","Introduction Guide To Linux Servers","fr-fr/blog/introduction-guide-to-linux-servers.yml","fr-fr/blog/introduction-guide-to-linux-servers",{"_path":846,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":847,"content":853,"config":859,"_id":861,"_type":14,"title":862,"_source":16,"_file":863,"_stem":864,"_extension":19},"/fr-fr/blog/journey-through-gits-20-year-history",{"title":848,"description":849,"ogTitle":848,"ogDescription":849,"noIndex":6,"ogImage":850,"ogUrl":851,"ogSiteName":675,"ogType":676,"canonicalUrls":851,"schema":852},"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":848,"description":849,"authors":854,"heroImage":850,"date":855,"body":856,"category":10,"tags":857,"updatedDate":858},[680],"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",[9,684],"2025-04-25",{"slug":860,"featured":91,"template":688},"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":866,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":867,"content":873,"config":879,"_id":881,"_type":14,"title":882,"_source":16,"_file":883,"_stem":884,"_extension":19},"/fr-fr/blog/kubernetes-the-container-orchestration-solution",{"title":868,"description":869,"ogTitle":868,"ogDescription":869,"noIndex":6,"ogImage":870,"ogUrl":871,"ogSiteName":675,"ogType":676,"canonicalUrls":871,"schema":872},"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":868,"description":869,"authors":874,"heroImage":870,"date":876,"body":877,"category":10,"tags":878},[875],"GitLab Team","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",[769,9],{"slug":880,"featured":6,"template":688},"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":886,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":887,"content":893,"config":903,"_id":905,"_type":14,"title":906,"_source":16,"_file":907,"_stem":908,"_extension":19},"/fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"title":888,"description":889,"ogTitle":888,"ogDescription":889,"noIndex":6,"ogImage":890,"ogUrl":891,"ogSiteName":675,"ogType":676,"canonicalUrls":891,"schema":892},"Programme Co-Create : comment nous construisons GitLab avec nos clients","Découvrez comment Thales, Scania et Kitware collaborent avec les ingénieurs de GitLab pour contribuer au développement de fonctionnalités significatives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Programme Co-Create : comment nous construisons GitLab avec nos clients\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }",{"title":888,"description":889,"authors":894,"heroImage":890,"date":896,"body":897,"category":898,"tags":899,"updatedDate":902},[895],"Fatima Sarah Khalid","2025-01-30","L'année dernière, plus de 800 membres de la communauté ont apporté plus de 3 000 contributions à GitLab. Parmi ces contributeurs figurent des membres issus d'équipes travaillant pour des entreprises internationales comme Thales, Scania et Kitware qui contribuent à façonner l'avenir de GitLab grâce au [Programme Co-Create](https://about.gitlab.com/community/co-create/). Dans le cadre de ce programme de développement collaboratif mis en place par GitLab, les clients travaillent directement avec les ingénieurs de GitLab pour ajouter des fonctionnalités importantes à la plateforme.\n\nÀ travers des ateliers, des sessions de programmation en binôme et une assistance en continu, les participants au programme acquièrent une connaissance pratique de l'architecture et du code base de GitLab tout en résolvant des problèmes ou en améliorant des fonctionnalités existantes.\n\n*« Notre expérience avec le Programme Co-Create a été incroyable »*, déclare Sébastien Lejeune, Open Source Advocate chez Thales. *« Il n'a fallu que deux mois entre le moment où nous avons discuté de notre contribution avec un ingénieur de l'équipe Contributor Success de GitLab et le moment où nous l'avons intégrée à la version de GitLab. »*\n\nDans cet article, découvrez comment nos clients tirent parti du Programme Co-Create pour transformer leurs idées en code, tout en se formant et en apportant leur contribution.\n\n## Qu'est-ce que le Programme Co-Create ? \n\nAvec le [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit), les contributeurs peuvent facilement faire leurs premiers pas sur la plateforme de développement de GitLab. *« Ce que les nouveaux contributeurs doivent comprendre, c'est que rien n'est définitif avec le GDK »*, indique Hook. *« Si un contributeur effectue une modification qui ne fonctionne pas, il peut l'annuler ou tout recommencer. Le GDK permet d'expérimenter, de tester et d'apprendre sans se soucier de l'environnement. »*\n\nChaque entreprise participant au Programme Co-Create de GitLab reçoit une assistance tout au long de son parcours de contribution :\n\n- __Atelier d'intégration technique__ : session dédiée à la mise en place du GitLab Development Kit (GDK) et à la présentation de l'architecture de la plateforme GitLab.\n- __Support technique individuel__ : accès aux ingénieurs GitLab pour programmer en binôme et recevoir des conseils techniques.\n- __Explications détaillées sur l'architecture__ : sessions sur des composants spécifiques de la plateforme GitLab en lien direct avec le problème auquel l'entreprise contribue.\n- __Aide à la revue de code__ : retours et conseils détaillés tout au long du processus de merge request.\n- __Points réguliers__ : collaboration continue pour assurer l'avancement de la contribution et répondre aux problématiques rencontrées.\n\nCette structure garantit que les équipes peuvent contribuer efficacement, quelle que soit leur expérience antérieure avec le code base de GitLab ou les langages de programmation Ruby/Go. Comme le note John Parent de Kitware, *« si vous êtes un nouvel utilisateur de GitLab, vous avez l'impression d'être face à une architecture sophistiquée et à une immense quantité de code réparti sur différents projets. Le Programme Co-Create regroupe l'équivalent de plusieurs semaines de formation interne en une formation accélérée et ciblée. »*\n\nEn plus d'aboutir au développement de nouvelles fonctionnalités, ce programme permet d'établir des relations durables entre GitLab et sa communauté d'utilisateurs. *« Le fait que nos clients contribuent avec enthousiasme au développement de nouvelles fonctionnalités est inspirant pour nos ingénieurs »*, révèle Shekhar Patnaik, Principal Engineer chez GitLab. *« Les clients découvrent la \"méthode GitLab\" et les ingénieurs sont témoins de leur engagement à façonner l'avenir de GitLab. »*\n\n## Contribution de Thales : amélioration de l'expérience utilisateur des projets\n\nLa société Thales a identifié des opportunités pour améliorer l'interface utilisateur de la plateforme GitLab lorsque les utilisateurs créent des projets vides. Et elle ne s'est pas contentée de soumettre une demande de fonctionnalité : elle a développé la solution elle-même. Elle a axé ses contributions sur l’amélioration de l'expérience de configuration de nouveaux projets en simplifiant la configuration SSH/HTTPS avec une interface composée de plusieurs onglets et en ajoutant une fonctionnalité de copier/coller pour les extraits de code. Ces changements ont eu un impact significatif sur les workflows des équipes de développement. \n\nL'équipe de Thales n'a pas seulement travaillé à l'amélioration de l'UX. Quentin Michaud, doctorant travaillant dans le domaine des applications cloud en périphérie chez Thales, a contribué à l'amélioration du GitLab Development Kit (GDK). Chargé de maintenance de paquets pour Arch Linux, Quentin Michaud, fort de son expertise, a contribué à enrichir la documentation du GDK et à soutenir sa conteneurisation, facilitant ainsi le travail des futurs contributeurs.\n\n*« Grâce à mon expérience en open source, j'ai pu améliorer la prise en charge des distributions Linux par le GDK »*, explique Quentin Michaud. *« Pendant que j'améliorais la documentation sur la gestion de versions des paquets, j'ai constaté que l'équipe Contributor Success de GitLab travaillait également à l'intégration du GDK dans un conteneur. Voir nos efforts converger a été un grand moment pour moi. Cela a montré que la collaboration open source peut contribuer à la création de meilleures solutions. »*\n\nL'expérience s'étant avérée positive pour l'équipe de Thales, Sébastien Lejeune utilise désormais le Programme Co-Create comme exemple *« pour montrer à nos managers le retour sur investissement généré grâce aux contributions open source. »*\n\n## Contribution de Scania : amélioration de la prise en charge des paquets\nLorsque l'entreprise Scania a eu besoin d'une prise en charge avancée des paquets dans GitLab, elle a vu une opportunité d'apporter sa contribution et de développer cette fonctionnalité elle-même. \n\n*« Cela fait longtemps que nous utilisons la plateforme GitLab et que nous promouvons activement l'open source au sein de notre entreprise. Le Programme Co-Create est pour nous une façon concrète d'y contribuer directement »*, révèle Puttaraju Venugopal Hassan, Solution Architect chez Scania.\n\nL'équipe a commencé par des changements mineurs pour se familiariser avec le code base et le processus de revue avant de passer à des fonctionnalités plus importantes. *« L'un des aspects les plus gratifiants du Programme Co-Create a été de revenir sur l'ensemble du processus et de voir le chemin parcouru »*, indique Océane Legrand, Software Developer chez Scania. *« Nous avons commencé par évaluer les besoins et apporter de petits changements, avant de passer à des tâches plus importantes au fil du temps. C'est formidable de voir cette progression. »*\n\nLes contributions de l'équipe de Scania incluent la correction des bogues pour le registre de paquets, ainsi que l'amélioration des fonctionnalités du registre de paquets Conan. Ce dernier pourra bientôt être proposé en disponibilité générale (GA), avec l'implémentation de la prise en charge de la version 2 de Conan. Le travail et la collaboration de Scania avec GitLab sont la preuve que le Programme Co-Create peut apporter des améliorations significatives aux fonctionnalités de registre de paquets de GitLab.\n\n*« Dès le début, notre expérience avec le Programme Co-Create a été très organisée. Nous avons participé à des sessions de formation pendant lesquelles nous avons pu découvrir tous les éléments nécessaires à notre contribution. Des sessions individuelles avec un ingénieur GitLab nous ont également offert une vue détaillée de l'architecture des paquets de GitLab, ce qui a rendu le processus de contribution beaucoup plus fluide »*, déclare Juan Pablo Gonzalez, Software Developer chez Scania. \n\nL'impact du programme va au-delà du code. En effet, les participants acquièrent également des compétences précieuses grâce à leurs contributions. À l'occasion de la sortie de [la version 17.8 de GitLab](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), Océane Legrand et Juan Pablo Gonzalez ont tous deux été désignés comme Most Valuable Person (MVP) de GitLab. Océane Legrand a parlé de l'impact de son travail en open source sur GitLab et Scania, y compris l'obtention de nouvelles compétences pour elle et son équipe : *« Ma contribution au travers du Programme Co-Create m'a permis d'acquérir de nouvelles compétences et une expérience de Ruby et des migrations en arrière-plan. Lorsque mon équipe chez Scania a rencontré un problème lors d'une mise à niveau, j'ai pu participer à sa résolution, car je l'avais déjà rencontré dans le cadre du Programme Co-Create. »*\n\n## Contribution de Kitware : optimisation de l'authentification pour le calcul haute performance\nKitware a mis à profit son expertise spécialisée issue de son travail avec des laboratoires nationaux pour améliorer le framework d'authentification de GitLab. Ses contributions comprenaient l'ajout de la prise en charge du flux d'autorisation d'appareil OAuth2 dans GitLab, ainsi que la mise en œuvre de nouveaux composants, tels que des tables de base de données, des contrôleurs, des vues et de la documentation. Ces améliorations élargissent les options d'authentification de GitLab, rendant la plateforme plus polyvalente pour les appareils sans navigateur ou disposant de capacités de saisie limitées.\n\n*« Le Programme Co-Create est le moyen le plus efficace de contribuer à GitLab en tant que contributeur externe »*, estime John Parent, R&D Engineer chez Kitware. *« Grâce aux sessions de [pair programming](https://about.gitlab.com/fr-fr/blog/agile-pairing-sessions/ \"Pair programming\") entre développeurs et développeuses, nous avons identifié de meilleures implémentations que nous aurions peut-être manquées si nous avions travaillé seuls. »*\n\nEn tant que contributeur open source de longue date, Kitware a particulièrement apprécié l'approche de développement de GitLab. *« Je me doutais que GitLab ne se contenterait pas de solutions prêtes à l'emploi à son échelle, mais voir les équipes de développement intégrer une dépendance Ruby au lieu de créer une solution interne personnalisée était génial »*, explique John Parent. *« Venant du monde C++, où les gestionnaires de paquets sont rares, j'ai apprécié de voir cette approche et sa simplicité. »*\n\n## Quels sont les avantages du Programme Co-Create ?\n\nLe Programme Co-Create crée de la valeur à la fois pour GitLab et le partenaire impliqué. *« Le programme comble le fossé qui peut exister entre les ingénieurs qui développent GitLab et nos clients »*, affirme Imre Farkas, Staff Backend Engineer chez GitLab. *« Collaborer avec les clients nous permet de comprendre leurs défis quotidiens, les parties de l'écosystème GitLab sur lesquelles ils s'appuient et les domaines dans lesquels des améliorations peuvent être apportées. C'est formidable de voir à quel point ils sont enthousiastes à l'idée de s'impliquer dans le développement de GitLab à nos côtés. »*\n\nCette approche collaborative accélère également le développement de GitLab. Comme l'observe Shekhar Patnaik, Principal Engineer chez GitLab : *« Grâce au Programme Co-Create, nos clients nous aident à faire progresser notre roadmap. Leurs contributions nous permettent de fournir des fonctionnalités critiques plus rapidement, ce qui profite à l'ensemble de notre base d'utilisateurs. Le programme étant en constante évolution, nous avons de fortes chances d'accélérer le développement de nos fonctionnalités les plus importantes en travaillant aux côtés des personnes qui comptent sur elles. »*\n\n## Premiers pas avec le Programme Co-Create\nVous souhaitez transformer vos demandes de fonctionnalités en réalité ? Que vous cherchiez à perfectionner l'interface utilisateur de GitLab comme Thales, à améliorer la prise en charge des paquets comme Scania ou à optimiser l'authentification comme Kitware, le Programme Co-Create accueille les entreprises qui souhaitent façonner activement l'avenir de GitLab tout en développant une expérience open source précieuse.\n\nContactez votre représentant GitLab pour en savoir plus sur la participation au Programme Co-Create ou visitez notre [page dédiée](https://about.gitlab.com/community/co-create/) pour plus d'informations.\n","customer-stories",[900,9,901],"contributors","customers","2025-02-10",{"slug":904,"featured":91,"template":688},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:fr-fr:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","fr-fr/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":910,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":911,"content":917,"config":926,"_id":928,"_type":14,"title":929,"_source":16,"_file":930,"_stem":931,"_extension":19},"/fr-fr/blog/the-ultimate-guide-to-sboms",{"title":912,"description":913,"ogTitle":912,"ogDescription":913,"noIndex":6,"ogImage":914,"ogUrl":915,"ogSiteName":675,"ogType":676,"canonicalUrls":915,"schema":916},"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?","Découvrez ce qu'est une nomenclature logicielle et pourquoi elle fait désormais partie intégrante du développement logiciel. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Qu’est-ce qu’une nomenclature logicielle (SBOM) et quel est son rôle ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }",{"title":912,"description":913,"authors":918,"heroImage":914,"date":920,"body":921,"category":922,"tags":923,"updatedDate":925},[919],"Sandra Gittlen","2022-10-25","Une nomenclature logicielle (ou SBOM) est une liste complète des composants d’un logiciel qui facilite la compréhension du réseau complexe de bibliothèques, d'outils et de processus utilisés tout au long du cycle de développement. Associées à des outils de gestion des vulnérabilités, les SBOM ne se contentent pas de révéler les vulnérabilités potentielles des logiciels, mais ouvrent également la voie à une stratégie d'atténuation des risques. \n\nDécouvrez dans ce guide tout ce que vous devez savoir sur les SBOM, ainsi que le rôle central qu'elles jouent dans une stratégie [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") multifacette : \n\n- [Qu'est-ce qu'une SBOM ?](#quest-ce-quune-sbom)\n- [Pourquoi les SBOM sont-elles importantes ?](#pourquoi-les-sbom-sont-elles-importantes)\n- [Quels sont les types de normes d'échange de données SBOM ?](#quels-sont-les-types-de-normes-dechange-de-donnees-sbom)\n- [Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?](#quels-sont-les-avantages-de-lassociation-des-sbom-avec-la-gestion-des-vulnerabilites-logicielles)\n- [GitLab et les SBOM dynamiques](#gitlab-et-les-sbom-dynamiques)\n- [L'avenir des fonctionnalités SBOM de GitLab](#lavenir-des-fonctionnalites-sbom-de-gitlab)\n- [Commencez à utiliser les SBOM](#commencez-à-utiliser-les-sbom)\n\n## Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire imbriqué ou une [liste des ingrédients qui constituent les composants logiciels](https://www.cisa.gov/sbom# \"Définition d'une SBOM\"). Les SBOM comprennent des informations critiques sur les bibliothèques, outils et processus utilisés pour développer, construire et déployer un artefact logiciel. \n\nBien que les SBOM soient souvent créées avec des logiciels autonomes, des plateformes DevSecOps comme GitLab intègrent la génération de SBOM dans un workflow DevSecOps.\n\n![Sécurité de la chaîne d'approvisionnement SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n### Pourquoi les SBOM sont-elles importantes ?\n\nAujourd'hui, le secteur du développement logiciel a tendance à prioriser rapidité et efficacité pour la livraison de logiciels. Cependant, cela induit parfois des __risques de sécurité__ via l'intégration de code moins sécurisé provenant de dépôts open source ou de paquets propriétaires.\n\nSelon le rapport « Open Source Security and Risk Analysis » de Synopsys (2024), qui a analysé plus de 1 000 bases de code commerciales issues de 17 industries différentes en 2023, 96 % de ces bases contenaient du code open source et 84 % de celles évaluées pour les risques contenaient des vulnérabilités.\n\nÀ la lecture de ce rapport, il devient clair qu'intégrer du code provenant de dépôts inconnus augmente le risque de failles exploitables par les hackers.\n\nUn exemple connu, l'[attaque de SolarWinds](https://fr.wikipedia.org/wiki/Cyberattaque_de_2020_contre_les_%C3%89tats-Unis \"Attaque de SolarWinds\") en 2020, a été déclenchée par l'activation d'une __injection malveillante de code__ dans un paquet utilisé par le produit Orion de SolarWinds. Cette dernière n'a pas été sans conséquences puisqu'elle a fortement affecté les clients de l’ensemble de la chaîne d'approvisionnement logicielle.\n\nCette attaque, comme bien d'autres (par exemple, la __vulnérabilité Log4j__) ont mis en lumière l'importance d'effectuer une analyse approfondie des dépendances des applications, y compris des __conteneurs et de l'infrastructure__, afin d'évaluer les [risques potentiels tout au long de la chaîne d'approvisionnement logicielle](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/ \"Sécurité de la chaîne d'approvisionnement logicielle\").\n\nLe coût lié à l'identification et à la correction d’une faille de sécurité est un facteur important à ne pas négliger. Mais au-delà de l'aspect financier, une attaque sur la chaîne d'approvisionnement logicielle peut gravement affecter __la réputation d'une entreprise__.\n\nNon seulement les SBOM permettent de __limiter les risques d'attaques__ (et donc de préserver votre réputation), mais elles contribuent également à optimiser les coûts liés à la gestion des vulnérabilités : \n\n- En offrant un aperçu de vos dépendances,\n- En identifiant les vulnérabilités ainsi que les licences non conformes aux protocoles de sécurité internes à votre entreprise. \n\n## Quels sont les types de normes d'échange de données SBOM ?\n\nLes SBOM fonctionnent de manière optimale lorsque la génération et l'interprétation d'informations telles que __le nom, la version, ou encore l’empaqueteur, peuvent être automatisées__. Cette automatisation est optimale si toutes les parties prenantes impliquées utilisent un format standard d'échange de données. \n\nIl existe deux principaux types de normes d'échange de données SBOM utilisées aujourd'hui :\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/ \"OWASP CycloneDX\")\n- [SPDX](https://spdx.dev/ \"SPDX\")\n\nGitLab utilise CycloneDX pour la génération de SBOM, car cette norme est :\n\n- prescriptive (marque un ensemble de normes objectives),\n- facile à comprendre et à prendre en main, \n- capable de simplifier les relations complexes, \n- extensible pour prendre en charge et s'adapter à des cas spécifiques.\n\nDe plus, il existe des outils open source comme cyclonedx-cli et cdx2spdx qui peuvent être utilisés pour convertir des fichiers CycloneDX au format SPDX si nécessaire.\n\n## Quels sont les avantages de l'association des SBOM avec la gestion des vulnérabilités logicielles ?\n\nLes SBOM sont très utiles pour les équipes DevSecOps et les utilisateurs de logiciels, et ce, pour plusieurs raisons :\n\n - Elles permettent une __approche standardisée__ pour comprendre quels composants logiciels supplémentaires sont présents dans une application et où ils sont déclarés.\n - Elles offrent une visibilité continue sur l'__historique de création d'une application__, y compris des détails sur les origines du code tiers et les dépôts hôtes.\n- Elles fournissent un haut niveau de transparence en matière de sécurité, tant pour le code développé en interne que pour les logiciels open source utilisés.\n- Les détails fournis par les SBOM permettent aux [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Construire une équipe DevOps\") d'identifier les vulnérabilités, d'évaluer les risques, puis de les atténuer. \n- Les SBOM fournissent la transparence désormais attendue par les acheteurs d'applications.\n\n## GitLab et les SBOM dynamiques\n\nPour que les SBOM soient les plus efficaces possibles, les entreprises doivent être en mesure :\n\n- de les générer automatiquement,\n- de les connecter à des outils d'analyse de sécurité des applications,\n- d’intégrer les vulnérabilités et les licences dans un tableau de bord (pour faciliter la compréhension et la prise de décision),\n- de les mettre à jour en continu.\n\nSachez que GitLab prend en charge tous ces objectifs. \n\n![Illustration de la gestion dynamique des SBOM](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### Générer et gérer des SBOM à grande échelle\n\nPour se conformer aux réglementations ainsi qu'aux politiques internes de votre entreprise, il est essentiel de disposer de SBOM capables de couvrir tant les logiciels open source que les logiciels tiers et propriétaires.\n\nIl est également nécessaire de mettre en place un processus optimisé afin de créer, fusionner, valider et approuver les SBOM. C'est une condition essentielle à la bonne gestion des SBOM, et ce, pour chaque composant et version de produit.\n\nComment la plateforme GitLab peut-elle vous aider dans la génération de SBOM ? \n\n- La fonctionnalité « [Liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/ \"Liste des dépendances de GitLab\") » rassemble les données connues sur les vulnérabilités et les licences dans une vue unique disponible au sein de l'interface utilisateur de GitLab. \n- Des informations sur le graphe des dépendances sont générées dans le cadre du rapport d'analyse des dépendances. Cela permet aux utilisateurs d'obtenir une vue d'ensemble complète sur les dépendances et les vulnérabilités potentielles au sein de leurs projets ou groupes de projets.  \n- Un artefact au format JSON CycloneDX peut être produit dans le [pipeline CI](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI ?\"). Cette API propose une approche plus nuancée et personnalisée de la génération de SBOM. \n- Les SBOM sont exportables depuis l'interface utilisateur, un pipeline ou un projet spécifique, ou via l'API GitLab.\n\n### Ingérer et fusionner des SBOM\n\nEn ingérant des SBOM tiers, GitLab offre un haut degré de transparence en matière de sécurité, que ce soit pour le code développé par des tiers que pour les logiciels open source utilisés. \n\nGitLab vous permet d'utiliser un job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ? \") pour fusionner simplement plusieurs SBOM CycloneDX. En s'appuyant sur les détails spécifiques à l'implémentation dans les métadonnées CycloneDX de chaque SBOM (comme l'emplacement des fichiers de compilation et de verrouillage), __GitLab élimine les doublons__. Ces données sont également enrichies automatiquement avec des informations sur les licences et les vulnérabilités des composants à l'intérieur de la nomenclature logicielle. \n\n### Accélérer l'atténuation des risques pour une meilleure gestion des SBOM\n\nPour pouvoir créer rapidement des produits de haute qualité, les équipes de développement ont besoin de données exploitables pour identifier et corriger les vulnérabilités critiques des applications. GitLab contribue à sécuriser votre chaîne d'approvisionnement logicielle en [analysant les vulnérabilités](https://docs.gitlab.com/ee/user/application_security/secure_your_application.html \"Comment sécuriser son application ? \") dans le code source, dans les conteneurs, les dépendances et les applications en cours d'exécution.\n\nGitLab offre une couverture complète pour aider dans la gestion des vulnérabilités (vulnerability management) grâce à sa large panoplie de scanners de sécurité : \n\n- des tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n- des tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n- l'analyse des conteneurs\n- l'analyse de la composition logicielle ([SCA](https://about.gitlab.com/direction/secure/composition-analysis/software-composition-analysis/ \"SCA\")) \n\nPour aider les équipes de développement et d'ingénierie en sécurité à mieux comprendre et corriger les vulnérabilités, GitLab met à disposition de ses utilisateurs la fonctionnalité d'explication des vulnérabilités de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/ \"GitLab Duo \"). Cette fonctionnalité alimentée par l'IA fournit une explication sur une vulnérabilité spécifique, comment elle peut être exploitée et, surtout, fournit une recommandation sur la manière de la corriger. Combinée à la [fonctionnalité de résolution des vulnérabilités de GitLab Duo](https://about.gitlab.com/fr-fr/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/ \"Développement de GitLab Duo : corriger les failles de sécurité avec l'IA\"), cette fonctionnalité permet aux équipes DevSecOps de rapidement identifier, analyser et corriger les vulnérabilités de leurs applications.\n\nLa plateforme prend également en charge la création de nouvelles règles (et le [respect de leur application](https://docs.gitlab.com/ee/administration/compliance.html)) basées sur les vulnérabilités nouvellement détectées.\n\n### Analyser les SBOM en continu \n\nL’analyse continue des vulnérabilités de GitLab déclenche une analyse sur tous les projets où l'analyse des conteneurs, l'analyse des dépendances, ou les deux, sont activées indépendamment d'un pipeline.\n\nLorsque de nouvelles CVE (Common Vulnerabilities and Exposures) sont signalées, les utilisateurs n'ont pas besoin de relancer leurs pipelines pour obtenir les dernières informations.\n\nEn effet, l'équipe de recherche sur les vulnérabilités de GitLab les ajoute à la base de données des avis ([GitLab Advisory Database](https://docs.gitlab.com/ee/user/application_security/gitlab_advisory_database/ \"GitLab Advisory Database\")) pour être intégrées dans la liste des vulnérabilités connues de GitLab. Cela rend la SBOM de GitLab véritablement dynamique. \n\n### Renforcer la confiance dans les SBOM\n\nGitLab permet aux entreprises nécessitant une [fonctionnalité de conformité](https://about.gitlab.com/fr-fr/solutions/compliance/ \"La conformité des logiciels avec GitLab\") de [générer des attestations pour tous les artefacts de compilation](https://about.gitlab.com/blog/securing-the-software-supply-chain-through-automated-attestation/ \"Sécuriser la chaîne d'approvisionnement logicielle grâce à l'attestation automatisée\") produits par le GitLab Runner. Le processus est sécurisé, car il est réalisé directement par le [GitLab Runner](https://docs.gitlab.com/runner/ \"GitLab Runner\"), sans qu'il y ait de transfert de données vers un service externe.\n\n## L'avenir des fonctionnalités SBOM de GitLab\n\nLes attaques fréquentes contre de grands fournisseurs de logiciels et sur les environnements open source obligent le monde du développement à renforcer ses défenses contre les menaces extérieures. Pour cette raison, la sécurité de la chaîne d'approvisionnement des logiciels est aujourd'hui un sujet central dans l'industrie de la cybersécurité et du logiciel. \n\nBien que les SBOM évoluent rapidement, des préoccupations subsistent néanmoins. Par exemple : \n\n- la manière et la fréquence dont elles sont générées\n- leur stockage\n- la combinaison de plusieurs SBOM pour des applications complexes\n- leur analyse et utilisation pour améliorer la santé des applications.\n\nGitLab a fait des SBOM une partie intégrante de sa stratégie en matière de [chaîne d'approvisionnement logicielle](https://about.gitlab.com/direction/supply-chain/ \"Chaîne d'approvisionnement logicielle\") et continue d'améliorer ses capacités SBOM en permanence, en intégrant régulièrement de nouvelles fonctionnalités.\n\nParmi ces améliorations, nous retrouvons entre autres : l'automatisation des attestations, la signature numérique des artefacts de compilation et la prise en charge des SBOM générées en externe.\n\nGitLab a également mis en place un [modèle de maturité SBOM](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/ \"Modèle de maturité SBOM\") (SBOM Model Maturity) au sein de sa plateforme. Ce modèle inclut des étapes comme la génération automatique de SBOM, l’approvisionnement en SBOM depuis l'environnement de développement, l’analyse des SBOM pour les artefacts et la promotion de la signature numérique des SBOM.\n\n## Commencez à utiliser les SBOM\n\nLa demande en SBOM est déjà très forte.\n\nAux États-Unis, les agences gouvernementales recommandent, voire exigent des fournisseurs et des développeurs de logiciels fédéraux, et même des communautés open source qu'ils créent des SBOM. \n\nA l'échelle européenne, ce sujet est traité au sein du [règlement sur la cyberrésilience (CRA)](https://digital-strategy.ec.europa.eu/fr/news/cyber-resilience-act-enters-force-make-europes-cyberspace-safer-and-more-secure \"règlement sur la cyberrésilience\"). Quant à la France, c'est l'[Agence nationale de la sécurité des systèmes d'information](https://cyber.gouv.fr/ \"Agence nationale de la sécurité des systèmes d'information\") (ANSSI) qui tranche sur ce type de sujets. \n\nAinsi, que ce soit aux États-Unis, en France, mais aussi ailleurs dans le monde, les agences liées à la sécurité informatique informent sur les menaces grandissantes qui pèsent sur le monde du développement logiciel et numérique plus globalement. \n\nPour anticiper ces exigences, consultez les fonctionnalités SBOM de l'édition GitLab Ultimate disponibles dans la [plateforme DevSecOps de GitLab](https://gitlab.com/-/trials/new \"Essai gratuit de la plateforme GitLab \").\n\n## FAQ sur les SBOM\n\n### Qu'est-ce qu'une SBOM ?\n\nUne SBOM est un inventaire détaillé qui répertorie tous les composants, bibliothèques et outils utilisés pour créer, construire et déployer des logiciels. Cette liste exhaustive inclut des informations essentielles sur les origines du code. Cela favorise une compréhension plus approfondie de la composition d'une application et de ses vulnérabilités potentielles.\n\n### Pourquoi les SBOM sont-elles si importantes ?\n\nLes SBOM sont essentielles pour plusieurs raisons. Elles fournissent :\n\n- __Un aperçu des dépendances.__ Elles permettent de comprendre ce qui compose votre logiciel, et donc de mieux identifier et atténuer les risques associés aux composants tiers.\n- __Une sécurité renforcée.__ Avec une visibilité détaillée des composants de leurs applications, les entreprises peuvent rapidement identifier leurs vulnérabilités et prendre des mesures pour les résoudre.\n- __Une conformité réglementaire.__ De plus en plus, les réglementations et les meilleures pratiques recommandent ou exigent une SBOM pour l'empaquetage de logiciels, en particulier dans le secteur public.\n- __Un développement rationalisé.__ Les équipes de développement peuvent s'appuyer sur les SBOM pour obtenir des informations sur les bibliothèques et les composants utilisés, ce qui permet de gagner du temps et de réduire les erreurs dans le cycle de développement logiciel. \n\n### Quels formats sont utilisés pour l'échange de données SBOM ?\n\nIl existe deux normes prédominantes pour l'échange de données SBOM : \n\n- [CycloneDX](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/ \"CycloneDX\") : connue pour être particulièrement intuitive, CycloneDX simplifie les relations complexes entre les composants logiciels et prend en charge des cas d'utilisation spécifiques. \n- [SPDX](https://docs.gitlab.com/ee/raketasks/spdx.html \"SPDX\") : un autre framework largement utilisé pour l'échange de données SBOM. SPDX fournit des informations détaillées sur les composants au sein de l'environnement logiciel. \n\nEn raison de sa nature normative et de son adaptabilité, GitLab utilise spécifiquement CycloneDX pour sa génération de SBOM.\n\n### Quelle est l’approche de GitLab en matière de SBOM ?\n\nGitLab met l'accent sur la création de SBOM dynamiques qui peuvent être : \n\n- Générées automatiquement : garantir des informations à jour sur la composition logicielle\n- Intégrées avec des outils : se connecter à des outils d’analyse de vulnérabilités, pour une meilleure gestion des risques. \n- Faciles à gérer : prendre en charge l'ingestion et la fusion des SBOM pour une analyse complète \n- Analysées en continu : offrir une analyse continue des projets pour détecter les nouvelles vulnérabilités au fur et à mesure de leur apparition\n\n### Comment puis-je commencer à implémenter les SBOM dans mon entreprise ?\n\nPour les entreprises prêtes à adopter les SBOM, l'édition [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") met à disposition des utilisateurs une plateforme robuste pour générer et gérer des SBOM au sein d'un workflow DevSecOps. En tirant parti des outils de GitLab, les équipes de développement peuvent garantir la conformité logicielle, renforcer la sécurité et optimiser les pratiques de développement.\n\nLa demande croissante de SBOM reflète l’importance grandissante accordée à la sécurité logicielle et à l'intégrité de la chaîne d'approvisionnement. En intégrant les fonctionnalités SBOM, les entreprises peuvent mieux se protéger contre les vulnérabilités et se conformer aux nouvelles réglementations en vigueur.\n\n> [Essayez GitLab Ultimate gratuitement.](https://about.gitlab.com/free-trial/fr-fr/devsecops/ \"Essai gratuit de GitLab Ultimate\")\n\n*Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que les informations contenues dans cet article de blog ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article (et les pages qui y sont liées) sont susceptibles de changer ou d'être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.*\n","security",[922,924,795,9,187],"DevSecOps","2024-12-16",{"slug":927,"featured":6,"template":688},"the-ultimate-guide-to-sboms","content:fr-fr:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","fr-fr/blog/the-ultimate-guide-to-sboms.yml","fr-fr/blog/the-ultimate-guide-to-sboms",{"_path":933,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":934,"content":940,"config":947,"_id":949,"_type":14,"title":950,"_source":16,"_file":951,"_stem":952,"_extension":19},"/fr-fr/blog/what-is-a-hackathon",{"title":935,"description":936,"ogTitle":935,"ogDescription":936,"noIndex":6,"ogImage":937,"ogUrl":938,"ogSiteName":675,"ogType":676,"canonicalUrls":938,"schema":939},"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":935,"description":936,"authors":941,"heroImage":937,"date":942,"body":943,"category":10,"tags":944,"updatedDate":946},[723],"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",[270,945,9],"collaboration","2025-03-20",{"slug":948,"featured":6,"template":688},"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":954,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":955,"content":961,"config":966,"_id":968,"_type":14,"title":969,"_source":16,"_file":970,"_stem":971,"_extension":19},"/fr-fr/blog/what-is-git",{"title":956,"description":957,"ogTitle":956,"ogDescription":957,"noIndex":6,"ogImage":958,"ogUrl":959,"ogSiteName":675,"ogType":676,"canonicalUrls":959,"schema":960},"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":956,"description":957,"authors":962,"heroImage":958,"date":963,"body":964,"category":10,"tags":965},[875],"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",[684,9],{"slug":967,"featured":91,"template":688},"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":973,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":974,"content":980,"config":986,"_id":988,"_type":14,"title":989,"_source":16,"_file":990,"_stem":991,"_extension":19},"/fr-fr/blog/what-is-gitflow",{"title":975,"description":976,"ogTitle":975,"ogDescription":976,"noIndex":6,"ogImage":977,"ogUrl":978,"ogSiteName":675,"ogType":676,"canonicalUrls":978,"schema":979},"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":975,"description":976,"authors":981,"heroImage":977,"date":982,"body":983,"category":10,"tags":984,"updatedDate":985},[875],"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)",[684,9],"2025-06-04",{"slug":987,"featured":6,"template":688},"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":993,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":994,"content":1000,"config":1005,"_id":1007,"_type":14,"title":1008,"_source":16,"_file":1009,"_stem":1010,"_extension":19},"/fr-fr/blog/what-is-open-source",{"title":995,"description":996,"ogTitle":995,"ogDescription":996,"noIndex":6,"ogImage":997,"ogUrl":998,"ogSiteName":675,"ogType":676,"canonicalUrls":998,"schema":999},"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","\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":995,"description":996,"authors":1001,"heroImage":997,"date":1002,"body":1003,"category":10,"tags":1004},[723],"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.",[9,838,924],{"slug":1006,"featured":6,"template":688},"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":1012,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1013,"content":1018,"config":1025,"_id":1027,"_type":14,"title":1028,"_source":16,"_file":1029,"_stem":1030,"_extension":19},"/fr-fr/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":1014,"description":1015,"ogTitle":1014,"ogDescription":1016,"ogImage":1017},"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":1019,"title":1014,"description":1020,"heroImage":1017,"authors":1021,"date":1023,"category":10,"tags":1024},"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.",[1022],"Justin Tobler","2025-07-02",[270,684,9],{"featured":6,"template":688,"slug":1026},"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":1032,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1033,"content":1038,"config":1044,"_id":1046,"_type":14,"title":1047,"_source":16,"_file":1048,"_stem":1049,"_extension":19},"/fr-fr/blog/what-s-new-in-git-2-51-0",{"config":1034,"title":1035,"ogTitle":1035,"description":1036,"ogDescription":1036,"ogImage":1037},{"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":1035,"description":1039,"authors":1040,"heroImage":1037,"date":1041,"body":1042,"category":10,"tags":1043},"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).",[789],"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",[684,9,270],{"featured":6,"template":688,"slug":1045},"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",{"_path":1051,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1052,"content":1057,"config":1063,"_id":1065,"_type":14,"title":1066,"_source":16,"_file":1067,"_stem":1068,"_extension":19},"/fr-fr/blog/whats-new-in-git-2-46-0",{"title":1053,"description":1054,"ogTitle":1053,"ogDescription":1054,"noIndex":6,"ogImage":738,"ogUrl":1055,"ogSiteName":675,"ogType":676,"canonicalUrls":1055,"schema":1056},"Nouveautés de Git 2.46.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-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":1053,"description":1054,"authors":1058,"heroImage":738,"date":1059,"body":1060,"category":10,"tags":1061,"updatedDate":1062},[1022],"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.",[684,9,270],"2024-08-15",{"slug":1064,"featured":91,"template":688},"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":1070,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1071,"content":1076,"config":1082,"_id":1084,"_type":14,"title":1085,"_source":16,"_file":1086,"_stem":1087,"_extension":19},"/fr-fr/blog/whats-new-in-git-2-47-0",{"title":1072,"description":1054,"ogTitle":1072,"ogDescription":1054,"noIndex":6,"ogImage":1073,"ogUrl":1074,"ogSiteName":675,"ogType":676,"canonicalUrls":1074,"schema":1075},"Nouveautés de Git 2.47.0","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.47.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":1072,"description":1054,"authors":1077,"heroImage":1073,"date":1078,"body":1079,"category":10,"tags":1080,"updatedDate":1081},[1022],"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/)",[684,9,270],"2024-10-21",{"slug":1083,"featured":91,"template":688},"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":1089,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1090,"content":1095,"config":1102,"_id":1104,"_type":14,"title":1105,"_source":16,"_file":1106,"_stem":1107,"_extension":19},"/fr-fr/blog/whats-new-in-git-2-48-0",{"title":1091,"description":1092,"ogTitle":1091,"ogDescription":1092,"noIndex":6,"ogImage":1073,"ogUrl":1093,"ogSiteName":675,"ogType":676,"canonicalUrls":1093,"schema":1094},"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://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":1091,"description":1092,"authors":1096,"heroImage":1073,"date":1098,"body":1099,"category":10,"tags":1100,"updatedDate":1101},[1097],"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",[684,9,270],"2025-01-20",{"slug":1103,"featured":91,"template":688},"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":1109,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1110,"content":1116,"config":1123,"_id":1125,"_type":14,"title":1126,"_source":16,"_file":1127,"_stem":1128,"_extension":19},"/fr-fr/blog/whats-new-in-git-2-49-0",{"title":1111,"description":1112,"ogTitle":1111,"ogDescription":1112,"noIndex":6,"ogImage":1113,"ogUrl":1114,"ogSiteName":675,"ogType":676,"canonicalUrls":1114,"schema":1115},"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":1111,"description":1112,"authors":1117,"heroImage":1113,"date":1119,"body":1120,"category":10,"tags":1121,"updatedDate":1122},[1118],"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/)",[270,9,684],"2025-04-10",{"slug":1124,"featured":91,"template":688},"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":1130,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1131,"content":1136,"config":1147,"_id":1149,"_type":14,"title":1150,"_source":16,"_file":1151,"_stem":1152,"_extension":19},"/fr-fr/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":1132,"title":1133,"description":1134,"ogTitle":1133,"ogDescription":1134,"ogImage":1135},{"noIndex":6},"Indépendance des entreprises et DevSecOps","Découvrez les avantages de GitLab pour renforcer l'indépendance et la transparence de votre infrastructure DevSecOps.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1756500636/wmey6kqzzuhirk88w2de.png",{"title":1137,"description":1138,"authors":1139,"heroImage":1135,"date":1141,"body":1142,"category":1143,"tags":1144},"L'indépendance des entreprises : un sujet plus important que jamais en DevSecOps","Dans un contexte où le contrôle des infrastructures de développement soulève de plus en plus d'interrogations, les avantages de GitLab en matière d'indépendance et de transparence n'ont jamais été aussi pertinents.",[1140],"Robin Schulman","2025-09-03","Depuis plus de dix ans, GitLab s'engage en faveur de la transparence, de l'indépendance et d'une approche axée sur les développeurs. Au vu de l'évolution actuelle du secteur, ces aspects sont plus importants que jamais. Dans les entreprises, trois questions sont au cœur des discussions : qui contrôle réellement l'infrastructure de développement ? Comment le code est-il utilisé dans les systèmes d'IA ? Que se passe-t-il lorsque les priorités des fournisseurs ne répondent plus tout à fait aux exigences ?\n\nLe mois dernier, [nous avons annoncé la sortie de GitLab 18.3](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/), la dernière version de notre plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") avec l’IA native. Agent Insights, qui fait partie de GitLab Duo Agent Platform, offre une visibilité sur les processus décisionnels des agents. La prise en charge étendue des modèles d'IA signifie qu'il n'y a aucune dépendance vis-à-vis d'un fournisseur. Par ailleurs, des contrôles de gouvernance améliorés permettent d’assurer la conformité dans plusieurs juridictions.\n\nCes nouveautés sont plus que de simples fonctionnalités. Elles témoignent de la transparence, de l'indépendance et de l'approche axée sur les équipes de développement qui caractérisent GitLab. Voici comment cette stratégie se traduit en pratique.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1115249475?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Who is GitLab_Robin_090225_FINAL\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Transparence de l'IA à chaque étape du cycle de développement DevSecOps\n\n**Chez GitLab, notre engagement de longue date en faveur de la transparence répond directement à ces préoccupations.** À mesure que l'intelligence artificielle s'intègre dans les workflows de développement, les entreprises s'inquiètent à juste titre de la façon dont leur code et leurs données sont utilisés pour entraîner l'IA.\n\nLancé en avril 2024, le [Centre pour la transparence de l'IA](https://about.gitlab.com/fr-fr/ai-transparency-center/) de GitLab fournit une documentation claire sur nos pratiques en matière de gouvernance des données, de protection de la vie privée et de principes éthiques relatifs à l'IA. Contrairement aux plateformes qui exploitent des fonctionnalités d'IA avec des politiques d'utilisation des données peu claires, GitLab privilégie la transparence pour que ses clients puissent comprendre [exactement comment leurs données sont traitées](https://docs.gitlab.com/fr/user/gitlab_duo/data_usage/), stockées et protégées, et garantit que la plateforme ne les utilise pas pour entraîner l'IA.\n\nNotre approche se distingue également par la flexibilité des modèles et notre indépendance vis-à-vis des fournisseurs. Tandis que certaines plateformes obligent leurs clients à utiliser un seul fournisseur de [grands modèles de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu’est-ce qu’un LLM ?\") et créent des dépendances supplémentaires vis-à-vis des fournisseurs et des points de défaillance potentiels, les fonctionnalités d'IA de GitLab s'appuient sur une variété de modèles. Cette approche nous permet de prendre en charge un large éventail de cas d'utilisation et d'offrir à nos clients la flexibilité nécessaire pour s'aligner sur leurs priorités stratégiques.\n\nÀ mesure que nous développons GitLab Duo Agent Platform, nous continuons à prioriser le contrôle des données et le maintien de contrôles humains complets. Par ailleurs, GitLab Duo Self-Hosted offre une souveraineté complète des données avec des options de déploiement air-gapped, des politiques de conservation des données zero-day et la possibilité de traiter toutes les requêtes d'IA au sein de votre propre infrastructure.\n\nEn mai 2024, nous avons élaboré un [plan de continuité IA](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/) que nous mettons régulièrement à jour. Ce dernier contient un engagement de premier plan dans le secteur comme la capacité d'évaluer et de passer à un nouveau modèle dans les 30 jours si un fournisseur modifie ses pratiques en matière de données client. Cette approche proactive de la gestion des risques liés aux fournisseurs d'IA reflète notre engagement en faveur du contrôle client.\n\n## Choix du déploiement et du fournisseur cloud\n\n**Vous devez pouvoir choisir comment et où déployer votre environnement DevSecOps.** Dans ce domaine, GitLab offre une véritable flexibilité de déploiement. Les entreprises peuvent utiliser leurs propres serveurs, le SaaS multilocataire ou GitLab Dedicated, notre solution SaaS monolocataire entièrement gérée, sans compromettre les fonctionnalités ni subir des restrictions artificielles conçues pour favoriser le verrouillage de l'écosystème. GitLab est également compatible avec toutes les solutions cloud, ce qui permet aux clients d'utiliser le fournisseur qui convient le mieux à leurs besoins et à leur environnement.\n\nCette flexibilité s'avère inestimable face à des exigences juridictionnelles complexes et des défis réglementaires toujours plus nombreux. Lorsque de nouvelles lois sur la localisation des données apparaissent, comme nous l'avons vu dans l'Union européenne et d'autres régions, les entreprises qui utilisent GitLab peuvent rapidement adapter leurs stratégies de déploiement sans être limitées par des dépendances liées à leur écosystème.\n\nDu point de vue des achats et de la gestion des risques, l'indépendance de la plateforme offre également un levier crucial dans les négociations de contrat. Les entreprises ne sont pas contraintes de signer des accords de licence restrictifs qui privilégient les intérêts des fournisseurs au détriment des besoins des clients. Cette indépendance devient particulièrement décisive à mesure que les entreprises se montrent plus vigilantes quant au contrôle de leur pile IA.\n\n## Sécurité et conformité : intégrées et toujours prioritaires\n\n**La sécurité et la conformité sont désormais tout aussi importantes que les fonctionnalités de développement et doivent être intégrées à la plateforme, et non ajoutées après coup.** L'approche  de GitLab, basée sur une plateforme unique, offre des avantages significatifs par rapport aux plateformes fragmentées qui s'appuient sur des modules complémentaires tiers pour proposer des fonctionnalités de sécurité et de gouvernance rudimentaires. Cette différence architecturale a des implications importantes en matière de risques juridiques potentiels, d’efficacité opérationnelle et de conformité réglementaire. Chaque outil supplémentaire représente un point de défaillance potentiel supplémentaire, un nouvel ensemble de conditions générales à négocier et une source de risque additionnelle.\n\nGitLab fournit des fonctionnalités intégrées complètes en matière de sécurité et de conformité, y compris des frameworks de conformité personnalisés, des tests dynamiques de sécurité des applications (DAST), des tests d’API par injection de données aléatoires, des tests à données aléatoires guidé par la couverture de code et des tests d'Infrastructure as Code. Ces fonctionnalités sont intégrées en natif à la plateforme, ce qui permet une application cohérente des politiques et réduit la complexité de la conformité et les coûts supplémentaires liés à la gestion de plusieurs outils tiers.\n\nNotre [Centre de conformité](https://docs.gitlab.com/fr/user/compliance/compliance_center/) offre aux équipes un espace centralisé pour gérer les normes et rapports de conformité, les rapports de violations et les frameworks de conformité de leur groupe. Cette approche unifiée de la gestion de la conformité est particulièrement précieuse pour les entreprises qui opèrent dans des secteurs hautement réglementés où les pistes d'audit et la documentation relative à la conformité sont essentielles.\n\n## À l'écoute de notre communauté open source\n\n**Les meilleurs outils sont façonnés par les personnes qui les utilisent.** Notre engagement envers l'[open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu’est-ce que l’open source ?\") et notre communauté sont au cœur de GitLab depuis notre création. Par exemple, notre [programme Co-Create](https://about.gitlab.com/community/co-create/) est une initiative collaborative qui permet à nos clients de travailler directement avec les équipes d'ingénierie de GitLab afin d’apporter des améliorations à la plateforme, comme des fonctionnalités ou des correctifs.\n\nNotre engagement en faveur de la transparence reste fondamental pour notre activité. Notre [système de suivi des tickets ouverts](https://gitlab.com/groups/gitlab-org/-/issues), qui permet aux utilisateurs de suivre nos progrès et d'échanger directement avec les équipes de GitLab sur les améliorations produit en est un bon exemple. Nous avons récemment lancé notre [initiative « Healthy Backlog »](https://about.gitlab.com/fr-fr/blog/inside-gitlabs-healthy-backlog-initiative/) pour donner à nos clients une visibilité encore plus grande sur notre calendrier et traiter leurs retours plus efficacement.\n\nNotre approche permet non seulement aux entreprises de contribuer à l'innovation open source et d'en tirer parti, mais aussi d'assurer la gouvernance, les pistes d'audit et les contrôles de sécurité requis pour les environnements réglementés.\n\n## Gouvernance des données : vos données, vos règles\n\n**Vous conservez un contrôle total sur vos données et leur traitement.** La gouvernance des données est devenue un facteur de plus en plus critique dans les décisions technologiques des entreprises, en raison d’un ensemble complexe de lois nationales et régionales sur la protection des données et d’une préoccupation croissante concernant le contrôle des données sensibles, comme le code source, les informations client, les initiatives stratégiques et la veille concurrentielle.\n\nAvec GitLab, vous pouvez gérer le niveau d’accès aux fonctionnalités alimentées par l'IA au sein de la plateforme, qui vont au-delà des simples contrôles d'accès pour inclure des normes de chiffrement et des fonctionnalités d'audit conformes aux cadres réglementaires. De plus, le code et les données clients ne sont jamais utilisés pour entraîner des modèles d'IA.\n\n## Le choix est clair\n\nGitLab continue d'être à la pointe de l'innovation en matière de plateforme DevSecOps avec l'IA native, comment en témoigne notre dernière [version 18.3](https://about.gitlab.com/fr-fr/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/), tout en restant fidèle aux engagements d'indépendance et de transparence qui nous ont toujours guidés.\n\nContrôle total ou dépendance vis-à-vis d'un fournisseur ? Transparence ou incertitude ? Engagement envers l'innovation ou simple rouage dans un écosystème plus large ? Pour les clients, le choix est clair.\n\nGitLab fournit les bases d'une transformation numérique durable qui trouve le juste équilibre entre innovation et indépendance afin d'aider les entreprises à créer de la valeur commerciale pour leurs clients.\n\n[Essayez GitLab Ultimate gratuitement avec GitLab Duo dès aujourd'hui.](https://about.gitlab.com/fr-fr/free-trial/)","ai-ml",[1145,924,705,1146,9],"AI/ML","features",{"featured":6,"template":688,"slug":1148},"why-enterprise-independence-matters-more-than-ever-in-devsecops","content:fr-fr:blog:why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","Why Enterprise Independence Matters More Than Ever In Devsecops","fr-fr/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","fr-fr/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"_path":1154,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1155,"content":1161,"config":1167,"_id":1169,"_type":14,"title":1170,"_source":16,"_file":1171,"_stem":1172,"_extension":19},"/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format",{"title":1156,"description":1157,"ogTitle":1156,"ogDescription":1157,"noIndex":6,"ogImage":1158,"ogUrl":1159,"ogSiteName":675,"ogType":676,"canonicalUrls":1159,"schema":1160},"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":1156,"description":1157,"authors":1162,"heroImage":1158,"date":1163,"body":1164,"category":10,"tags":1165,"updatedDate":1166},[680],"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.",[684,770,9,795],"2024-12-19",{"slug":1168,"featured":91,"template":688},"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",3,[668,693,713,733,755,778,803,823,845],1758326276418]