De nombreux programmeurs sont suffisamment jeunes pour n’avoir jamais connu un monde sans Git et les sites de développement construits autour de lui, comme GitHub et GitLab. Vous devriez être heureux, très heureux, que Linus Torvalds se soit senti obligé de créer un meilleur système de contrôle de version (VCS).
Avant cela, j’utilisais des systèmes de gestion du contrôle des sources (SCM) de première génération tels que Revision Control System (RCS), ce qui était… pénible. Puis est arrivé le Concurrent Versions System (CVS) en 1986, et ensuite Subversion (SVN) en 2000. La même année est apparu BitKeeper, le VCS à code source ouvert qui a été le premier SCM de Linux.
Auparavant, Torvalds s’était contenté de maintenir l’intégrité du code de Linux à la main. Mais en 1999, comme l’a fait remarquer le développeur Larry McVoy, Torvalds était épuisé. Le problème ? Il avait besoin des bons outils pour partager la charge de travail. McVoy lui a proposé son propre programme de SCM, BitKeeper. Mais Torvalds voulait continuer à faire les choses comme il les avait toujours faites.
Le dilemme BitKeeper
En 2003, le noyau Linux 2.4 avait pris du retard, beaucoup de retard, et la version 2.6 était encore plus lente a accoucher. Torvalds s’est donc finalement tourné vers BitKeeper.
Au début, cela a très bien fonctionné. Mais la mouche du coche a toujours été que BitKeeper était un programme propriétaire. Il est vrai qu’il existait une version gratuite de BitKeeper qui ne pouvait être utilisée qu’avec des projets open-source. Mais elle présentait des problèmes importants.
Comme l’a fait remarquer à l’époque Jonathan Corbet, développeur du noyau Linux et rédacteur en chef de Linux Weekly News (LWN), « Larry voulait avoir le beurre et l’argent du beurre. Il voulait vraiment soutenir le développement des logiciels libres – tant que ces logiciels ne menaçaient pas son propre créneau commercial. … Chaque fois que BitMover [la société de McVoy] sentait que son modèle commercial était menacé », elle modifiait ses conditions de licence.
Bryan Cantrill, développeur bien connu et directeur technique d’Oxide Computer, a déclaré des années plus tard sur Ycombinator : « La grande ironie est que Larry était l’un des premiers partisans de l’ouverture du système d’exploitation à Sun … D’un côté, on peut considérer l’histoire de BitKeeper en ce qui concerne l’open source comme une tragédie grecque ».
En 2005, Andrew Tridgell, un développeur du noyau Linux, a tenté d’inverser les protocoles de BitKeeper pour créer un client BitKeeper open source. C’est ce qui a fait déborder le vase pour McVoy, qui a ensuite retiré la version gratuite de BitKeeper.
Torvalds ne pensait cependant pas qu’il était juste de blâmer McVoy pour cette rupture. Dans un billet de la Linux Kernel Mailing List (LKM), il a écrit : « Ne blâmez pas BitMover, même si c’est probablement une réaction très courante. Larry, en particulier, a vraiment essayé d’arranger les choses »
Quelle que soit la personne à blâmer, Linux s’est retrouvé sans SCM. Que faire ?
La création de Git
La réponse de Torvalds a été de créer une véritable alternative VCS open-source : Git. En seulement 10 jours, il a développé une version fonctionnelle de Git, qui a été livrée pour la première fois le 7 avril 2005.
Bien sûr, il y pensait depuis un certain temps. Le conflit BitKeeper couvait depuis le début. Lors d’une récente interview sur GitHub, Torvalds a déclaré qu’il avait été confronté à la question suivante : « Comment puis-je faire quelque chose qui fonctionne encore mieux que BitKeeper mais qui ne le fait pas de la même manière que BitKeeper ? »
Comme Torvalds me l’a dit à l’époque, il ne voulait pas changer d’outil de gestion de la configuration des logiciels. Mais il n’avait pas d’autre choix que d’abandonner BitKeeper et de créer son propre système. Le nom lui-même n’a pas vraiment de signification. Torvalds a plaisanté en disant qu’il pourrait s’agir d’une « combinaison aléatoire de trois lettres qui est prononçable et qui n’est utilisé par aucune commande Unix courante. Le fait qu’il s’agisse d’une mauvaise prononciation de get peut ou non être pertinent ».
Torvalds n’était pas sûr à l’époque que Git serait le remplaçant permanent de BitKeeprer.
Impact durable
Je pense que nous sommes tous d’accord pour dire que Git a prouvé qu’il était plus qu’une passerelle temporaire. Selon le dernier décompte de 6sense, Git a plus de 87% de parts de marché SCM.
Aujourd’hui, tout le monde pense que ce que fait Git est évident. Ce n’était pas le cas à l’époque. Torvalds a déclaré : « Je pense que l’une des raisons pour lesquelles les gens ont trouvé Git très difficile à utiliser est que la plupart des personnes qui ont commencé sans utiliser Git venaient d’un environnement de type CVS. Et la mentalité Git, je l’ai abordée du point de vue d’un spécialiste des systèmes de fichiers, où j’avais ce dédain et presque cette haine de la plupart des projets de gestion du contrôle de source ». Aujourd’hui, sa vision de la gestion du code logiciel est devenue la façon dont nous travaillons presque tous avec le code.
Aujourd’hui, presque tous les développements open-source utilisent Git. Et si Linux est lié à Git, tous les systèmes d’exploitation le prennent désormais en charge.
Pourquoi Git connaît-il un tel succès ?
La conception décentralisée de Git était révolutionnaire à l’époque. Elle permettait aux développeurs de travailler de manière indépendante et de synchroniser les modifications de manière efficace. Cette approche a transformé la manière dont les équipes logicielles collaborent et développent des projets. « Git est devenu pratiquement synonyme de contrôle de version », a déclaré Scott Chacon, fondateur de GitHub, qui attribue à Git le mérite d’avoir changé le cours de sa vie.
En outre, comme l’a écrit Mohamed Yasser, architecte logiciel réputé, sur LinkedIn, « Git n’est pas seulement un système de contrôle de version ; c’est un cadre de confiance. Un registre de vision. Un espace où chaque branche reflète une pensée, et où chaque validation porte une intention. »
À l’aube de sa troisième décennie, Git continue de façonner l’avenir du développement logiciel.