[{"data":1,"prerenderedAt":902},["ShallowReactive",2],{"/fr-fr/blog/tags/community/":3,"navigation-fr-fr":19,"banner-fr-fr":439,"footer-fr-fr":452,"community-tag-page-fr-fr":664},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/fr-fr/blog/tags/community","tags",false,"",{"tag":9,"tagSlug":9},"community",{"template":11},"BlogTag","content:fr-fr:blog:tags:community.yml","yaml","Community","content","fr-fr/blog/tags/community.yml","fr-fr/blog/tags/community","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":435,"_type":13,"title":436,"_source":15,"_file":437,"_stem":438,"_extension":18},"/shared/fr-fr/main-navigation","fr-fr",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":376,"minimal":412,"duo":426},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/fr-fr/","gitlab logo","header",{"text":29,"config":30},"Commencer un essai gratuit",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Contacter l'équipe commerciale",{"href":36,"dataGaName":37,"dataGaLocation":27},"/fr-fr/sales/","sales",{"text":39,"config":40},"Connexion",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,187,192,297,357],{"text":45,"config":46,"cards":48,"footer":71},"Plateforme",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":52,"config":53},"Découvrir notre plateforme",{"href":54,"dataGaName":47,"dataGaLocation":27},"/fr-fr/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":59,"config":60},"Découvrez GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":67,"config":68},"En savoir plus",{"href":69,"dataGaName":70,"dataGaLocation":27},"/fr-fr/why-gitlab/","why gitlab",{"title":72,"items":73},"Démarrer avec",[74,79,84],{"text":75,"config":76},"Ingénierie de plateforme",{"href":77,"dataGaName":78,"dataGaLocation":27},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Expérience développeur",{"href":82,"dataGaName":83,"dataGaLocation":27},"/fr-fr/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":169},"Produit",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Voir toutes les solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/fr-fr/solutions/",[98,124,147],{"title":99,"description":100,"link":101,"items":106},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[107,111,115,120],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/fr-fr/solutions/continuous-integration/",{"text":112,"config":113},"Développement assisté par l'IA",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Gestion du code source",{"href":118,"dataGaLocation":27,"dataGaName":119},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Livraison de logiciels automatisée",{"href":104,"dataGaLocation":27,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":27,"icon":131},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":141,"dataGaLocation":27,"dataGaName":142},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":27},"/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Mesures",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Visibilité et mesures",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Gestion de la chaîne de valeur",{"href":162,"dataGaLocation":27,"dataGaName":163},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Données d'analyse et informations clés",{"href":167,"dataGaLocation":27,"dataGaName":168},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab pour",[172,177,182],{"text":173,"config":174},"Entreprises",{"href":175,"dataGaLocation":27,"dataGaName":176},"/fr-fr/enterprise/","enterprise",{"text":178,"config":179},"PME",{"href":180,"dataGaLocation":27,"dataGaName":181},"/fr-fr/small-business/","small business",{"text":183,"config":184},"Secteur public",{"href":185,"dataGaLocation":27,"dataGaName":186},"/fr-fr/solutions/public-sector/","public sector",{"text":188,"config":189},"Tarifs",{"href":190,"dataGaName":191,"dataGaLocation":27,"dataNavLevelOne":191},"/fr-fr/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":284},"Ressources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Afficher toutes les ressources",{"href":199,"dataGaName":195,"dataGaLocation":27},"/fr-fr/resources/",[201,234,257],{"title":202,"items":203},"Premiers pas",[204,209,214,219,224,229],{"text":205,"config":206},"Installation",{"href":207,"dataGaName":208,"dataGaLocation":27},"/fr-fr/install/","install",{"text":210,"config":211},"Guides de démarrage rapide",{"href":212,"dataGaName":213,"dataGaLocation":27},"/fr-fr/get-started/","quick setup checklists",{"text":215,"config":216},"Apprentissage",{"href":217,"dataGaLocation":27,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Documentation sur le produit",{"href":222,"dataGaName":223,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Vidéos sur les bonnes pratiques",{"href":227,"dataGaName":228,"dataGaLocation":27},"/fr-fr/getting-started-videos/","best practice videos",{"text":230,"config":231},"Intégrations",{"href":232,"dataGaName":233,"dataGaLocation":27},"/fr-fr/integrations/","integrations",{"title":235,"items":236},"Découvrir",[237,242,247,252],{"text":238,"config":239},"Histoires de succès client",{"href":240,"dataGaName":241,"dataGaLocation":27},"/fr-fr/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":27},"/fr-fr/blog/","blog",{"text":248,"config":249},"Travail à distance",{"href":250,"dataGaName":251,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":27},"/fr-fr/teamops/","teamops",{"title":258,"items":259},"Connecter",[260,265,269,274,279],{"text":261,"config":262},"Services GitLab",{"href":263,"dataGaName":264,"dataGaLocation":27},"/fr-fr/services/","services",{"text":266,"config":267},"Communauté",{"href":268,"dataGaName":9,"dataGaLocation":27},"/community/",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Événements",{"href":277,"dataGaName":278,"dataGaLocation":27},"/events/","events",{"text":280,"config":281},"Partenaires",{"href":282,"dataGaName":283,"dataGaLocation":27},"/fr-fr/partners/","partners",{"backgroundColor":285,"textColor":286,"text":287,"image":288,"link":292},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":289,"config":290},"carte promo The Source",{"src":291},"/images/navigation/the-source-promo-card.svg",{"text":293,"config":294},"Lire les articles les plus récents",{"href":295,"dataGaName":296,"dataGaLocation":27},"/fr-fr/the-source/","the source",{"text":298,"config":299,"lists":301},"Société",{"dataNavLevelOne":300},"company",[302],{"items":303},[304,309,315,317,322,327,332,337,342,347,352],{"text":305,"config":306},"À propos",{"href":307,"dataGaName":308,"dataGaLocation":27},"/fr-fr/company/","about",{"text":310,"config":311,"footerGa":314},"Emplois",{"href":312,"dataGaName":313,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":27},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":323,"config":324},"Équipe",{"href":325,"dataGaName":326,"dataGaLocation":27},"/company/team/","team",{"text":328,"config":329},"Manuel",{"href":330,"dataGaName":331,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Relations avec les investisseurs",{"href":335,"dataGaName":336,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Centre de confiance",{"href":340,"dataGaName":341,"dataGaLocation":27},"/fr-fr/security/","trust center",{"text":343,"config":344},"Centre pour la transparence de l'IA",{"href":345,"dataGaName":346,"dataGaLocation":27},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":27},"/company/contact/","newsletter",{"text":353,"config":354},"Presse",{"href":355,"dataGaName":356,"dataGaLocation":27},"/press/","press",{"text":358,"config":359,"lists":360},"Nous contacter",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":34,"config":364},{"href":36,"dataGaName":365,"dataGaLocation":27},"talk to sales",{"text":367,"config":368},"Aide",{"href":369,"dataGaName":370,"dataGaLocation":27},"/support/","get help",{"text":372,"config":373},"Portail clients GitLab",{"href":374,"dataGaName":375,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"Fermer",{"text":379,"link":380},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":381,"config":382},"gitlab.com",{"href":41,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,391,396,398,403,408],{"text":56,"config":389},{"href":61,"dataGaName":390,"dataGaLocation":384},"GitLab Duo (AI)",{"text":392,"config":393},"Suggestions de code (IA)",{"href":394,"dataGaName":395,"dataGaLocation":384},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":397},{"href":110,"dataGaName":108,"dataGaLocation":384},{"text":399,"config":400},"GitLab sur AWS",{"href":401,"dataGaName":402,"dataGaLocation":384},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":404,"config":405},"GitLab sur Google Cloud ",{"href":406,"dataGaName":407,"dataGaLocation":384},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":409,"config":410},"Pourquoi utiliser GitLab ?",{"href":69,"dataGaName":411,"dataGaLocation":384},"Why GitLab?",{"freeTrial":413,"mobileIcon":418,"desktopIcon":423},{"text":414,"config":415},"Commencer votre essai gratuit",{"href":416,"dataGaName":32,"dataGaLocation":417},"https://gitlab.com/-/trials/new/","nav",{"altText":419,"config":420},"Icône GitLab",{"src":421,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":419,"config":424},{"src":425,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-type.svg",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"En savoir plus sur GitLab Duo",{"href":61,"dataGaName":430,"dataGaLocation":417},"gitlab duo",{"altText":419,"config":432},{"src":421,"dataGaName":422,"dataGaLocation":417},{"altText":419,"config":434},{"src":425,"dataGaName":422,"dataGaLocation":417},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":440,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":441,"titleMobile":441,"button":442,"config":447,"_id":449,"_type":13,"_source":15,"_file":450,"_stem":451,"_extension":18},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":443,"config":444},"Essayer la version bêta",{"href":445,"dataGaName":446,"dataGaLocation":27},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":448},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":453,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":660,"_type":13,"title":661,"_source":15,"_file":662,"_stem":663,"_extension":18},"/shared/fr-fr/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":457,"config":458},"Afficher le code source de la page",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Modifier cette page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Veuillez contribuer",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,588,622],{"title":45,"links":479,"subMenu":484},[480],{"text":481,"config":482},"Plateforme DevSecOps",{"href":54,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":188,"links":486},[487,491,496],{"text":488,"config":489},"Voir les forfaits",{"href":190,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Pourquoi choisir GitLab Premium ?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/fr-fr/pricing/premium/","why premium",{"text":497,"config":498},"Pourquoi choisir GitLab Ultimate ?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/fr-fr/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"Transformation digitale",{"href":507,"dataGaName":508,"dataGaLocation":461},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sécurité et conformité",{"href":136,"dataGaName":137,"dataGaLocation":461},{"text":121,"config":513},{"href":104,"dataGaName":105,"dataGaLocation":461},{"text":515,"config":516},"Développement agile",{"href":517,"dataGaName":518,"dataGaLocation":461},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Transformation cloud",{"href":522,"dataGaName":523,"dataGaLocation":461},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":118,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":108,"config":529},{"href":110,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":160,"config":532},{"href":162,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/fr-fr/solutions/gitops/","gitops",{"text":173,"config":540},{"href":175,"dataGaName":176,"dataGaLocation":461},{"text":178,"config":542},{"href":180,"dataGaName":181,"dataGaLocation":461},{"text":183,"config":544},{"href":185,"dataGaName":186,"dataGaLocation":461},{"text":546,"config":547},"Formation",{"href":548,"dataGaName":549,"dataGaLocation":461},"/fr-fr/solutions/education/","education",{"text":551,"config":552},"Services financiers",{"href":553,"dataGaName":554,"dataGaLocation":461},"/fr-fr/solutions/finance/","financial services",{"title":193,"links":556},[557,559,561,563,566,568,572,574,576,578,580,582,584,586],{"text":205,"config":558},{"href":207,"dataGaName":208,"dataGaLocation":461},{"text":210,"config":560},{"href":212,"dataGaName":213,"dataGaLocation":461},{"text":215,"config":562},{"href":217,"dataGaName":218,"dataGaLocation":461},{"text":220,"config":564},{"href":222,"dataGaName":565,"dataGaLocation":461},"docs",{"text":243,"config":567},{"href":245,"dataGaName":246},{"text":569,"config":570},"Histoires de réussite client",{"href":571,"dataGaLocation":461},"/customers/",{"text":238,"config":573},{"href":240,"dataGaName":241,"dataGaLocation":461},{"text":248,"config":575},{"href":250,"dataGaName":251,"dataGaLocation":461},{"text":261,"config":577},{"href":263,"dataGaName":264,"dataGaLocation":461},{"text":253,"config":579},{"href":255,"dataGaName":256,"dataGaLocation":461},{"text":266,"config":581},{"href":268,"dataGaName":9,"dataGaLocation":461},{"text":270,"config":583},{"href":272,"dataGaName":273,"dataGaLocation":461},{"text":275,"config":585},{"href":277,"dataGaName":278,"dataGaLocation":461},{"text":280,"config":587},{"href":282,"dataGaName":283,"dataGaLocation":461},{"title":298,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":305,"config":591},{"href":307,"dataGaName":300,"dataGaLocation":461},{"text":310,"config":593},{"href":312,"dataGaName":313,"dataGaLocation":461},{"text":318,"config":595},{"href":320,"dataGaName":321,"dataGaLocation":461},{"text":323,"config":597},{"href":325,"dataGaName":326,"dataGaLocation":461},{"text":328,"config":599},{"href":330,"dataGaName":331,"dataGaLocation":461},{"text":333,"config":601},{"href":335,"dataGaName":336,"dataGaLocation":461},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":461},"/sustainability/",{"text":607,"config":608},"Diversité, inclusion et appartenance (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":461},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":612},{"href":340,"dataGaName":341,"dataGaLocation":461},{"text":348,"config":614},{"href":350,"dataGaName":351,"dataGaLocation":461},{"text":353,"config":616},{"href":355,"dataGaName":356,"dataGaLocation":461},{"text":618,"config":619},"Déclaration de transparence sur l'esclavage moderne",{"href":620,"dataGaName":621,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":358,"links":623},[624,627,629,631,636,641,646],{"text":625,"config":626},"Échanger avec un expert",{"href":36,"dataGaName":37,"dataGaLocation":461},{"text":367,"config":628},{"href":369,"dataGaName":370,"dataGaLocation":461},{"text":372,"config":630},{"href":374,"dataGaName":375,"dataGaLocation":461},{"text":632,"config":633},"Statut",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"Conditions d'utilisation",{"href":639,"dataGaName":640},"/terms/","terms of use",{"text":642,"config":643},"Déclaration de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":461},"/fr-fr/privacy/","privacy statement",{"text":647,"config":648},"Préférences en matière de cookies",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,658],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":656,"config":657},"Politique de confidentialité",{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":659},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"allPosts":665,"featuredPost":878,"totalPagesCount":900,"initialPosts":901},[666,690,713,737,759,780,799,818,837,857],{"_path":667,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":672,"config":683,"_id":686,"_type":13,"title":687,"_source":15,"_file":688,"_stem":689,"_extension":18},"/fr-fr/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":669,"description":670,"ogDescription":670,"ogTitle":669,"ogImage":671},"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":670,"title":673,"category":674,"tags":675,"heroImage":671,"date":678,"body":679,"authors":680},"Comment nous utilisons GitLab pour développer les communautés open source","open-source",[676,9,677],"open source","product","2025-07-22","L'équipe Contributor Success de GitLab faisait face au défi suivant : alors\nque nos contributeurs open source récurrents fusionnaient davantage de\nmodifications de code et collaboraient sur des fonctionnalités avancées, les\ncontributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions\nconscients que beaucoup de nouveaux contributeurs open source finissaient\npar abandonner sans même demander de l'aide. Attachés à la [mission de\nGitLab](https://handbook.gitlab.com/handbook/company/mission/) où chacun\npeut contribuer, nous aspirions à inverser cette tendance.\n\n\nNous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.\n\n\nTrois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.\n\n\nVoici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\").\n\n\n## Ce que nous avons appris sur les nouveaux contributeurs\n\n\nEn 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.\n\n\nVoici ce qu’ils nous ont dit : \n\n\n* La documentation destinée aux contributeurs était confuse\n\n* La prise en main était difficile \n\n* Trouver de l’aide n'était pas clair\n\n\nSeul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.\n\n\nIl est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc [itéré](https://handbook.gitlab.com/handbook/values/#iteration) !\n\n\nNotre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.\n\n\nEn 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.\n\n\n## Création d’une intégration personnalisée\n\n\nNotre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.\n\n\nNous avons créé un [template de ticket ](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md)avec une liste claire de tâches.\n\n\nLe ticket d'intégration gère également l'approbation d'accès aux [forks de la communauté de GitLab](https://about.gitlab.com/blog/gitlab-community-forks/), une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.\n\n\nEn utilisant des [labels à portée limitée](https://docs.gitlab.com/user/project/labels/#scoped-labels), nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.\n\n\n![Ticket d'intégration GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nNous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.\n\n\nÀ partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets. \n\n\n## Standardisation des réponses avec des templates de commentaires\n\n\nAvec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.\n\n\nNous avons créé des [templates de commentaires](https://docs.gitlab.com/user/profile/comment_templates/), que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un [script Ruby](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\n\nLe script est déclenché dans le fichier `.gitlab-ci.yml` lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).\n\n\n```yaml\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n![Template de commentaire dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Suppression du temps d'attente de 5 minutes\n\n\nNotre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.\n\n\n[Niklas](https://gitlab.com/Taucher2003), un membre de notre [équipe Core](https://about.gitlab.com/community/core-team/), a trouvé une solution. Il a ajouté des [événements webhook pour les demandes d'accès](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094) et des [templates de charge utile personnalisés pour les webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\n\nCes fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée. \n\n\nNous avons configuré un [token de déclenchement de pipeline](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :\n\n\n```json\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n```\n\n\n![Liste de pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Automatisation des suivis\n\n\nAvec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.\n\n\nNous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance. \n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.\n\n\n![Relance automatisée des tickets d'intégration inactif dans GitLab ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## Organisation du suivi des tickets avec GLQL\n\n\nNous avons construit une [vue GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.\n\n\n![Vue GLQL du suivi des tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nCes vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes [GitLab pour l’open source](https://about.gitlab.com/fr-fr/solutions/open-source/) et [GitLab pour l'éducation](https://about.gitlab.com/fr-fr/solutions/education/). Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.\n\n\n## Meilleure accessibilité du README\n\n\nLe [groupe @gitlab-community](https://gitlab.com/gitlab-community/) est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier `README.md` expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.\n\n\nNous avons alors utilisé la [mise en miroir de projet de GitLab](https://docs.gitlab.com/user/project/repository/mirror/) pour résoudre cela et mis en miroir le projet meta vers `gitlab-profile`. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.\n\n\n![Mise en miroir de projet GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![README de groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Les résultats parlent d'eux-mêmes\n\n\nEn utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD?\").\n\n\nNotre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.\n\n\n![Graphique de croissance des forks de la communauté](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nNous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer. \n\n\nNous utilisons l’[analyse de la chaîne de valeur](https://docs.gitlab.com/user/group/value_stream_analytics/) de GitLab pour suivre nos taux de réponse.\n\n\n* Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois\n\n* Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois\n\n\n![Chronologie de l’analyse de la chaîne de valeur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nLe taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.\n\n\n## Meilleure reconnaissance des contributeurs\n\n\nCorriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : [contributors.gitlab.com](http://contributors.gitlab.com). Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.\n\n\n## Partager ce que nous avons appris\n\nCes améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer. \n\n\nAu fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance. \n\n\n**Contactez-nous**\n\n\nVous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à contributors@gitlab.com ou [créez un ticket](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues) pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.\n",[681,682],"Lee Tickett","Daniel Murphy",{"featured":6,"template":684,"slug":685},"BlogPost","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":691,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":692,"content":697,"config":707,"_id":709,"_type":13,"title":710,"_source":15,"_file":711,"_stem":712,"_extension":18},"/fr-fr/blog/inside-gitlabs-healthy-backlog-initiative",{"config":693,"title":694,"description":695,"ogImage":696},{"noIndex":6},"Amélioration de la gestion des tickets de la communauté","Nous avons amélioré la gestion des tickets pour prioriser le travail stratégique, optimiser la livraison et créer des boucles de rétroaction plus efficaces avec nos utilisateurs. ","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png",{"title":698,"description":699,"date":700,"body":701,"heroImage":696,"authors":702,"category":704,"tags":705},"Amélioration de la gestion des tickets créés par la communauté GitLab","Découvrez comment nous améliorons la gestion des tickets pour prioriser le travail stratégique, optimiser la livraison de logiciels et créer des boucles de rétroaction plus efficaces avec nos utilisateurs.","2025-07-30","Chez GitLab, nous sommes fiers de la relation solide et collaborative que nous entretenons avec notre communauté. Nous encourageons chacun à contribuer à GitLab. Au fil des années, ces contributions communautaires ont permis de renforcer notre plateforme. Mais au fur et à mesure de notre croissance, la participation de la communauté via les tickets GitLab a également augmenté, créant un backlog de tickets difficile à gérer.\n\nLes équipes chargées du produit et de l'ingénierie de GitLab ont récemment lancé [une initiative pour traiter ce backlog et affiner notre approche de la gestion des tickets](https://gitlab.com/groups/gitlab-org/-/epics/18639). \n\nLes tickets avec un engagement communautaire continu, une activité récente ou un alignement stratégique clair resteront ouverts. Nous fermerons les tickets qui ne sont plus pertinents, qui manquent d'intérêt ou qui ne correspondent plus à notre direction produit.\n\nCette approche ciblée conduira à une innovation accrue, à une meilleure définition des attentes et à des cycles de développement et de livraison plus rapides pour les fonctionnalités proposées par la communauté.\n\n## Présentation de l'initiative\n\nAu fil du temps, la communauté GitLab a soumis des dizaines de milliers de tickets, incluant des bogues, des demandes de fonctionnalités et des retours. Actuellement, [notre système principal de suivi des tickets](https://gitlab.com/gitlab-org/gitlab/-/issues) contient plus de 65 000 tickets. Certains ne sont plus applicables à la plateforme, tandis que d'autres restent toujours pertinents. \n\nAvec cette initiative, nos équipes chargées du produit et de l'ingénierie pourront réduire le backlog et établir un workflow afin de mettre en œuvre une approche plus ciblée de la gestion du backlog. Elles effectueront des évaluations hebdomadaires du backlog pour s'assurer que nous priorisons les tickets qui s'alignent avec notre stratégie produit et notre roadmap.\n\nRemarque : Si vous pensez qu’un ticket fermé s'aligne avec la stratégie produit et la roadmap de GitLab, ou si vous contribuez activement à cette demande, nous vous encourageons à commenter le ticket. Nous nous engageons à examiner ces tickets mis à jour dans le cadre de nos efforts d'évaluation réguliers.\n\n## Quels sont les avantages ?\n\nCette approche rationalisée apporte des améliorations directes et concrètes pour chaque utilisateur de GitLab :\n\n* **Un focus plus précis et une livraison plus rapide :** en recentrant notre backlog sur des fonctionnalités stratégiquement alignées, nous pouvons allouer nos ressources de développement plus efficacement. Cela signifie que vous pouvez vous attendre à des cycles de développement plus courts et à des améliorations plus significatives de votre expérience GitLab.\n* **Des attentes plus claires :** nous nous engageons à communiquer de manière transparente sur ce qui figure ou non dans notre roadmap, afin que vous puissiez prendre des décisions éclairées concernant vos workflows et vos contributions.\n* **Des boucles de rétroaction accélérées :** avec un backlog épuré, les nouveaux retours et demandes de fonctionnalités seront examinés et priorisés plus efficacement, réduisant le temps global de triage et garantissant que les tickets urgents reçoivent l'attention nécessaire. Cela crée une boucle de rétroaction plus réactive pour tous.\n\nCette initiative ne diminue pas l'importance des retours et des contributions de la communauté. Nous prenons cette mesure pour clarifier ce que les membres de l'équipe GitLab peuvent réellement s'engager à livrer, et pour garantir que tous les retours reçoivent la considération appropriée.\n\n## Perspectives d'avenir\n\nCette initiative reflète notre engagement à être des gestionnaires transparents et efficaces de la plateforme GitLab. En communiquant clairement nos priorités et en concentrant nos efforts sur ce que nous pouvons réellement livrer au cours de l'année à venir, nous sommes mieux positionnés pour répondre et dépasser vos attentes.\n\nVotre participation et vos retours continus contribuent à renforcer GitLab. Chaque commentaire, merge request, rapport de bogue et suggestion de fonctionnalité contribue à notre vision commune. Et nous continuons à vous récompenser pour cela, avec des initiatives comme notre programme mensuel Notable Contributor, des récompenses, et plus encore, via notre [portail dédié aux contributeurs](https://contributors.gitlab.com/).\n\nPour en savoir plus sur comment contribuer à GitLab, consultez notre [page Communauté](https://about.gitlab.com/community/). Pour partager vos retours sur cette initiative, veuillez ajouter vos commentaires sur [ce ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/556865).",[703],"Stan Hu","engineering",[9,677,706],"news",{"featured":6,"template":684,"slug":708},"inside-gitlabs-healthy-backlog-initiative","content:fr-fr:blog:inside-gitlabs-healthy-backlog-initiative.yml","Inside Gitlabs Healthy Backlog Initiative","fr-fr/blog/inside-gitlabs-healthy-backlog-initiative.yml","fr-fr/blog/inside-gitlabs-healthy-backlog-initiative",{"_path":714,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":715,"content":723,"config":731,"_id":733,"_type":13,"title":734,"_source":15,"_file":735,"_stem":736,"_extension":18},"/fr-fr/blog/we-need-to-talk-no-proxy",{"title":716,"description":717,"ogTitle":716,"ogDescription":717,"noIndex":6,"ogImage":718,"ogUrl":719,"ogSiteName":720,"ogType":721,"canonicalUrls":719,"schema":722},"Pouvons-nous standardiser la variable d'environnement NO_PROXY ?","Découvrez notre guide complet sur no_proxy, la configuration des paramètres\ndu proxy, ainsi que les spécificités de no_proxy, http_proxy et https_proxy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","https://about.gitlab.com/blog/we-need-to-talk-no-proxy","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pouvons-nous standardiser la variable d'environnement NO_PROXY ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2021-01-27\",\n      }",{"title":716,"description":717,"authors":724,"heroImage":718,"date":725,"body":726,"category":704,"tags":727},[703],"2021-01-27","Si vous avez déjà utilisé un serveur proxy Web, vous êtes probablement familier avec les variables d’environnement `http_proxy` ou `HTTP_PROXY`. Cependant, vous l'êtes peut-être moins avec la variable `no_proxy` qui permet d’exclure le trafic destiné à certains hôtes d'utiliser le proxy. Bien que le protocole HTTP soit standardisé, aucune norme ne précise comment utiliser ces variables. Par conséquent, les clients Web prennent en charge ces variables de manière différente.  \n\nDécouvrez dans cet article tout ce que vous devez savoir sur la variable d’environnement no_proxy, ainsi qu’un cas pratique d’un de nos clients GitLab. \n\n## Comprendre http_proxy, https_proxy et no_proxy\n\nDe nos jours, la plupart des clients Web permettent de se connecter à des serveurs proxy via les variables d'environnement suivantes : \n\n- `http_proxy` / `HTTP_PROXY`\n- `https_proxy` / `HTTPS_PROXY`\n- `no_proxy` / `NO_PROXY`\n\nCes variables indiquent au client l'URL à utiliser pour accéder aux serveurs proxy et quelles exceptions appliquer. \n\nPar exemple, si vous avez un serveur proxy attaché à `http://alice.example.com:8080`, vous pourriez l’utiliser via : \n\n```sh\nexport http_proxy=http://alice.example.com:8080\n```\n\nMais quel serveur proxy sera utilisé si Maxime définit aussi la version en majuscules : `HTTP_PROXY` ?\n\n```sh\nexport HTTP_PROXY=http://maxime.example.com:8080\n```\nAussi surprenant que cela puisse paraître, cela dépend. Dans certains cas, le proxy d'Alice est utilisé, dans d'autres cas, c'est celui de Maxime. Nous y reviendrons plus loin dans cet article. \n\nQue se passe-t-il si vous souhaitez définir des exceptions ? Par exemple, admettons que vous souhaitez utiliser un serveur proxy pour tout, sauf pour `internal.example.com` et `internal2.example.com`. C'est ici que la variable `no_proxy` entre en jeu. Vous paramétrez alors `no_proxy` comme suit : \n\n```sh\nexport no_proxy=internal.example.com,internal2.example.com\n```\n\nEt si vous souhaitez exclure certaines adresses IP ? Faut-il utiliser des astérisques ou des caractères génériques ? Ou bien utiliser des blocs CIDR (comme `192.168.1.1/32`) ? Même réponse : cela dépend.\n\n## L'évolution des variables proxy et no_proxy\n\nEn 1994, la plupart des clients Web utilisaient la bibliothèque logicielle `libwww` du CERN, qui prenait en charge les variables d'environnement `http_proxy` et `no_proxy`. `libwww` utilisait uniquement la forme en minuscules de `http_proxy` et [la syntaxe de `no_proxy` était simple](https://github.com/w3c/libwww/blob/8678b3dcb4191065ca39caea54bb1beba809a617/Library/src/HTAccess.c#L234-L239) : \n\n```\nno_proxy is a comma- or space-separated list of machine\nor domain names, with optional :port part.  If no :port\npart is present, it applies to all ports on that domain.\n\nExample:\n\t\tno_proxy=\"cern.ch,some.domain:8001\"\n```\n\nDe nouveaux clients sont apparus, ajoutant leurs propres implémentations HTTP sans les relier à `libwww`. En janvier 1996, Hrvoje Niksic publie `geturl`, le prédécesseur de ce qu'on connaît aujourd'hui sous le nom de `wget`. Un mois plus tard, [`geturl` prend en charge `http_proxy` dans la version v1.1](https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/www/utilities/wget/old-versions/). En mai 1996, `geturl` v1.3 ajoute la prise en charge de `no_proxy`. Tout comme `libwww`, `geturl` n'accepte que les minuscules. \n\nEn janvier 1998, Daniel Stenberg publie `curl` v5.1, [qui prend en charge les variables `http_proxy` et `no_proxy`](https://github.com/curl/curl/blob/ae1912cb0d494b48d514d937826c9fe83ec96c4d/CHANGES#L929-L944). De plus, `curl` accepte désormais les majuscules, `HTTP_PROXY` et `NO_PROXY`.\n\n__Nota Bene :__ en mars 2009, [`curl` v7.19.4](https://github.com/curl/curl/releases/tag/curl-7_19_4) abandonne la prise en compte de la forme en majuscules de `HTTP_PROXY` [en raison de problèmes de sécurité](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2261). Cependant, même si `curl` n'accepte plus `HTTP_PROXY`, `HTTPS_PROXY` fonctionne toujours.\n\n## Gestion des variables du serveur proxy\n\nSuite aux [recherches de notre collègue Nourdin el Bacha](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/2991), nous comprenons que la gestion des variables du serveur proxy varie en fonction du langage ou de l'outil utilisé. \n\n### http_proxy et https_proxy\n\nDans ce tableau, chaque ligne représente une variable, et chaque colonne correspond à l'outil (comme `curl`) ou au langage (comme `Ruby`) auquel elle s'applique : \n\n|                 | curl      | wget           | Ruby          | Python    | Go        |\n|-----------------|-----------|----------------|---------------|-----------|-----------|\n| `http_proxy`    | Oui       | Oui            | Oui           | Oui       | Oui        |\n| `HTTP_PROXY`    | Non        | Non           | Oui ([Mise en garde](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1519)) | Oui (si `REQUEST_METHOD` n'est pas dans env)       | Oui       |\n| `https_proxy`   | Oui       | Oui            | Oui           | Oui       | Oui       |\n| `HTTPS_PROXY`   | Oui       | Non             | Oui           | Oui       | Oui       |\n| Casse de caractères | Minuscules | Minuscules uniquement | Minuscules     | Minuscules | Majuscules |\n| Sources       | [source](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2266) | [source](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1222-L1239) | [source](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1474-L1543) | [source](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2488-L2517) | [source](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L82-L97) |\n\nNotez que `http_proxy` et `https_proxy` sont toujours pris en charge, alors que `HTTP_PROXY` ne l'est pas. Python (via `urllib`) ne facilite pas les choses : `HTTP_PROXY` peut être utilisé [tant que `REQUEST_METHOD` n'est pas défini dans l'environnement](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2504-L2508).\n\nLes variables d'environnement sont normalement définies en majuscules, mais puisque `http_proxy` est apparu en premier, il est devenu de fait la norme. En cas de doute, optez pour la forme en minuscules, car elle est universellement prise en charge.\n\nContrairement à la plupart des implémentations, Go essaie d'abord la forme en majuscules avant revenir à la version en minuscules. Nous verrons plus tard pourquoi cela a causé du tort à notre client GitLab. \n\n### no_proxy\n\nCertains utilisateurs ont signalé le [manque d'indications sur `no_proxy`](https://github.com/curl/curl/issues/1208). Puisque `no_proxy` définit une liste d'exceptions, des questions sur son fonctionnement se posent. \n\nPar exemple, vous configurez votre `no_proxy` comme suit : \n\n```sh\nexport no_proxy=example.com\n```\n\nEst-ce que cela signifie que le domaine doit être une correspondance exacte ou que `subdomain.example.com` corresponde aussi à cette configuration ? \n\nLe tableau suivant présente les différentes configurations. Toutes les implémentations correspondent aux suffixes, comme le montre la ligne « `correspondance des suffixes` ».\n\n|                       | curl      | wget           | Ruby      | Python    | Go        |\n|-----------------------|-----------|----------------|-----------|-----------|-----------|\n| `no_proxy`            | Oui       | Oui          | Oui     | Oui      | Oui      |\n| `NO_PROXY`            | Oui       | Non             | Oui       | Oui       | Oui       |\n| Casse de caractères       | Minuscules | Minuscules uniquement | Minuscules | Minuscules | Majuscules |\n| Correspondance des suffixes ?     | Oui       | Oui            | Oui       | Oui       | Oui       |\n| Points initiaux `.` ?   | Oui       | Non             | Oui       | Oui       | Non        |\n| `*` fait correspondre tous les hôtes| Oui       | Non             | Non        | Oui       | Oui       |\n| Prise en charge des expressions régulières ?     | Non        | Non             | Non        | Non        | Non        |\n| Prise en charge des blocs CIDR ? | Non        | Non             | Oui       | Non        | Oui       |\n| Détection des adresses IP de bouclage ? | Non        | Non             | Non        | Non        | Oui       |\n| Sources            | [source](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2152-L2206) | [source](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1266-L1274) | [source](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1545-L1554) | [source](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2519-L2551)| [source](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L170-L206) |\n\nCependant, si `no_proxy` est précédé d'un `.`, cela implique des changements. \n\nPar exemple, `curl` et `wget` se comportent différemment. `curl` supprime le `.` dans la configuration pour se coller au suffixe du domaine. Il contourne ainsi le proxy :\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com curl https://gitlab.com\n\u003Chtml>\u003Cbody>You are being \u003Ca href=\"https://about.gitlab.com/\">redirected\u003C/a>.\u003C/body>\u003C/html>\n```\n\nNéanmoins, `wget` ne supprime pas le `.` et utilise la correspondance exacte avec le nom d'hôte. Par conséquent, `wget` essaie d'utiliser un proxy si un domaine de premier niveau est utilisé : \n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com wget https://gitlab.com\nResolving non.existent (non.existent)... failed: Name or service not known.\nwget: unable to resolve host address 'non.existent'\n```\n\nToutes les implémentations ne prennent pas en charge les expressions régulières (regex). Utiliser des regex peut compliquer la configuration puisqu'elles peuvent prendre différentes variantes (comme PCRE ou POSIX). L'utilisation d'expressions régulières entraîne également de potentielles failles de sécurité et de performance. \n\nConfigurer `no_proxy` avec un astérisque (`*`) peut désactiver l'utilisation de proxy pour toutes les adresses, bien que ce principe ne soit pas appliqué tout le temps. \n\nAu moment de décider de l'utilisation d'un proxy, aucune implémentation n'effectue de recherche DNS pour résoudre un nom d'hôte en adresse IP. Il est préférable d'éviter de spécifier les adresses IP dans `no_proxy` à moins que le client ne les utilise explicitement. \n\nIl en va de même pour les blocs CIDR, tels que `18.240.0.1/24`. Ces blocs ne fonctionnent que si la requête est faite directement à une adresse IP. Seuls les environnements de développement Go et Ruby permettent l'utilisation de blocs CIDR. Go désactive même automatiquement l'utilisation d'un proxy si une adresse IP de bouclage est détectée, ce qui n'est pas le cas dans d'autres implémentations.\n\n## Pourquoi les paramètres du proxy sont-ils importants ?\n\nSi votre application est codée en plusieurs langages et doit fonctionner avec un pare-feu avec un serveur proxy, il est important de faire attention à ces différences. \n\nPar exemple, GitLab est composé d'éléments codés en Ruby et d'autres en Go. Un de nos clients a configuré son proxy de la façon suivante : \n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\n```\n\nIl a ensuite signalé un problème avec GitLab : \n- Un `git push` à partir de la ligne de commande a fonctionné.\n- Les modifications Git effectuées à partir de l'interface Web ont échoué.\n\nNos ingénieurs ont découvert qu'un problème de configuration de [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") entraînait le maintien de valeurs obsolètes. L'environnement ressemblait à : \n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\nno_proxy: .wrong-company.com\n```\n\nLes irrégularités entre `no_proxy` et `NO_PROXY` ont entraîné des alertes. Supprimer l'entrée incorrecte ou uniformiser les variables auraient pu résoudre le problème. Observons ce qu'il s'est passé. \n\nRappelez-vous que : \n- Ruby priorise `no_proxy`.\n- Go priorise `NO_PROXY`.\n\nPar conséquent, les services codées en Go, comme [GitLab Workhorse](https://docs.gitlab.com/ee/development/workhorse/), ont un bon paramétrage du proxy. Un `git push` depuis la ligne de commande a fonctionné car les services Go gèrent cette activité : \n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant W as Workhorse\n    participant G as Gitaly\n    C->>W: git push\n    W->>G: gRPC: PostReceivePack\n    G->>W: OK\n    W->>C: OK\n```\n\nL'appel gRPC de l'étape 2 n'a jamais tenté d'utiliser le proxy car `no_proxy` a été configuré correctement pour se connecter directement à Gitaly.\n\nCependant, lorsqu'un utilisateur effectue une modification dans l'interface utilisateur, Gitaly transmet la requête au service `gitaly-ruby`, qui est écrit en Ruby. `gitaly-ruby` effectue des modifications dans le dépôt et renvoie un rapport via un appel gRPC à son processus parent. Malheureusement, comme le montre l'étape 4 ci-dessous, l'étape de reporting n'a pas eu lieu :\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>P: CONNECT\n    P->>GR: FAIL\n```\n\nPuisque gRPC utilise HTTP/2 comme mode de transport, `gitaly-ruby` tente de se connecter au proxy (il était connecté à une configuration erronée de `no_proxy`). Le proxy a immédiatement rejeté la requête HTTP, ce qui a entraîné l'erreur du push sur l'interface Web. \n\nAprès la suppression des minuscules `no_proxy` de l'environnement, les pushs depuis l'interface utilisateur ont fonctionné comme prévu. `gitaly-ruby` s'est connecté au processus parent Gitaly. L'étape 4 a donc fonctionné comme suit : \n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>G: OK\n    G->>R: OK\n    R->>C: OK\n```\n\n#### Pourquoi faut-il privilégier un proxy HTTPS ?\n\nNotez que le client a défini `HTTPS_PROXY` sur un proxy HTTP non crypté : `http://` est préféré à `https://`. Bien que ce ne soit pas idéal en termes de sécurité, certaines équipes de développement utilisent cette méthode pour éviter les problèmes de certificats TLS (et donc, des problèmes de connexion pour les utilisateurs finaux). \n\nSi un proxy HTTPS avait été spécifié, nous n’aurions pas rencontré ce problème. Lorsqu'un proxy HTTPS est utilisé, gRPC ignore ce paramètre car [les proxy HTTPS ne sont pas pris en charge](https://github.com/grpc/grpc/issues/20939).\n\n## Le plus petit dénominateur commun\n\nPersonne ne devrait définir des valeurs irrégulières avec des paramètres de proxy en minuscules et en majuscules. Cependant, si vous devez gérer une stack dans plusieurs langages, vous pourrez configurer les paramètres de proxy HTTP selon le plus petit dénominateur commun.\n\n### `http_proxy` et `https_proxy`\n\n`HTTP_PROXY` n'est pas toujours pris en charge ou recommandé. Préférez toujours le format en minuscules et si vous devez absolument utiliser la version en majuscules, vérifiez qu'elles partagent la même valeur.\n\n### `no_proxy`\n\n1. Adoptez le format en minuscules.\n2. Utilisez les valeurs `hostname:port` séparées par des virgules.\n3. Les adresses IP sont acceptables, mais les noms d'hôtes ne sont pas résolus.\n4. Les suffixes correspondent toujours (`example.com` correspondra à `test.example.com`).\n5. Évitez d'utiliser le point initial (`.`) pour les domaines de premier niveau.\n6. Veillez à ne pas utiliser de correspondances de blocs CIDR. Seuls Go et Ruby les prennent en charge. \n\n## Standardiser `no_proxy`\n\nConnaître le plus petit dénominateur commun aide à éviter des problèmes si ces définitions sont copiées pour différents clients Web. Mais est-ce que `no_proxy` et les autres configurations de proxy requièrent une version standard documentée plutôt qu'une convention ad hoc ? \n\nVoici quelques points qui peuvent vous aider : \n\n1. Préférez le format en minuscules aux variantes en majuscules (`http_proxy` devrait être utilisé avant `HTTP_PROXY`).\n2. Utilisez des valeurs `hostname:port` séparées par des virgules (chaque valeur peut inclure des espaces facultatifs.). \n3. Ne faites pas de recherche DNS et évitez les expressions régulières (regex). \n4. Appliquez `*` pour faire correspondre tous les hôtes.\n5. Supprimez les points initiaux (`.`) et faites correspondre les suffixes de domaine. \n6. Prenez en charge la correspondance des blocs CIDR. \n7. Évitez les suppositions sur des adresses IP spéciales (comme les adresses de bouclage dans `no_proxy`).\n\n## Conclusion\n\nPlus de 30 ans se sont écoulés depuis la sortie du premier serveur proxy Web. Depuis, les principes fondamentaux pour configurer un client Web grâce à des variables n'ont pas vraiment changé. Néanmoins, certaines subtilités ont vu le jour. \n\nÀ travers un cas pratique, vous avez découvert qu'une définition erronée des variables `no_proxy` et `NO_PROXY` a entraîné des heures de travail pour résoudre le problème, en raison de différences d'acceptation de configuration entre Ruby et Go. \n\nEn mettant en évidence ces différences, nous espérons vous éviter de futurs problèmes dans votre stack de production. Et qui sait, nous verrons peut-être voir le jour une standardisation au niveau des chargés de maintenance des clients Web. \n",[9,728,729,730],"careers","user stories","startups",{"slug":732,"featured":6,"template":684},"we-need-to-talk-no-proxy","content:fr-fr:blog:we-need-to-talk-no-proxy.yml","We Need To Talk No Proxy","fr-fr/blog/we-need-to-talk-no-proxy.yml","fr-fr/blog/we-need-to-talk-no-proxy",{"_path":738,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":739,"content":745,"config":753,"_id":755,"_type":13,"title":756,"_source":15,"_file":757,"_stem":758,"_extension":18},"/fr-fr/blog/what-is-a-hackathon",{"title":740,"description":741,"ogTitle":740,"ogDescription":741,"noIndex":6,"ogImage":742,"ogUrl":743,"ogSiteName":720,"ogType":721,"canonicalUrls":743,"schema":744},"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":740,"description":741,"authors":746,"heroImage":742,"date":748,"body":749,"category":674,"tags":750,"updatedDate":752},[747],"GitLab France Team","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",[9,751,676],"collaboration","2025-03-20",{"slug":754,"featured":6,"template":684},"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":760,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":766,"config":774,"_id":776,"_type":13,"title":777,"_source":15,"_file":778,"_stem":779,"_extension":18},"/fr-fr/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":762,"description":763,"ogTitle":762,"ogDescription":764,"ogImage":765},"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":767,"title":762,"description":768,"heroImage":765,"authors":769,"date":771,"category":674,"tags":772},"Le projet Git a récemment publié la [version 2.50.0 de\nGit](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u).\nDécouvrons les points forts de cette nouvelle version, qui comprend les\ncontributions 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 optimisé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 d'évolutivité, 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 une 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 à assimiler.\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:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN\n\n```\n\n\nGit 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 la sortie de « correctif » 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 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\\\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 permettant d'alimenter des informations « brutes » sur les paires de fichiers et de générer la sortie de correctifs correspondants.\n\n\nAvec la version 2.50.0, Git dispose d’une nouvelle commande intégrée `git-diff-pairs(1)`, qui prend en charge les informations de paires de fichiers au format « brut » en tant qu'entrée sur stdin pour déterminer avec précision les correctifs à 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 correctif, 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\\\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 stdin. La mise à jour des références par 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$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n# Print out the commit IDs\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Attempt to create a new reference and update existing reference in transaction.\n\n# Update is expected to fail because the specified old object ID doesn’t match.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# The \"bar\" reference was not created.\n\n$ git switch bar\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. Cela ne remet pas en cause les gains de productivité obtenus grâce aux 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\nCela permet 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$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# The \"bar\" reference was created even though the update to \"foo\" was rejected.\n\n$ git switch bar\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 correctifs 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$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n# Create an unreachable object.\n\n$ git commit --amend --no-edit\n\n# Use git-cat-file(1) to print info about all objects including unreachable objects.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\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 correspondent à 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\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\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\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nCette approche facilite le traitement par Git, mais également la recherche dans les grands dépôts contenant de nombreux objets. 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 de manière considérable 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\nTime (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]\n\nRange (min … max): 73.936 s … 89.690 s 10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\nTime (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]\n\nRange (min … max): 18.2 ms … 23.6 ms 127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\nTime (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]\n\nRange (min … max): 1.541 s … 1.566 s 10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\nTime (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]\n\nRange (min … max): 11.114 s … 11.245 s 10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n\nTime (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]\n\nRange (min … max): 62.836 s … 73.618 s 10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\nTime (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]\n\nRange (min … max): 12.960 s … 13.199 s 10 runs\n\nSummary\n\ngit cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n\n74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n\n538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n\n627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n\n3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\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 de paquets\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 l'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 le paquet. L'implémentation a utilisé une boucle `for` imbriquée pour itérer et comparer toutes les références répertoriées, ce qui a entraîné une complexité temporelle O(N^2). Cette façon de procéder n'est pas adaptée en cas d'augmentation du nombre de références dans un dépôt.\n\n\nDans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par une structure de données de mappage, 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'un paquet avec un dépôt contenant 100 000 références :\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n\nTime (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]\n\nRange (min … max): 14.237 s … 14.920 s 10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n\nTime (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]\n\nRange (min … max): 2.364 s … 2.425 s 10 runs\n\nSummary\n\nbundle (refcount = 100000, revision = HEAD) ran\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 de paquets\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 les paquets dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge un paquet, les références sous `refs/heads/*` et les objets qui les accompagnent sont copiés du paquet dans le dépôt. Un paquet 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 l'URI du paquet 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 le paquet téléchargé 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\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\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 du paquet, 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 correctifs 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.",[770],"Justin Tobler","2025-07-02",[9,773,676],"git",{"featured":6,"template":684,"slug":775},"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":781,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":782,"content":787,"config":793,"_id":795,"_type":13,"title":796,"_source":15,"_file":797,"_stem":798,"_extension":18},"/fr-fr/blog/whats-new-in-git-2-45-0",{"title":783,"description":784,"ogTitle":783,"ogDescription":784,"noIndex":6,"ogImage":718,"ogUrl":785,"ogSiteName":720,"ogType":721,"canonicalUrls":785,"schema":786},"Nouveautés de Git 2.45.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-45-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.45.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }",{"title":783,"description":784,"authors":788,"heroImage":718,"date":790,"body":791,"category":674,"tags":792},[789],"Patrick Steinhardt","2024-04-30","Le projet Git a récemment publié la [version 2.45.0 de\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/). Jetons un\ncoup d'œil aux points forts de cette version, comprenant des contributions\nde l'équipe Git de GitLab et de la communauté Git au sens large.\n\n\n## Reftables : un nouveau backend pour le stockage des références\n\n\nChaque dépôt Git doit suivre deux structures de données de base :\n\n- Le graphique qui stocke les données de vos fichiers, la structure de\nrépertoires, les messages de commit et les tags.\n\n- Les références qui sont des pointeurs dans ce graphique pour associer des\nobjets spécifiques à un nom plus accessible. Par exemple, une branche est\nune référence dont le nom commence par un préfixe `refs/heads/`. \n\n\nLe format sur disque de stockage des références dans un dépôt est resté\nlargement inchangé depuis la création de Git et est appelé le format «\nfichiers ». Chaque fois que vous créez une référence, Git crée une «\nréférence libre » qui correspond à un fichier ordinaire dans votre dépôt Git\ndont le chemin d'accès correspond au nom de la référence.\n\n\nPar exemple : \n\n\n```shell\n\n$ git init .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n# Updating a reference will cause Git to create a \"loose ref\". This loose\nref is\n\n# a simple file which contains the object ID of the commit.\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) c70f266] Initial commit\n\n$ cat .git/refs/heads/main\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n# Creating a second reference will end up with a second loose ref.\n\n$ git branch feature\n\n$ cat .git/refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946\n\n$ tree .git/refs\n\n.git/refs/\n\n├── heads\n\n│   ├── feature\n\n│   └── main\n\n└── tags\n\n\n3 directories, 2 files\n\n```\n\nIl arrive que Git empaquette ces références dans un format de fichier «\nempaqueté » pour que la recherche de références soit plus efficace. Par\nexemple :\n\n\n```shell\n\n# Packing references will create \"packed\" references, which are a sorted\nlist of\n\n# references. The loose reference does not exist anymore.\n\n$ git pack-refs --all\n\n$ cat .git/refs/heads/main\n\ncat: .git/refs/heads/main: No such file or directory\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n```\n\n\nBien qu'il soit relativement simple, ce format comporte certaines limites :\n\n\n- Dans les mono repos contenant de nombreuses références, nous avons\ncommencé à nous heurter à des problèmes d'évolutivité. La suppression des\nréférences est particulièrement inefficace car l'ensemble du fichier «\npacked-refs » doit être réécrit pour supprimer la référence supprimée. Dans\nnos plus grands dépôts, cela peut entraîner la réécriture de plusieurs\ngigaoctets de données à chaque suppression de référence. \n\n- Il est impossible d'effectuer une lecture atomique des références sans\nbloquer les rédacteurs simultanés, car il est nécessaire de lire plusieurs\nfichiers pour comprendre toutes les références.\n\n- Il est impossible d'effectuer une écriture atomique, car elle nécessite la\ncréation ou la mise à jour de plusieurs fichiers, ce qui est impossible en\nune seule étape. \n\n- La maintenance des références ne s'adapte pas bien, parce que vous devez\nréécrire le fichier « packed-refs » entièrement. \n\n- Étant donné que les références libres utilisent le chemin d'accès du\nsystème de fichiers comme nom, elles sont soumises à un comportement\nspécifique au système de fichiers. Par exemple, les systèmes de fichiers\ninsensibles à la casse ne peuvent pas stocker des références pour lesquelles\nseule la casse diffère.\n\n\nPour résoudre ces problèmes, Git v2.45.0 introduit un nouveau backend «\nreftable », qui utilise un nouveau format binaire pour stocker les\nréférences. Ce nouveau backend est en développement depuis très longtemps.\nIl a été initialement proposé par [Shawn\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/) en juillet\n2017 et a été mis en place pour la première fois dans\n[JGit](https://www.eclipse.org/jgit/ \"JGit\"). Il est largement utilisé par\nle [projet Gerrit](https://www.gerritcodereview.com/ \"Projet Gerrit\"). En\n2021, [Han-Wen Nienhuys](https://hanwen.home.xs4all.nl/) a intégré la\nbibliothèque dans Git, ce qui lui permet de lire et d'écrire le format\nreftable. \n\n\nLe nouveau backend « reftable » que nous avons introduit dans Git v2.45.0\nrassemble enfin la bibliothèque reftable et Git de sorte qu'il est possible\nd'utiliser le nouveau format comme backend de stockage dans vos dépôts Git. \n\n\nEn supposant que vous exécutez au moins la version 2.45.0 de Git, vous\npouvez créer de nouveaux dépôts au format « reftable » en basculant\n`--ref-format=reftable` sur `git-init(1)` ou `git-clone(1)`. \n\n\nPar exemple :\n\n\n```shell\n\n$ git init --ref-format=reftable .\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/tables.list\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n$ find -type f .git/reftable/\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n.git/reftable/tables.list\n\n```\n\n\nComme vous pouvez le constater, les références sont maintenant stockées dans\n`.git/reftable` au lieu du répertoire `.git/refs.` Les références et les\njournaux de référence (ou « reflogs ») sont stockés dans des « tables », qui\nsont les fichiers se terminant par `.ref`, tandis que le fichier\n`tables.list` contient la liste de toutes les tables actuellement actives. \n\n\nLe backend « reftable » est censé remplacer le backend « fichiers ». Par\nconséquent, du point de vue de l'utilisateur, tout devrait fonctionner de la\nmême manière. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\"). Le mérite revient également à Shawn\nPearce en tant qu'inventeur original du format et à Han-Wen Nienhuys en tant\nqu'auteur de la bibliothèque reftable.\n\n\n## De meilleurs outils pour les références \n\n\nAlors que le format « reftable » résout de nombreux problèmes existants, il\nen introduit également de nouveaux. L'un des problèmes les plus importants\nétant l'accessibilité des données qu'il contient. \n\n\nAvec le backend « fichiers », vous pouvez, dans le pire des cas, utiliser\nvos outils Unix habituels pour inspecter l'état des références. Les\nréférences « empaquetées » et « libres » contiennent toutes deux des données\nlisibles par l'homme et faciles à interpréter. Ce qui est différent avec le\nformat « reftable », qui est un format binaire. Par conséquent, Git doit\nfournir tous les outils nécessaires pour extraire les données du nouveau\nformat « reftable ».\n\n\n### Répertorier toutes les références\n\n\nLe premier problème que nous avons rencontré est qu'il est fondamentalement\nimpossible de connaître toutes les références connues d'un dépôt. Cela\npeut-être quelque peu déroutant au début : comment est-il possible de créer\net modifier des références via Git, qui ne peut pas énumérer de manière\nexhaustive toutes les références dont il a connaissance ?\n\n\nEn effet, le backend « fichiers » en est incapable. Alors qu'il peut\nrépertorier de manière évidente toutes les références « habituelles » qui\ncommencent par le préfixe `refs/`, Git utilise également des [pseudo\nrefs](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpseudorefapseudoref\n\"Les pseudo refs de Git\"). Ces fichiers se trouvent directement à la racine\ndu répertoire Git et seraient des fichiers comme, par exemple,\n`.git/MERGE_HEAD`. Le problème ici est que ces pseudo refs se trouvent à\ncôté d'autres fichiers que Git stocke comme, par exemple, `.git/config`.\n\n\nAlors que certaines pseudo refs sont bien connues et donc faciles à\nidentifier, il n'y a en théorie aucune limite aux références que Git peut\nécrire. Rien ne vous empêche de créer une référence appelée « foobar ».\n\n\nPar exemple : \n\n\n```shell\n\n$ git update-ref foobar HEAD\n\n$ cat .git/foobar\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n```\n\n\nMaintenant, le problème du backend « fichiers » est qu'il ne peut énumérer\nles références qu'en parcourant les répertoires. Donc, pour déterminer si\n`.git/foobar` est effectivement une référence, Git devrait ouvrir le fichier\net vérifier s'il est formaté ou non comme une référence. \n\n\nD'autre part, le backend « reftable » connaît de manière évidente toutes les\nréférences qu'il contient : elles sont encodées dans ses structures de\ndonnées, il lui suffit donc de décoder ces références et de les renvoyer.\nMais en raison des restrictions du backend « fichiers », il n'existe aucun\noutil qui vous permettrait de connaître toutes les références existantes. \n\n\nPour résoudre le problème, nous avons intégré un nouvel élément à\n`git-for-each-ref(1)` appelé `--include-root-refs`, ce qui lui permettra de\nrépertorier également toutes les références qui existent à la racine de la\nhiérarchie de nommage des références.\n\n\nPar exemple : \n\n\n```shell\n\n$ git for-each-ref --include-root-refs\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n```\n\n\nPour le backend « fichiers », ce nouvel élément est géré au mieux et nous y\nincluons toutes les références qui correspondent à un nom de pseudo ref\nconnu. Pour le backend « reftable », nous pouvons simplement lister toutes\nles références qui lui sont connues. \n\n\nCe projet a été mené par [Karthik Nayak](https://gitlab.com/knayakgl \"Profil\nGitLab de Karthik Nayak\").\n\n\n### Répertorier tous les reflogs \n\n\nChaque fois que vous mettez à jour des branches, Git, par défaut, suit ces\nmises à jour de branche dans un reflog. Ce reflog vous permet de rétablir\nles modifications apportées à cette branche au cas où vous auriez effectué\nune modification involontaire. \n\n\nAvec le backend « fichiers », ces journaux sont stockés dans votre\nrépertoire `.git/logs` :\n\n\n```shell\n\n$ find -type f .git/logs/\n\n.git/logs/HEAD\n\n.git/logs/refs/heads/main\n\n```\n\n\nLister les fichiers dans ce répertoire est le seul moyen pour vous de savoir\nquelles références ont un reflog en premier lieu. C'est un problème pour le\nbackend « reftable », qui stocke ces journaux avec les références. Par\nconséquent, il n'existe plus aucun moyen pour vous de savoir quels reflogs\nexistent dans le dépôt lorsque vous utilisez le format « reftable ». \n\n\nIl ne s'agit pas d'une faille imputable au format « reftable », mais d'une\nomission dans les outils fournis par Git. Pour y remédier, nous avons\nintroduit une nouvelle sous-commande `list` à `git-reflog(1)` permettant de\nrépertorier tous les reflogs existants :\n\n\n```shell\n\n$ git reflog list\n\nHEAD\n\nrefs/heads/main\n\n```\n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n### Un empaquetage plus efficace des références \n\n\nPour rester efficaces, les dépôts Git nécessitent une maintenance régulière.\nHabituellement, cette maintenance est déclenchée par diverses commandes Git\nqui écrivent des données dans les dépôts Git en exécutant `git maintenance\nrun --auto`. Cette commande optimise uniquement les structures de données\nqui doivent être optimisées afin que Git ne gaspille pas de ressources de\ncalcul.\n\n\nUne structure de données optimisée par la maintenance de Git constitue la\nbase de données de référence, obtenue en exécutant `git pack-refs --all`.\nPour le backend « fichiers », cela signifie que toutes les références sont à\nnouveau regroupées dans le fichier « packed-refs » et que les références\nlibres sont supprimées, tandis que pour le backend « reftable », toutes les\ntables sont fusionnées en une seule table. \n\n\nPour le backend « fichiers », nous ne pouvons pas faire beaucoup mieux.\nÉtant donné que nous devons de toute façon réécrire l'ensemble du fichier «\npacked-refs », il est logique que nous souhaitions regrouper toutes les\nréférences libres. \n\n\nMais pour le backend « reftable », cette démarche est sous-optimale, car le\nbackend « reftable » s'optimise automatiquement. Chaque fois que Git ajoute\nune nouvelle table au backend « reftable », il effectue un compactage\nautomatique et fusionne les tables si nécessaire. Par conséquent, la base de\ndonnées de référence doit toujours être dans un état optimisé et la fusion\nde toutes les tables s'avère donc un effort inutile.\n\n\nDans la version 2.45.0 de Git, nous avons donc introduit un nouveau mode\n`git pack-refs --auto`, qui demande au backend de référence de s'optimiser\nsi nécessaire. Alors que le backend « fichiers » continue de fonctionner de\nla même manière même lorsque l'indicateur `--auto` est défini, le backend «\nreftable » utilise les mêmes heuristiques que celles qu'il utilise pour son\nauto-compactage. Dans la pratique, cela ne devrait pas poser de problème\ndans la plupart des cas. \n\n\nDe plus, `git maintenance run --auto` a été adapté pour transmettre\nl'indicateur `-tauto` à `git-pack-refs(1)` pour utiliser ce nouveau mode par\ndéfaut. \n\n\nCe projet a été mené par [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\"Profil GitLab de Patrick Steinhardt\").\n\n\n## En conclusion \n\n\nCet article de blog met l'accent sur le [nouveau backend « reftable\n»](https://about.gitlab.com/fr-fr/blog/a-beginners-guide-to-the-git-reftable-format/\n\"Format reftable de Git \"), qui nous permet de mieux évoluer dans les dépôts\nvolumineux comprenant de multiples références, ainsi que sur les outils\nconnexes que nous avons introduits en parallèle pour le faire fonctionner\ncorrectement. Cette version de Git par la communauté Git, au sens large, a\nbien entendu introduit diverses améliorations de performances, des\ncorrections de bugs et des fonctionnalités plus petites. Vous pouvez en\napprendre davantage à ce sujet dans [l'annonce officielle du projet\nGit](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Annonce\nofficielle du projet Git\").\n",[773,9],{"slug":794,"featured":6,"template":684},"whats-new-in-git-2-45-0","content:fr-fr:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","fr-fr/blog/whats-new-in-git-2-45-0.yml","fr-fr/blog/whats-new-in-git-2-45-0",{"_path":800,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":801,"content":806,"config":812,"_id":814,"_type":13,"title":815,"_source":15,"_file":816,"_stem":817,"_extension":18},"/fr-fr/blog/whats-new-in-git-2-46-0",{"title":802,"description":784,"ogTitle":802,"ogDescription":784,"noIndex":6,"ogImage":803,"ogUrl":804,"ogSiteName":720,"ogType":721,"canonicalUrls":804,"schema":805},"Nouveautés de Git 2.46.0","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nouveautés de Git 2.46.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }",{"title":802,"description":784,"authors":807,"heroImage":803,"date":808,"body":809,"category":674,"tags":810,"updatedDate":811},[770],"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.",[773,676,9],"2024-08-15",{"slug":813,"featured":90,"template":684},"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":819,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":820,"content":825,"config":831,"_id":833,"_type":13,"title":834,"_source":15,"_file":835,"_stem":836,"_extension":18},"/fr-fr/blog/whats-new-in-git-2-47-0",{"title":821,"description":784,"ogTitle":821,"ogDescription":784,"noIndex":6,"ogImage":822,"ogUrl":823,"ogSiteName":720,"ogType":721,"canonicalUrls":823,"schema":824},"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":821,"description":784,"authors":826,"heroImage":822,"date":827,"body":828,"category":674,"tags":829,"updatedDate":830},[770],"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/)",[773,676,9],"2024-10-21",{"slug":832,"featured":90,"template":684},"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":838,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":839,"content":844,"config":851,"_id":853,"_type":13,"title":854,"_source":15,"_file":855,"_stem":856,"_extension":18},"/fr-fr/blog/whats-new-in-git-2-48-0",{"title":840,"description":841,"ogTitle":840,"ogDescription":841,"noIndex":6,"ogImage":822,"ogUrl":842,"ogSiteName":720,"ogType":721,"canonicalUrls":842,"schema":843},"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":840,"description":841,"authors":845,"heroImage":822,"date":847,"body":848,"category":674,"tags":849,"updatedDate":850},[846],"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",[773,676,9],"2025-01-20",{"slug":852,"featured":90,"template":684},"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":858,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":859,"content":865,"config":872,"_id":874,"_type":13,"title":875,"_source":15,"_file":876,"_stem":877,"_extension":18},"/fr-fr/blog/whats-new-in-git-2-49-0",{"title":860,"description":861,"ogTitle":860,"ogDescription":861,"noIndex":6,"ogImage":862,"ogUrl":863,"ogSiteName":720,"ogType":721,"canonicalUrls":863,"schema":864},"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":860,"description":861,"authors":866,"heroImage":862,"date":868,"body":869,"category":674,"tags":870,"updatedDate":871},[867],"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/)",[9,676,773],"2025-04-10",{"slug":873,"featured":90,"template":684},"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":879,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":886,"config":894,"_id":896,"_type":13,"title":897,"_source":15,"_file":898,"_stem":899,"_extension":18},"/fr-fr/blog/how-gitlab-empowers-translators-with-more-context",{"title":881,"description":882,"ogTitle":881,"ogDescription":882,"noIndex":6,"ogImage":883,"ogUrl":884,"ogSiteName":720,"ogType":721,"canonicalUrls":884,"schema":885},"Comment GitLab facilite la compréhension du contexte pour les traducteurs","Découvrez notre nouvelle fonctionnalité d'amélioration du contexte de traduction et rejoignez notre communauté de traducteurs.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment GitLab facilite la compréhension du contexte pour les traducteurs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }",{"title":881,"description":882,"authors":887,"heroImage":883,"date":889,"body":890,"category":674,"tags":891,"updatedDate":893},[888],"Oleksandr Pysaryuk","2024-12-09","Notre communauté mondiale s'investit sans relâche pour traduire GitLab. Les traducteurs et relecteurs utilisent [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html) pour rendre notre produit disponible dans 78 langues. La communauté de traduction GitLab est composée de traducteurs et relecteurs bénévoles, de professionnels qui utilisent GitLab et même d'[étudiants qui contribuent dans le cadre de projets académiques](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### Le modèle open core de GitLab pour la traduction\n\nLa collaboration entre les membres de la communauté a beau porter ses fruits, les traducteurs se heurtent souvent à un défi majeur : comprendre le contexte du texte qu'ils ont sous les yeux.\n\nBien traduire, ce n'est pas seulement remplacer un mot par un autre dans une autre langue. C'est aussi préserver le sens, l'intention et la clarté dans la langue cible. La traduction de logiciels nécessite une combinaison unique de compétences. Les bons traducteurs se spécialisent généralement dans plusieurs domaines linguistiques et maîtrisent également le domaine technique du produit lui-même. \n\nIls effectuent de nombreuses tâches adjacentes à la traduction, telles que :\n* assurer l'exactitude et la cohérence de la terminologie technique\n* ajouter des termes au glossaire pour de nouveaux concepts\n* respecter le style et le ton\n* appliquer correctement les [règles de pluralisation CLDR](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html) complexes\n* comprendre la traductibilité des messages composites et fournir des retours pour améliorer la source afin de faciliter sa localisation\n\nLes traducteurs consacrent une grande partie de leur temps à analyser le contexte, à poser des questions et à consulter la [documentation produit de GitLab](https://docs.gitlab.com/). Sans contexte approprié, même des phrases simples peuvent être mal traduites, ce qui peut dérouter les utilisateurs ou perturber leurs workflows. [GitLab se distingue par son modèle open core](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/) qui permet aux traducteurs d'accéder au contexte de développement du produit directement à la source, dans la plupart des cas. Cette transparence leur permet d'être de véritables [co-créateurs du produit GitLab](https://handbook.gitlab.com/handbook/company/mission/#mission) et de contribuer activement à son amélioration continue.\n\n### Notre nouvelle fonctionnalité d'amélioration du contexte\n\nPour répondre à ces besoins et offrir un contexte précis aux traducteurs, GitLab a développé une nouvelle fonctionnalité : nous [intégrons désormais un lien contextuel dans chaque chaîne traduisible](https://docs.gitlab.com/ee/development/i18n/translation.html#context). Il s'agit plus précisément d'un lien vers notre recherche globale dans le produit. Celui-ci permet aux traducteurs de trouver toutes les instances d'une chaîne dans le code base. Ils ont ainsi la possibilité de s'appuyer sur [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) pour retracer l'historique de chaque chaîne, de son emplacement actuel dans le code et des validations dans les merge requests jusqu'aux discussions de planification initiales.\n\nPrenons par exemple la traduction de **Rotate**. L'[espace de nommage](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) **AccessTokens|** suggère qu'il s'agit dans ce contexte de *jetons d'accès*. Cependant, sans contexte visuel supplémentaire sur la signification de **Rotate**, les traducteurs ne peuvent que s'interroger, deviner et fournir la meilleure hypothèse possible dans la langue cible.\n\nGrâce à la nouvelle fonctionnalité d'amélioration du contexte, les traducteurs peuvent désormais :\n\n1. Cliquer sur l'URL dans la section **See where this string is used in code**.\n\n![voir où cette chaîne est utilisée dans la section du code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Consulter le [résultat de la recherche dans le code](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true), puis cliquer sur l'icône **View blame** :\n\n![Écran affichant l'icône View blame](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Cliquer sur le lien pour accéder à la merge request pertinente ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)) :\n\n![Lien amenant à la merge request pertinente](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. Sur la page **Validations**, cliquer sur le lien vers la merge request pertinente :\n\n![Page Validations avec le lien](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Consulter l'enregistrement d'écran que le développeur a ajouté à la merge request :\n\n![enregistrement d'écran dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Poursuivre leur recherche en accédant :  \n   a. Au ticket associé [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) ou à l'epic parent [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563) :\n\n![ticket associé et epic parent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. À la [merge request associée qui met à jour la documentation du produit GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916) :\n\n![merge request associée pour mettre à jour la documentation du produit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nToutes ces étapes de recherche permettent aux traducteurs de mieux comprendre le concept technique de *rotation des jetons d'accès*, ainsi que les raisons pour lesquelles cette fonctionnalité a été ajoutée, son fonctionnement et le problème qu'elle résout.\n\nGrâce à cette piste de recherche approfondie, les traducteurs obtiennent autant de contexte que possible pour fournir une traduction technique précise et linguistiquement correcte du terme **Rotate**, en apparence simple.\n\nCette approche surpasse les aides à la traduction traditionnelles, comme les captures d'écran ou l'accès à l'interface utilisateur du produit. Les traducteurs peuvent désormais comprendre pleinement le contexte en :\n\n* le déduisant des informations à partir des chemins d'accès et des conventions de nommage dans le code\n* consultant les captures d'écran ou enregistrements vidéo ajoutés aux merge requests initiales\n* consultant les discussions initiales de planification et de développement\n* retraçant le processus de prise de décision en matière d'ingénierie, de rédaction et de gestion des produits qui a conduit à une formulation spécifique\n\n### Plus de fonctionnalités contextuelles alimentées par l'IA seront bientôt disponibles\n\nL'équipe Globalization & Localization de GitLab ne compte pas s'arrêter là. Nous développons [d'autres fonctionnalités d'amélioration du contexte](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), y compris des outils basés sur l'IA conçus pour aider les traducteurs à comprendre l'utilisation et le placement des chaînes. Notre objectif est de créer un système interactif dans lequel les traducteurs pourraient dialoguer avec un agent, poser des questions ou recevoir des réponses de manière proactive et immédiate, adaptées au code, sur l'emplacement et l'usage des chaînes dans l'interface utilisateur du produit.\n\n> ##### Rejoignez notre [communauté sur Crowdin](https://docs.gitlab.com/ee/development/i18n/) en tant que traducteur ou [relecteur](https://docs.gitlab.com/ee/development/i18n/#proofreading). Essayez nos nouvelles fonctionnalités contextuelles et dites-nous comment nous pouvons encore améliorer [l'expérience de traduction et notre produit](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[9,751,677,892],"contributors","2025-02-03",{"slug":895,"featured":6,"template":684},"how-gitlab-empowers-translators-with-more-context","content:fr-fr:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","fr-fr/blog/how-gitlab-empowers-translators-with-more-context.yml","fr-fr/blog/how-gitlab-empowers-translators-with-more-context",2,[666,690,713,737,759,780,799,818,837],1756472667210]