Rétrospective des 20 ans de Git – toujours étrange, toujours génial

• Git est un système de gestion de versions qui a commencé il y a 20 ans lorsque Linus Torvalds a effectué le premier commit
• À l’origine, ce n’était qu’un simple projet personnel, mais il est ensuite devenu le système de gestion de versions le plus largement utilisé dans le monde
• L’auteur est cofondateur de GitHub et a été profondément impliqué dans l’évolution de Git en construisant des livres et une communauté autour de Git
• Au départ, c’était un simple outil de gestion du contenu de répertoires, mais il est devenu aujourd’hui un outil central qui a transformé la manière de développer des logiciels

La philosophie de Git et sa nécessité

• Git est né dans la communauté du noyau Linux, frustrée par les limites des outils de gestion de versions existants
• Les méthodes de collaboration de l’époque reposaient sur des mailing lists, des tarballs et des fichiers patch, dans une logique distribuée et locale
• Les outils de SCM de l’époque étaient lents, centralisés et inefficaces, si bien que l’approche fondée sur les tarballs et les patchs était préférable
• Un outil appelé BitKeeper constituait une alternative, mais des problèmes de licence ont conduit au lancement du développement de Git
• Dès le départ, Git n’a pas été conçu comme un « système de gestion de versions », mais comme une structure de données destinée à mieux manipuler les patchs et les tarballs

Le premier commit de Git

• Le premier commit était un outil très basique de suivi du contenu des répertoires
• À l’époque, il ne s’agissait pas de commandes comme git commit, mais d’outils de base de données de bas niveau comme write-tree et commit-tree
• Dès le départ, Git disposait des capacités suivantes :
  • stocker le répertoire de travail dans le cache (update-cache), le transformer en arbre d’objets (write-tree) et l’enregistrer dans la base de données
  • enregistrer les changements sous forme de commit (commit-tree) afin de créer un historique
  • lire et comparer les objets de la base de données avec cat-file, read-tree et show-diff
• Linus considérait Git simplement comme un backend de « plomberie » et voulait que l’interface utilisateur soit construite à l’extérieur

Un cas d’usage de Git pour la distribution de contenu

• En 2005, l’auteur a utilisé Git chez une startup appelée Reactrix pour distribuer du contenu publicitaire numérique
• Des centaines d’écrans numériques devaient chacun recevoir une combinaison différente de publicités, et les capacités d’adressage par contenu de Git ont permis de résoudre cela efficacement
• Il s’agissait d’un exemple créatif d’utilisation de Git non pas comme outil de gestion de code, mais comme outil de distribution de contenu
• Nick Hengeveld, l’un des principaux contributeurs du projet Git à ses débuts, a ajouté des fonctionnalités comme SSL et les transferts HTTP parallèles
• Cette expérience a conduit à la création de documentation, d’un site web et de livres sur Git, puis plus tard à GitHub

L’évolution des commandes Git et des outils pour les utilisateurs

• À ses débuts, toutes les commandes Git étaient des outils de bas niveau reposant sur des scripts, très différents de ce que nous connaissons aujourd’hui
• Des commandes comme git log, git rebase et git commit ont d’abord été de simples scripts shell, puis ont progressivement évolué vers leur forme actuelle

La première version de git log

• git log était un script simple de la forme git-rev-list --pretty HEAD | less
• rev-list est un outil servant à afficher les ID de commit, et il existe encore aujourd’hui

L’apparition de git rebase

• Le concept de rebase est né d’un échange d’e-mails entre Linus et Junio Hamano en 2005
• La manière de travailler de Junio consistait à abandonner le HEAD existant puis à poursuivre le travail à partir d’un nouveau HEAD, ce qu’il a décrit comme un « rebase »
• Cela a ensuite évolué pour devenir la commande git rebase telle que nous la connaissons aujourd’hui

L’origine d’Octocat

