Comment Git a-t-il été conçu?

Mon lieu de travail est récemment passé à Git et je l'aime (et je déteste!). Je l'aime vraiment et c'est extrêmement puissant. La seule partie que je déteste, c'est que parfois c'est trop puissant (et peut-être un peu laconique / déroutant).

Ma question est ... Comment Git a-t-il été conçu? En l'utilisant simplement pendant un court laps de temps, vous avez l'impression qu'il peut gérer de nombreux flux de travail obscurs que d'autres systèmes de contrôle de version ne pouvaient pas. Mais il se sent également élégant en dessous. Et vite!

C'est sans doute en partie grâce au talent de Linus. Mais je me demande, la conception globale de git était-elle basée sur quelque chose? J'ai lu BitKeeper mais les comptes manquent de détails techniques. La compression, les graphiques, se débarrasser des numéros de révision, mettre l'accent sur les branchements, le stashing, les télécommandes ... D'où tout cela vient-il?

Linus a vraiment frappé celui-ci hors du parc et à peu près du premier essai! C'est assez bon à utiliser une fois que vous avez dépassé la courbe d'apprentissage.

Git n'a pas été conçu autant qu'il a évolué .

Jetez un œil par vous-même. Clonez le référentiel git officiel , ouvrez-le dans gitk(ou votre visionneuse graphique de journaux git préférée), et regardez ses premières révisions.

Vous verrez qu'il n'avait à l'origine que la fonctionnalité de base (la base de données d'objets et l'index). Tout le reste a été fait à la main . Cependant, ce petit noyau a été conçu pour être facilement automatisé via des scripts shell. Les premiers utilisateurs de git ont écrit leurs propres scripts shell pour automatiser les tâches courantes; peu à peu, ces scripts ont été incorporés dans la distribution git (voir pour un premier exemple 839a7a0 ). Chaque fois qu'il y avait un nouveau besoin, les scripts étaient adaptés pour le permettre. Beaucoup plus tard, plusieurs de ces scripts seraient réécrits en C.

Cette combinaison d'un noyau orthogonal propre (que vous pouvez toujours utiliser directement si vous en avez besoin), avec une couche supérieure qui s'est développée organiquement dessus, est ce qui donne à git sa puissance. Bien sûr, c'est aussi ce qui lui donne la grande quantité de commandes et d'options aux noms étranges.

La compression, les graphiques, se débarrasser des numéros de révision, mettre l'accent sur les branchements, le stashing, les télécommandes ... D'où tout cela vient-il?

Une grande partie de cela n'était pas là au début.

Alors que chaque objet était compressé individuellement et que les doublons étaient évités par leur dénomination, les fichiers "pack" qui sont responsables de la compression élevée que nous avons l'habitude de voir dans git n'existaient pas. La philosophie au début était "l'espace disque est bon marché".

Si par "les graphiques" vous voulez dire les téléspectateurs graphiques gitk, ils sont apparus plus tard (AFAIK, le premier l'était gitk). AFAIK, BitKeeper avait également une visionneuse d'historique graphique.

Se débarrasser des numéros de version, en fait, le concept de base de git consistant à utiliser un système de fichiers adressé par contenu pour stocker les objets, venait principalement de monotone . À cette époque, le monotone était lent; si ce n'était pas le cas, il est possible que Linus l'ait utilisé au lieu de créer git.

Mettre l'accent sur la ramification est quelque peu inévitable sur un système de contrôle de version distribué, car chaque clone agit comme une branche distincte.

Stashing ( git stash) est, IIRC, assez récent. Les reflogs, qu'il utilise, n'étaient pas là au début.

Même les télécommandes n'étaient pas là au départ. À l'origine, vous avez copié les objets à la main à l'aide de rsync.

Une par une, chacune de ces fonctionnalités a été ajoutée par quelqu'un. Tous - peut-être même pas la plupart - n'ont pas tous été écrits par Linus. Chaque fois que quelqu'un ressent un besoin auquel git ne répond pas, on peut créer une nouvelle fonctionnalité sur la couche "plomberie" principale de git, et la proposer pour inclusion. S'il est bon, il sera probablement accepté, améliorant encore l'utilité de git (et sa complexité en ligne de commande).

Je pense que le point principal est simplement que git a été conçu par la personne la plus qualifiée de la planète pour le faire. Et je ne parle pas de talent, je parle d'expérience: je doute qu'il y ait quelqu'un d'autre qui ait été en charge d'une base de code avec une combinaison comparable de taille et de nombre de contributeurs comme le noyau Linux et qui s'occupe toujours de la plupart de l'intégration travailler lui-même.

Linus connaissait donc mieux que quiconque les exigences et les cas d'utilisation d'un système de contrôle de version distribué. Et bien sûr, cela a aidé que la plupart du codage qu'il traitait était en C, et une grande partie des performances critiques.

Fondamentalement, c'est l'exemple ultime de gratter ses propres démangeaisons.

Il a été conçu à peu près exactement comme décrit dans The Git Parable .

Imaginez que vous avez un ordinateur qui n'a rien d'autre qu'un éditeur de texte et quelques commandes de système de fichiers. Imaginez maintenant que vous avez décidé d'écrire un gros logiciel sur ce système. Parce que vous êtes un développeur de logiciels responsable, vous décidez que vous devez inventer une sorte de méthode pour garder une trace des versions de votre logiciel afin de pouvoir récupérer le code que vous avez précédemment modifié ou supprimé. Ce qui suit est une histoire sur la façon dont vous pourriez concevoir un tel système de contrôle de version (VCS) et le raisonnement derrière ces choix de conception.