Git va changer le nom par défaut de sa branche « master » en « main » dans la version 3.0, prévue pour fin 2026, afin de promouvoir un langage inclusif dans le contexte des changements sociaux de 2020

Git prévoit de changer le nom par défaut de sa branche « master » en « main » dans la version 3.0, attendue fin 2026, afin de promouvoir un langage inclusif dans le contexte des changements sociaux de 2020. Cela affectera les nouveaux référentiels, qui devront être mis à jour au niveau des scripts et des workflows afin d'éviter toute perturbation. Parmi les autres améliorations, on peut citer le hachage SHA-256 et l'intégration de Rust. Cette décision permet d'équilibrer progrès technique et sensibilité culturelle.

Faut-il opérer le retrait de termes comme blacklist, whitelist, master, slave ou encore kill (longtemps utilisés au sein de bases de code et de documentations) au motif de ce qu’ils véhiculent des stéréotypes raciaux ? C’est l’un des débats qui divisent le plus la communauté des développeurs informatique à date. Avec les développements en lien avec la mort de Georges Floyd en 2021, il a pris plus d’ampleur. Désormais, le passage à des termes considérés comme plus inclusifs se généralise pour lutter contre le racisme dans le monde de l’informatique.

En 2021, l’équipe de mainteneurs de Gitlab a annoncé une mise à jour du nommage de la branche par défaut des projets sur la plateforme. « Les mainteneurs du projet Git, en coordination avec la communauté au sens large, ont écouté les commentaires de la communauté de développement pour déterminer un nom plus descriptif et plus inclusif pour la branche par défaut et offrir aux utilisateurs des options pour changer le nom de la branche par défaut (généralement maître) de leur dépôt », indique-t-elle.

En 2020, GitHub a annoncé faire usage du terme « main » en lieu et place de « master » pour désigner la branche par défaut des projets. L’explication des responsables de la plateforme en lien avec ce changement tranche avec l’habituel en s’appuyant sur une terminologie elle-même politiquement correcte : « Main est le remplacement de master le plus populaire que l'on rencontre sur GitHub. Nous l'aimons parce qu'il est court, qu'il garde la mémoire musculaire intacte et qu'il se traduit bien dans la plupart des langues. »

En 2018, la communauté Python avait déjà fait de même et a enclenché le processus de suppression des termes es termes "master/slave" dans sa documentation et dans sa base de code. En outre, des projets comme Django (2014), CouchDB (2014), Drupal (2014) et Redis (2017) ont fait de même. Tous avaient le même argument : bien que ces termes aient été utilisés depuis des décennies, ils peuvent avoir des significations à caractère raciste, entre autres, pour les utilisateurs. Il serait donc bon de les éviter.

Récemment, c'est Git qui a annoncé changer le nom par défaut de sa branche « master » en « main » dans la version 3.0, prévue pour fin 2026. Git est un logiciel de gestion de versions décentralisé. C'est un logiciel libre et gratuit, créé en 2005 par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. Git est maintenu par Junio C Hamano depuis juillet 2005. Depuis les années 2010, il s’agit du logiciel de gestion de versions le plus populaire dans le développement logiciel et web, qui est utilisé par 12 millions de personnes, sur tous les environnements (Windows, Mac, Linux). Git est aussi le système à la base du célèbre site web GitHub, le plus important hébergeur de code informatique.


De Master à Main : la révolution silencieuse de Git dans les conventions de nommage des codes

Dans le monde en constante évolution du développement logiciel, peu d'outils ont atteint l'omniprésence de Git, le système de contrôle de version qui sous-tend tout, des projets de codage individuels aux référentiels d'entreprise massifs. Alors que Git approche de la version 3.0, un changement apparemment mineur mais symboliquement chargé est sur le point de redéfinir ses paramètres par défaut : le nom initial de la branche passera de « master » à « main ». Cet ajustement, attendu depuis longtemps, reflète une évolution plus large du secteur vers un langage inclusif et des pratiques modernes, mais il soulève également des questions pratiques pour les développeurs, les équipes et les organisations qui dépendent de l'écosystème Git.

Les origines de ce changement remontent à 2020, dans un contexte mondial de remise en question des préjugés systémiques. La Software Freedom Conservancy, l'organisme à but non lucratif qui gère Git, a annoncé son intention de mettre à jour le nom par défaut de la branche, invoquant des préoccupations liées à la terminologie ayant des connotations historiques d'oppression. Comme détaillé dans un récent article publié sur le blog de Thoughtbot, Git 3.0 imposera « main » pour les nouveaux référentiels initialisés avec « git init », sauf configuration contraire. Il ne s'agit pas seulement d'un changement cosmétique, mais d'un clin d'œil à l'évolution des normes sociales dans le domaine technologique, où les mots ont leur importance pour favoriser la diversité et créer des environnements accueillants.