• Octocat, le symbole de GitHub, tire son inspiration de la stratégie d’« octopus merge » dans Git
• Cette stratégie de fusion de plusieurs branches en même temps était appelée « octopus », et GitHub s’est inspiré de ce terme à ses débuts pour créer le personnage d’Octocat

Le présent et l’avenir de Git

• L’auteur continue d’utiliser Git conformément à son objectif d’origine, comme un « stupid content tracker »
• Le projet GitButler utilise Git pour suivre et enregistrer l’historique des projets
• Git reste un système puissant de suivi de contenu et distribué, et il pourra probablement continuer à être utilisé de multiples façons à l’avenir

• Joyeux anniversaire, Git. Toujours étrange, toujours génial

[aobamisaki]

Joyeux 20e anniversaire à Git.

[bobross0]

Félicitations

[girr311]

Joyeux anniversaire. Écoute bien les anciens et reste en bonne santé pendant très longtemps.

[kaistj]

Joyeux anniversaire ^^

[crawler]

C’est bizarrement le genre de post qui enthousiasme à fond, ça.

[GN⁺]

Réactions sur Hacker News

• Les récits sur les origines de Git ont tendance à décrire Linus comme une sorte de prophète

  • Le billet de blog met en avant le côté humain de Linus et évoque les tâtonnements du début
  • Mercurial a aussi joué un rôle important, mais on l’ignore souvent
  • Mercurial avait une UI dès le départ et, avec une UI proche de Subversion, il était plus convivial
  • La structure de données de Git n’est pas adaptée aux fichiers volumineux
  • Je ne pense pas que Git était inévitable, et j’espère voir apparaître de nouvelles alternatives

• Vers 2002, j’avais eu l’idée d’étiqueter chaque partie d’un projet avec un code de hachage unique

  • Je l’ai proposée à des entreprises de logiciel, mais cela n’a suscité aucun intérêt

• J’ai commencé à utiliser Git comme alternative à ClearCase

  • J’ai commencé à utiliser Git vers 2007 et j’ai écrit des scripts pour contourner les lourdeurs de ClearCase
  • En 2008, j’ai commencé à contribuer des patchs à Git et j’y ai beaucoup appris sur la contribution open source
  • Malgré la complexité de sa CLI, je n’ai pas eu de difficulté particulière à utiliser Git
  • Dans mon emploi suivant, je travaillais à partir d’un fork de Chromium et je suis devenu très à l’aise pour résoudre les conflits de fusion avec Git
  • J’ai été déçu que GitHub soit devenu le principal outil de revue de code pour Git, mais je pense quand même que Git était un meilleur choix que Mercurial

• Il est surprenant de constater que Git n’a que 20 ans

  • Le fait que GitHub ait moins de 20 ans n’est pas surprenant, mais apprendre que Git n’existait pas avant 2005 est choquant
  • Je n’ai jamais utilisé d’autres solutions de gestion de code source, et je me demande si j’en utiliserai un jour

• Il était intéressant de découvrir le contexte historique

  • ClearCase utilisait lui aussi le terme rebase, et on peut vérifier qu’il était employé depuis 1999
  • Le rebase de ClearCase prenait beaucoup de temps, donc le rebase quasi instantané de Git était impressionnant

• Je voulais créer un outil efficace de base de données d’historique de tarballs, pas un système de gestion de versions

• J’ai appris qu’on pouvait signer les commits avec des clés ssh

  • J’ai utilisé la signature via ssh pour résoudre un problème sur OpenBSD
  • J’ai l’impression que cela ne fait pas déjà 20 ans que j’ai migré des éléments de travail de CVS vers Git

• Merci pour cet article utile ; je recommande aussi un dépôt qui inclut une introduction à la structure interne de Git

• L’idée d’écrire un billet de blog sur la collaboration via mailing lists est intéressante

• Parmi les nombreux systèmes de gestion de code source, Git a la pire ergonomie, mais c’est quand même mon préféré