Git a 20 ans : questions et réponses avec Linus TorvaldsPour célébrer les vingt ans de Git, Linus Torvalds s'est livré à une foire aux questions pour discuter de la façon dont il a changé à jamais le développement de logiciels. Pour rappel, Linus Torvalds est un ingénieur logiciel finlandais, créateur et développeur principal du noyau Linux. Il a également créé le système de contrôle de version distribué Git.
Il y a exactement vingt ans, le 7 avril 2005, Linus Torvalds a effectué la toute première validation du système de contrôle de version Git. Torvalds a écrit Git en seulement 10 jours après que les développeurs du noyau Linux aient perdu l'accès à leur outil propriétaire, BitKeeper, en raison de désaccords sur les licences. En fait, lors de ce premier commit, il avait écrit suffisamment de Git pour utiliser Git pour faire le commit !
La conception non conventionnelle et décentralisée de Git, aujourd'hui omniprésente et apparemment évidente, était révolutionnaire à l'époque et a modifié la manière dont les équipes logicielles collaborent et développent.
La vidéo suivante montre l'interview de Linus Torvalds où il parle des premiers jours de Git, revient sur les principales décisions de conception à l'origine du succès durable de Git et discute de la façon dont il a changé à jamais le développement logiciel. La suite de l'article est la transcription de la vidéo.
Taylor Blau : Cela fait 20 ans, presque à l'heure près, que Git a été suffisamment auto-hébergé pour écrire son premier commit. Vous attendiez-vous à être assis ici 20 ans plus tard, à l'utiliser encore et à en parler ?
Linus Torvalds : Toujours en train de l'utiliser, oui. Peut-être pas en train d'en parler. Je veux dire que cela a été l'une des grandes surprises, à savoir à quel point il s'est imposé dans le monde du SCM. J'y voyais une solution à mes problèmes, et je pensais évidemment qu'il était supérieur. Même il y a 20 ans jour pour jour, je pensais que la première version, qui était assez brute - pour être honnête, même cette version était supérieure à CVS.
Mais en même temps, j'avais vu CVS s'accrocher au marché - SVN est apparu, mais c'est juste CVS sous une autre forme, n'est-ce pas - pendant de nombreuses décennies. Je me suis donc dit : « D'accord, ce marché est très collant. Je ne peux pas utiliser CVS parce que je le déteste passionnément, alors je vais faire mon propre truc. Je ne pouvais plus utiliser BitKeeper, évidemment. Alors je me suis dit, ok, je vais faire quelque chose qui marche pour moi, et je ne me préoccuperai pas des autres. Et cela s'est vraiment vu au cours des premiers mois et des premières années - les gens se plaignaient que c'était un peu difficile à utiliser, pas assez intuitif. Puis il s'est passé quelque chose, comme si on avait appuyé sur un bouton.
Je vais faire quelque chose qui marche pour moi, et je ne me préoccuperai pas des autres.
Taylor Blau : Vous avez parlé de BitKeeper. Nous pourrions peut-être en parler.
Linus Torvalds : Bien sûr.
Taylor Blau : Vous avez écrit la version initiale de Git en une dizaine de jours pour remplacer le noyau.
Linus Torvalds : Oui et non. Il a fallu moins de dix jours pour que je puisse l'utiliser pour le noyau, oui. Mais pour être juste, tout le processus a commencé en décembre ou novembre de l'année précédente, donc en 2004.
Ce qui s'est passé, c'est que BitKeeper avait toujours assez bien fonctionné pour moi. Il n'était pas parfait, mais il était à des années-lumière de tout ce que j'avais essayé. Mais BitKeeper dans la communauté du noyau a toujours été très mal accueilli par la communauté parce qu'il était commercial. Il était gratuit pour une utilisation open source parce que Larry McVoy, que je connaissais, aimait vraiment l'open source. Je veux dire qu'en même temps, il en faisait un business et il voulait vendre BitKeeper à de grandes entreprises. Le fait que BitKeeper ne soit pas open source et qu'il soit utilisé pour l'un des plus grands projets open source était un point de friction pour beaucoup de gens. Et c'était aussi le cas pour moi.
Dans une certaine mesure, je voulais vraiment utiliser l'open source, mais en même temps, je suis très pragmatique et il n'y avait rien d'open source qui était, même de loin, assez bon. J'espérais donc que quelque chose de mieux se présenterait. Mais ce qui est arrivé, c'est que Tridge, en Australie, a fait de la rétro-ingénierie sur BitKeeper, ce qui n'était pas si difficile, car BitKeeper était en fait une bonne enveloppe autour de SCCS, qui remonte aux années 60. SCCS est presque pire que CVS.
Mais c'était explicitement contre les règles de la licence de BitKeeper. BitKeeper disait : vous pouvez l'utiliser pour l'open source, mais vous ne pouvez pas faire d'ingénierie inverse. Et vous ne pouvez pas essayer de cloner BitKeeper. Et cela a posé d'énormes problèmes. Et tout cela se passait en privé, donc je parlais à Larry et j'envoyais des courriels à Tridge et nous essayions de trouver une solution, mais Tridge et Larry étaient vraiment aux antipodes l'un de l'autre et il n'y avait aucune solution qui se dessinait.
Lorsque j'ai commencé à écrire Git, cela faisait quatre mois que je réfléchissais à ce problème, à ce qui fonctionnait pour moi et à la question suivante : « Comment puis-je faire quelque chose qui soit encore mieux que BitKeeper, mais qui ne le fasse pas comme BitKeeper ? Je ne voulais pas me retrouver dans la situation où Larry me dirait : « Hé, tu as fait la seule chose que tu n'étais pas censé faire. »
...comment faire quelque chose qui fait encore mieux que BitKeeper, mais qui ne le fait pas de la même manière que BitKeeper.
Taylor Blau : Je voudrais parler de ces deux choses. Nous pouvons commencer par cette période de 10 jours. Si j'ai bien compris, vous avez pris cette période pour vous éloigner du noyau et vous vous êtes surtout concentré sur Git de manière isolée. Comment s'est déroulée la transition entre le travail sur Git et le noyau ?
Linus Torvalds : Eh bien, comme il ne s'agissait que de deux semaines, c'est ce qui s'est passé. En fait, ce n'était pas très important. J'avais déjà fait ce genre de choses pour - au cours des 35 dernières années, j'ai été en vacances deux ou trois fois, c'est vrai, pas très souvent. Mais je me suis déjà éloigné du noyau pendant deux semaines d'affilée.
Et c'était assez intéressant parce que l'une de mes réactions a été de voir à quel point il est plus facile de programmer dans l'espace utilisateur. Il y a tellement moins de choses dont il faut se préoccuper. Vous n'avez pas à vous soucier des allocations de mémoire. Vous n'avez pas à vous soucier de beaucoup de choses. Et le débogage est tellement plus facile quand vous avez toute cette infrastructure que vous écrivez quand vous faites un noyau.
En fait, c'était un peu - je ne dirais pas relaxant, mais c'était amusant de faire quelque chose dans l'espace utilisateur où j'avais un objectif assez clair de ce que je voulais. Je veux dire, un objectif clair dans le sens où je connaissais la direction. Je ne connaissais pas les détails.
Taylor Blau : L'une des choses que je trouve intéressantes à propos de Git, surtout 20 ans plus tard, c'est que le modèle de développement qu'il encourage me semble si simple qu'il est presque évident à ce stade. Mais je ne dis pas cela comme un terme réducteur. Je pense qu'il y a eu beaucoup de réflexion pour distiller l'univers des idées de contrôle de source jusqu'à ce qui est devenu Git. Dites-moi, quels ont été les choix non évidents que vous avez faits à l'époque ?
Linus Torvalds : Le fait que vous disiez que c'est évident maintenant, je pense que ce n'était pas évident à l'époque. 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 contexte de type CVS. Et l'état d'esprit de Git, je l'ai abordé d'un point de vue de personne de système de fichiers, où j'avais ce dédain et presque de la haine pour la plupart des projets de gestion de contrôle de source, donc je n'étais pas du tout intéressé par le maintien du statu quo.
Et le plus gros problème pour moi - eh bien, il y en avait deux énormes. L'un était la performance : à l'époque, j'appliquais encore beaucoup de correctifs, ce que Git a presque fait disparaître, car je ne fais plus que fusionner le code d'autres personnes.
Mais pour moi, l'un des objectifs était de pouvoir appliquer une série de correctifs en une demi-minute, même s'il s'agissait de 50 ou 100 correctifs.
Taylor Blau : Vous ne devriez pas avoir besoin d'un café pour...
Linus Torvalds : Exactement. Et c'était important pour moi parce que c'est en fait une question de qualité de vie. C'est l'une de ces choses où si les choses sont instantanées, si une erreur se produit, vous voyez immédiatement le résultat et vous continuez et vous le corrigez. Certains des autres projets que j'avais examinés prenaient environ une demi-minute par correctif, ce qui n'était pas acceptable pour moi. Et ce parce que le noyau est un projet très vaste et que beaucoup de ces SCM n'ont pas été conçus pour être évolutifs.
Et c'était important pour moi parce que c'est en fait une question de qualité de vie.
En effet, nous avions déjà rencontré ce problème avec BitKeeper, qui utilisait des CRC et des MD5, mais qui ne les utilisait pas pour tout. L'une des premières idées que j'ai eues, c'est qu'absolument tout était protégé par un très bon hachage.
C'est ce qui a guidé l'ensemble du projet, avec deux ou trois idées de conception fondamentales. C'est pourquoi, à un bas niveau, il est en fait assez simple, mais la complexité réside dans les détails, les interfaces utilisateur et toutes les choses qu'il doit être capable de faire - parce que tout le monde veut qu'il fasse des choses folles. Mais le fait d'avoir une conception de bas niveau avec quelques concepts de base a facilité l'écriture, la réflexion et, dans une certaine mesure, l'explication des idées aux gens.
Je compare cela à Unix. Unix a comme philosophie de base que tout est un processus, tout est un fichier, on fait passer des choses entre les choses. En réalité, ce n'est pas si simple. Il y a les concepts simples qui sous-tendent la philosophie, mais tous les détails sont très compliqués.
Je pense que c'est ce qui m'a fait apprécier Unix en premier lieu. Et je pense que Git a un peu le même genre de caractéristiques, il y a une simplicité fondamentale dans la conception et puis il y a la complexité de l'implémentation.
Taylor Blau : Il y a un lien entre Unix et la façon dont Git a été conçu.
Linus Torvalds : Oui.
Taylor Blau : Vous avez parlé de SHA-1. L'une des choses auxquelles je pense au cours de la semaine ou des deux semaines où vous avez développé la première version de Git, c'est que vous avez pris beaucoup de décisions qui sont restées dans les mémoires.
Linus Torvalds : Oui, c'est vrai.
Taylor Blau : Y en a-t-il eu, y compris SHA-1 ou non, que vous avez regrettées ou que vous auriez voulu faire différemment ?
Linus Torvalds : Eh bien, je veux dire que je regrette SHA-1 dans le sens où je pense qu'il a causé beaucoup d'agitation inutile avec l'idée d'essayer de supporter SHA-256 aussi bien que SHA-1. Je comprends pourquoi c'est arrivé, mais je pense que c'était surtout inutile.
Je ne pense pas qu'il y ait eu un besoin énorme et réel, mais les gens étaient inquiets, alors c'était court. Je pense donc qu'il y a eu beaucoup d'efforts gaspillés. Il y a un certain nombre d'autres petits problèmes. Je pense que j'ai fait une erreur dans la façon dont les entrées du fichier d'index sont triées. Je pense qu'il y a ces détails stupides qui ont rendu les choses plus difficiles qu'elles ne devraient l'être.
Mais en même temps, beaucoup de ces choses pourraient être corrigées, mais elles sont suffisamment petites. Cela n'a pas vraiment d'importance. Toutes les complexités sont ailleurs en fin de compte.
Taylor Blau : Il semble donc que vous ayez peu de regrets. Je pense que c'est une bonne chose. Y a-t-il eu des moments où vous n'étiez pas sûr que ce que vous essayiez de réaliser allait fonctionner, s'assembler ou être utilisable ? Ou aviez-vous déjà une idée assez claire ?
Linus Torvalds : J'avais une idée claire des étapes initiales, mais je n'étais pas sûr de la façon dont cela fonctionnerait à long terme. Honnêtement, après la première semaine, j'avais quelque chose de bien pour appliquer les correctifs, mais pas vraiment pour le reste. J'avais les bases pour faire des fusions, et les structures de données étaient en place pour cela, mais cela a pris, je crois, une semaine de plus avant que je ne fasse ma première fusion.
Il y a un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un résultat en tête, mais je n'étais pas sûr d'y arriver. Oui, les premiers pas, je veux dire la première ou les deux premières semaines, vous pouvez aller voir le code - et les gens l'ont fait - et ce n'est pas un code compliqué.
Taylor Blau : Non.
Linus Torvalds : Je crois que la première version faisait 10 000 lignes ou quelque chose comme ça.
Taylor Blau : Vous pouvez plus ou moins le lire en une seule séance.
Linus Torvalds : Oui, et il est assez simple et ne fait pas beaucoup de vérifications d'erreurs et d'autres choses de ce genre. Il s'agit vraiment d'un « Faisons-le fonctionner parce que j'ai un autre projet que je considère comme plus important que celui auquel je dois me consacrer ». C'était vraiment le cas. Il m'arrivait de rencontrer des problèmes qui m'obligeaient à faire des changements.
« Il y a eu un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un résultat en tête, mais je n'étais pas sûr d'y arriver. »
Linus Torvalds : La première version - je pense que nous avons fini par faire un transfert de magasin d'objets incompatible à un moment donné. Au moins, fsck se plaint de certains des anciens objets que nous avions parce que j'ai changé le format des données.
Taylor Blau : Je ne savais pas d'où cela venait.
Linus Torvalds : Oui, non. La première version ne faisait pas tout ce qu'elle devait faire.
Et j'ai oublié si j'avais fait une conversion ou non. Il se peut que je n'aie jamais eu besoin de convertir. Et nous avons juste quelques avertissements pour quelques objets dans le noyau où fsck dira, « Hé, c'est un ancien format qui n'est plus supporté ». Ce genre de choses. Mais d'un autre côté, dans l'ensemble, cela a vraiment fonctionné, je veux dire, étonnamment bien.
Le gros problème a toujours été l'acceptation par les gens.
Taylor Blau : C'est vrai.
Linus Torvalds : Et cela a pris beaucoup de temps.
« Mais d'un autre côté, dans l'ensemble, ça a vraiment marché, je veux dire, étonnamment bien. »
Taylor Blau : Nous avons un peu parlé du fait que la fusion a été mise en place mais qu'elle n'a pas été fonctionnelle avant la deuxième ou la troisième semaine. Quelles sont les autres fonctionnalités que vous avez laissées de côté dans la version initiale et dont vous vous êtes rendu compte plus tard qu'elles étaient en fait essentielles au projet ?
Linus Torvalds : Eh bien, ce n'est pas tant « réalisé plus tard », c'était des choses dont je ne me souciais pas, mais je savais que si cela devait aller quelque part, quelqu'un d'autre le ferait. La première semaine où je l'ai utilisé pour le noyau, j'utilisais littéralement les commandes brutes, ce qu'on appelle aujourd'hui les « commandes de plomberie », à la main.
Taylor Blau : C'est évident.
Linus Torvalds : Parce qu'il n'y avait pas de porcelaine. Il n'y avait rien au-dessus pour le rendre utilisable. Donc, pour faire un commit, vous faisiez ces choses très obscures.
Taylor Blau : Définir l'index, faire un commit-tree.
Linus Torvalds : Oui, commit-tree, écrit, et cela renvoie juste un SHA que vous écrivez à la main dans le fichier head et c'est tout.
Taylor Blau : Est-ce que hash-object existait dans la première version ?
Linus Torvalds : Je pense que c'était l'un des premiers binaires que j'avais où je...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.