GitHub, la plateforme dominante pour les référentiels Git, a pris les devants en remplaçant son nom par défaut par « main » en octobre 2020, influençant ainsi des millions d'utilisateurs. Cependant, Git lui-même a pris du retard, conservant « master » afin de ne pas perturber les flux de travail. Avec l'arrivée prochaine de Git 3.0, prévue pour fin 2026, l'outil principal rattrape son retard. Cette synchronisation pourrait rationaliser les opérations, mais exige également une préparation des systèmes existants.

Les répercussions techniques d'un changement de nom

Au-delà du symbolisme, ce changement a des implications concrètes pour les bases de code du monde entier. Pour commencer, les référentiels existants ne renommeront pas automatiquement les branches ; le changement ne s'applique qu'aux nouvelles branches. Cependant, les pipelines CI/CD, les scripts et les outils d'automatisation codés en dur avec des références « master » pourraient ne plus fonctionner. Imaginez qu'un script de déploiement échoue parce qu'il suppose que la branche principale est « master » — un scénario qui s'est déjà produit lors des migrations GitHub.

Les développeurs habitués à « git checkout master » devront adapter leurs habitudes, éventuellement en modifiant la configuration, par exemple en définissant « init.defaultBranch » dans les configurations Git. Les réactions mettent en évidence les pièges courants : téléchargements à distance oubliés, demandes de tirage incompatibles et même problèmes d'intégration avec des outils tels que Jenkins ou GitLab. Un message publié en 2021 fait état de la frustration suscitée par les poussées aboutissant dans des branches non souhaitées en raison d'incompatibilités par défaut.

De plus, ce n'est pas la seule refonte de Git 3.0. La version promet le passage du hachage SHA-1 au hachage SHA-256 pour une sécurité renforcée, de meilleurs formats de stockage pour des performances multiplateformes et une intégration plus poussée de Rust dans le processus de construction de Git. Ces mises à niveau positionnent l'outil pour un avenir où l'évolutivité et la sécurité sont primordiales. Pourtant, le changement de nom de la branche se distingue par sa résonance culturelle, faisant écho aux directives de GitHub de 2020 sur le renommage des référentiels.

Réactions de l'industrie et défis liés à l'adoption

La communauté des développeurs a des sentiments mitigés. Certains saluent cette mesure comme une avancée progressive, en phase avec les pratiques inclusives qui rendent la technologie plus accessible. D'autres la considèrent comme une perturbation inutile, un utilisateur déplorant les étapes supplémentaires imposées par les plateformes qui capitalisent sur les mouvements sociaux. Un ingénieur logiciel explique comment les modèles structurés tels que GitFlow, popularisés en 2010, doivent évoluer pour s'adapter à la nouvelle norme « main », ce qui pourrait simplifier les flux de travail mais nécessiterait une nouvelle formation.

Dans le monde de l'entreprise, l'impact pourrait être considérable. Les grandes organisations, des start-ups aux entreprises du Fortune 500, gèrent souvent des milliers de référentiels. Une migration forcée pourrait impliquer l'audit de scripts, la mise à jour de la documentation et la formation du personnel, ce qui représente des coûts supplémentaires. Ce changement officialise ce que beaucoup ont déjà adopté volontairement, mais pour les retardataires, c'est un signal d'alarme. Un rapport de 2025 décrit étape par étape les processus permettant de modifier les paramètres par défaut via l'interface web ou les commandes CLI de GitHub, soulignant la facilité pour les nouveaux référentiels, mais la complexité pour les anciens.

La résistance n'est pas seulement technique, elle est aussi philosophique. Les détracteurs affirment que le terme « master » dans Git fait référence à une copie principale, et non à l'esclavage historique, en s'appuyant sur des termes utilisés dans l'ingénierie audio ou les bases de données. Les partisans rétorquent que l'intention n'efface pas la perception, en particulier dans une industrie mondiale. Ce débat reflète des discussions plus larges dans le domaine technologique, comme le changement de nom de « blacklist » (liste noire) en « blocklist » (liste de blocage), comme on le voit dans les initiatives d'entreprises telles qu'Apple et Google.


Préparation à Git 3.0 : stratégies et meilleures pratiques

Pour atténuer les perturbations, les experts recommandent des mesures proactives. Commencez par configurer Git localement : « git config –global init.defaultBranch main » garantit que les nouveaux projets s'alignent sur la future norme. Pour les équipes, des outils tels que le guide de renommage de GitHub, disponible sur leur référentiel dédié, fournissent des scripts pour les mises à jour en masse, y compris l'ajustement des références distantes et symboliques.

L'intégration avec d'autres systèmes est essentielle. Dans les pipelines DevOps, la mise à jour des références dans les fichiers YAML ou les scripts Docker permet d'éviter les échecs. La fusion régulière de « main » dans les branches de fonctionnalités permet de tout synchroniser, réduisant ainsi les conflits de fusion. Pour les responsables de l'open source, une communication claire dans les documents du projet peut guider les contributeurs, évitant ainsi toute confusion dans les demandes d'extraction.

À l'avenir, ce changement pourrait accélérer l'adoption de stratégies de branchement modernes. Le développement basé sur le tronc, qui favorise les branches de courte durée issues de « main », pourrait gagner du terrain par rapport à des modèles complexes comme...