Pourquoi l'augmentation soudaine du nombre de soumissionnaires Git sur le graphique popcon Debian en 2010-01?
Presque tous les articles que j'ai lus 1 en comparant Git et Mercurial, il semble que Mercurial ait une meilleure UX en ligne de commande, chaque commande étant limitée à une seule idée (contrairement à disons git checkout).
Mais à un moment donné, Git est soudainement devenu très populaire et le nombre de soumissionnaires Git sur le graphique popcon Debian (voir l'image du graphique ci-dessous) a littéralement explosé.
Source: Debian
Que s'est-il passé en 2010-01 que les choses ont soudainement changé. On dirait que GitHub a été fondé plus tôt que cela - 2008.
Le paquet "gnuit" (GNU Interactive Tools, un navigateur/visualiseur de fichiers et un visualiseur de processus) était appelé "git" dans Debian jusqu'au 2009-09-09, tandis que git était appelé "git-core".
Par conséquent, un meilleur graphique à regarder est:
Ce qui montre que la popularité n'a pas augmenté de façon spectaculaire (prenez la ligne verte pour la partie gauche jusqu'à ce qu'ils traversent, puis prenez la ligne rouge).
Le paquet git dans Debian était auparavant connu sous le nom de git-core. En avril 2010, le package a été renommé git. Plus de détails peuvent être trouvés dans ce blog de Julius Plenz ou ce commit dans Debian .
Voici un graphique qui montre le nombre d'installations de git et git-core heures supplémentaires:
J'utilisais Darcs pour mes propres projets depuis un petit moment. Je suis passé à git pendant l'ascension rapide à laquelle fait référence votre graphique, voici donc mon observation:
Les systèmes de contrôle des sources distribuées à peu près à ce moment-là étaient une chose de pointe. Les soi-disant programmeurs alpha les utilisaient sur le côté, mais ils tombaient hors du radar de la plupart des développeurs de logiciels professionnels. La manière CVS/SVN/SourceSafe/TFS de regarder le monde était une manière dont les programmeurs en général étaient plus ou moins satisfaits et la plupart des gens supposaient que les problèmes qui engendraient le système de contrôle de source distribué pourraient être corrigés avec un meilleur outillage. Tout comme vous avez obtenu une amélioration en passant de CVS -> SVN, il y aurait un jour quelque chose qui vous permettrait d'aller SVN -> SVN ++. Sinon, comment géreriez-vous le contrôle de code source?
Puis vint git. Ce qui a forcé Git sur le radar de tout le monde, c'est qu'il y avait un énorme, projet public qui l'a immédiatement adopté. Git a beaucoup d'utilisateurs gratuitement - si vous deviez faire un piratage sérieux du noyau, vous avez utilisé git. Bien que je ne puisse pas être sûr à 100%, je parierais qu'à ce moment-là, aucun autre DVCS n'avait une telle base d'utilisateurs.
Ensuite, cela a fonctionné. Cela a bien fonctionné. Cela a bien fonctionné en public. Il était également, pour ses verrues initiales, plus stable que la plupart des DVCS simultanés à l'époque. Les darcs, par exemple, pouvaient être mis dans un état incohérent qui nécessitait un utilitaire absurdement complexe (quadratique? Factoriel? Je ne m'en souviens pas avec certitude, mais c'était mauvais) utilitaire à corriger. Git a toujours été plus stable.
De sa large base d'utilisateurs, il a simplement saigné.
Chaque projet, commercial ou open source, a besoin de cette masse critique. Les Darcs ne l'ont pas compris. Mercurial non plus. Se rappeler. Beaucoup de petits projets l'utilisent. Il y a probablement même un certain nombre d'utilisateurs commerciaux. Mais quelle est votre grande réussite?
"Si c'est assez bon pour le noyau Linux, c'est assez bon pour vous" est un argument très convaincant.
Donc, pour résumer, c'était un bon produit qui est arrivé au bon moment et a obtenu une large base d'utilisateurs dévouée.
J'étais un adopteur tardif - passant de Mercurial à Git vers 2010.
La raison pour laquelle je crois que Git est devenu si populaire est à cause de sites tels que GitHub, vous avez eu un effet de réseau dans les outils de contrôle de version. Cela n'était auparavant pas vu, car vous partagiez du code sur une base de projet ou d'entreprise.
Je me souviens spécifiquement d'avoir changé pour Git et Github parce que tous les projets auxquels je voulais participer et auxquels j'avais contribué avaient fait de même, ainsi que les développeurs avec lesquels je m'associe.
C'est un effet de réseau.
GitHub était la couche de collaboration basée sur le Web la plus populaire basée sur DVCS et Git a fini par être "assez bon". Mercurial était certainement plus facile à apprendre et à utiliser, Git a de nombreuses nuances, mais avait une marque solide à cause de Linus.
Ce n'est pas parce que GitHub a été lancé en 2008 et que la croissance commence en 2010 que GitHub n'est pas responsable. Si vous regardez les courbes de croissance compétitives dans d'autres domaines tels que les réseaux sociaux et la croissance de Facebook, la ligne est très similaire.
Vous ne voyez pas de courbes de croissance comme ça sans un effet de boucle/réseau viral.
Par exemple. comparer à un graphique de croissance Facebook
Mise à jour: je sais que la source ci-dessus n'est peut-être pas exacte, mais il existe de nombreuses sources de données qui démontrent que Git a connu une croissance exponentielle au cours des dernières années.
Graphique 1: Mentions de Git dans les offres d'emploi
Et l'enquête Eclipse qui montre que la part de marché de Git est passée de 13% en 2011 à 27% en 2012 . Croissance incroyable.
Cet article fait une bien meilleure explication de la croissance de Git et des effets de réseau que ce que j'ai fait ici.
Je suis surpris que personne n'ait mentionné Github est l'une des principales raisons pour lesquelles Git gagne en popularité. Ils ont poussé Git mainstream.
Github a été lancé en avril 2008 et en 1 à 2 ans, ils ont gagné en popularité. Et puis, quand vous voyez une explosion soudaine de l'utilisation de git/git-core, c'est principalement dû aux utilisateurs de 2 millions de github et à leurs 3,7 millions de référentiels. Github a rendu git facile à utiliser. Bitbucket était là, mais github l'a fait sans effort. Je suis sûr que si les gars de github choisissaient Hg à la place de git, nous aurions dû voir une même augmentation de l'utilisation de Hg.
L'analogie peut être: Canonical: Linux :: Github: Git
Juste pour être clair, ce graphique montre l'installation de git sur les systèmes Debian.
Au moment où le pic survient, le paquet Debian a été renommé de git-core en git. Peut-être que les gens ont trouvé le package plus facile maintenant que le nom reflétait le logiciel.
Eh bien, à mon humble avis, les VCS distribués comme Hg et Git sont intrinsèquement meilleurs qu'un VCS centralisé - donc SVN allait toujours perdre à l'un d'eux.
Et git, comme cela a déjà été observé, avait l'énorme avantage sur Hg qu'il était utilisé par le projet open source le plus grand et le plus réussi de la planète - c'est un sacré record, dès le début.
Quant à savoir pourquoi l'explosion soudaine au début de 2010, je suppose que c'est assez prosaïque. Git est génial, mais ce n'est pas massivement intuitif pour un débutant.
Le meilleur livre Git, IMHO, est Pro Git, qui a été publié en septembre 2009. Le deuxième meilleur livre (à mon humble avis), O'Reilly's Git, a été publié en juin 2009.
Ainsi, la raison pour laquelle l'utilisation de Git a explosé au début de 2010 pourrait être aussi simple que le fait que c'est alors que de très bonnes ressources pour apprendre à l'utiliser sont devenues disponibles.
Le choix d'un système de contrôle de version est une décision sociale. L'équipe doit tous utiliser la même solution. Contrairement à un éditeur de texte, qui est une décision personnelle, différents développeurs peuvent utiliser différents éditeurs et collaborer facilement.
Donc choisir un système de contrôle de version a des effets de réseau, ce qui rend les systèmes qui peuvent être un peu meilleurs ou un peu plus populaires devenir encore plus populaires.
Par exemple, je préfère les darcs pour les projets open source, mais j'ai constaté que la plupart de mes contributeurs potentiels connaissaient git, et j'ai reçu plus de contributions plus facilement pour les projets hébergés avec git au lieu de darcs. Donc, je finis par utiliser git beaucoup à la place des darcs. Ensuite, parce que je l'utilise et publie du code sur Github, il semble que je l'approuve ou peut-être même le préfère, ce qui pourrait influencer les autres à l'utiliser.
Les développeurs ne veulent pas apprendre un nouveau système de contrôle des sources pour chaque projet auquel ils contribuent, donc il est avantageux pour la communauté globale d'avoir une norme qui soit "assez bonne" et largement populaire, puis de faire en sorte que chaque équipe et chaque projet choisissent le "meilleur". "solution dans le vide.
Github n'a ajouté que du carburant pour déclencher l'effet de réseau.