Pourquoi Git a-t-il eu autant de battage médiatique? ... tandis que d'autres ne le font pas?
Ces dernières années, le battage médiatique autour de Git a considérablement augmenté. Tout le monde connaît Git, personne ne connaît les alternatives.
D'autres, comme Mercurial, semblent passer inaperçus. Les deux sont sortis en 2005 et offrent des fonctionnalités similaires. De plus, Mercurial est généralement considéré comme plus facile à utiliser, plus intuitif et avait depuis longtemps de meilleures interfaces utilisateur. Par conséquent, on pourrait supposer que ce serait une alternative populaire, en particulier pour les nouveaux utilisateurs du contrôle de version distribué. Pourtant, il semble inconnu de la plupart des gens, contrairement à Git qui a plutôt bien réussi.
Le but de cet article est d'essayer de mieux comprendre ce phénomène.
Comment se fait-il que Git fasse partie du gâteau? Ont-ils en quelque sorte utilisé un meilleur marketing? Est-ce parce que sa communauté est plus ... hum ... "verbeuse"? Est-ce à cause du nom "Linus"? Est-ce à cause de son image geek?
Qu'en penses-tu?
Je pense que des services comme GitHub ou Gitorious est un facteur important. Il est important pour les gens qu'ils puissent héberger leurs affaires quelque part et en particulier GitHub est un excellent service pour cela.
Pour Mercurial, il n'existait pas de service de ce type lorsque le DVCS est devenu populaire (du moins, à ma connaissance). Vous avez Bitbucket maintenant et probablement d'autres, mais GitHub existe depuis un certain temps, c'est bien connu et ça va de mieux en mieux.
Je vois beaucoup de réponses à cela qui s'appuient sur les sentiments de l'auteur en entendant parler de l'un ou l'autre SCM. D'autres disent que tout cela n'était que de la chance. Je crois que la chance peut être retracée dans l'histoire.
Je vais parler d'histoire.
Git et Mercurial ont été créés simultanément afin de résoudre le même problème. À l'époque, le noyau Linux a été contraint de cesser d'utiliser BitKeeper , un SCM distribué propriétaire qu'il utilisait depuis 3 ans. La raison en était que Larry McVoy, PDG de BitMover, la société derrière BitKeeper, a cessé de donner son logiciel gratuitement aux développeurs Linux, parce que quelqu'un au sein de la communauté Linux l'avait inversé.
Insatisfait de ce qui existait, Linus Torvalds a ensuite commencé à travailler sur un tout nouveau SCM qu'il appellerait bientôt Git. Peu de temps après, Matt Mackall a commencé le projet Mercurial pour des raisons similaires.
Après un certain temps à développer ces projets séparément, Matt Mackall a présenté une version avancée de son SCM et l'a comparée d'une certaine manière, en la comparant à Git (qui n'avait lui-même que quelques semaines). Linus a envisagé de l'utiliser au lieu de Git pour le développement du noyau, mais a abandonné l'idée quand il s'est rendu compte que Mercurial utilisait des Sets de modifications pour enregistrer les modifications de révision . Il craignait que cela ne soit trop proche de la façon dont BitKeeper fonctionnait, et il ne voulait certainement rien qui puisse faire dire à quelqu'un: "Ils ont construit un clone BitKeeper".
Git a donc été utilisé pour le développement du noyau au lieu de Mercurial, mais les deux étaient techniquement pertinents. Le résultat final est que Git a commencé par être réellement utilisé là où il était conçu pour être utilisé, tandis que Mercurial n'était pas aussi rapide pour trouver sa première grande utilisation des logiciels libres. Parce qu'il était doté d'un très bon design, et grâce à la persévérance de Matt Mackall, il est finalement devenu célèbre et utilisé pour de grands projets du monde réel.
Aujourd'hui, ils sont tous les deux célèbres. Lequel est le plus célèbre est impossible à dire. Google Code n'a intégré Git que récemment, alors qu'il avait Mercurial depuis longtemps. Beaucoup de projets vraiment grands et célèbres utilisent l'un ou l'autre.
Je suppose que ce que je veux dire, c'est que lorsque la raison même pour laquelle vous avez lancé un projet disparaît, il est plus difficile de gagner en popularité, mais cela reste possible.
Bazaar est un autre SCM qui est très célèbre dans le monde GNU, mais pas tellement en dehors de cela, car il était construit avec l'intention de satisfaire la communauté GNU. Les logiciels vont souvent là où leurs créateurs veulent aller, et pas plus loin.
D'un autre côté, les SCM distribués sont clairement gagnants. Je ne vois pas beaucoup de SCM non distribués largement utilisés.
Linus Torvalds
Linus est un grand défenseur de Git et l'a fortement promu au sein du groupe linux principal pendant des années et il a grandi à partir de là. Je suppose que c'est entièrement dû à l'influence de Linus sur la communauté * nix.
Personnellement, j'utilise toujours Subversion, mais c'est par préférence plutôt que par utilité.
Le problème habituel avec le système de contrôle de version est fusion de branche.
Vous devez l'avoir essayé quand cela ne fonctionne pas fonctionne pour comprendre à quel point cela peut être douloureux et combien il est important d'avoir du travail, afin de travailler librement avec les branches.
Apprendre que Linus Torvalds a écrit git pour faire cela correctement, et que prétendument dans une situation, il a utilisé git pour fusionner douze branches ensemble à la fois, c'est un argument très convaincant pour que git soit intéressant.
J'étais dans la situation il y a environ un an où je devais choisir entre hg et git, et la fusion ci-dessus était un facteur important dans le choix de git. La seconde était que l'organisation Eclipse était passée à git, donc les outils Eclipse étaient censés être bons pour les projets Java. Avec la sortie d'Eclipse 3.7, cela s'est produit. Nous étions peut-être 6-9 mois dès le début.
Pour différents besoins, le hg peut être tout aussi utile. Sun l'a choisi pour leur VCS sur la base d'une très enquête minutieuse. Vous voudrez peut-être trouver les livres blancs et voir quels étaient leurs raisonnements.
EDIT: Remarque, je ne dis pas qu'il n'y a rien que Mercurial ne puisse faire, juste que pour Java avec Eclipse - qui est notre objectif principal - les forces du marché sont actuellement les plus fortes pour git, même sous Windows , et nous devons nous tenir sur les épaules des autres, pas sur leurs pieds.
Au lieu de dire pourquoi git ou Mercurial est meilleur et dire que c'est la seule raison pour laquelle il est populaire, je vais me concentrer sur la communauté.
Comme je souligné plus haut , la communauté Git est très bruyante et arrogante. La plupart défendront vigoureusement leur précieux programme. La plupart des guerres Git contre Mercurial que j'ai vues ont été déclenchées par des git qui se demandaient pourquoi tout le monde sur Terre n'utilisait pas le git sacré. Des sites comme whygitisbetterthanx.com montrent même cette arrogance dans l'introduction, qui est écrit pour enflammer les autres.
Je ne dis pas que tout le monde est comme ça, mais la plupart du temps quand j'ai rencontré des gens git, des sites Web pro-git et des blogs pro-git, j'avais l'impression que git était poussé dans ma gorge au lieu d'être proposé comme un DVCS viable système.
En revanche, les autres communautés DVCS ne sont pas aussi bruyantes. Je ne savais pas que Mercurial existait jusqu'à ce que je voie un "Quel est le meilleur DVCS?" question sur SO. Alors que git apparaît partout, les autres DVCS prennent du temps à trouver.
Je ne pense pas que Mercurial soit particulièrement discret. Kiln est construit sur Hg et il y a un bon support dans les IDE comme Eclipse et Netbeans depuis un certain temps maintenant.
La plupart des développeurs avec qui je parle semblent préférer le Hg en raison de la meilleure prise en charge de Windows. Si nous étions des développeurs Linux, cela pourrait être une autre histoire.
Il vous manque également "Bazaar" qui est le vrai "DVCS oublié".
Je suis certainement d'accord que Linus est un gars très charismatique et un nerd alpha presque sans égal, donc beaucoup de gens graviteraient vers Git à cause de cela. En outre, le "mythe de la création" de Git est très convaincant avec Linus travaillant pendant 6 jours pour créer Git et reposant sur le septième - ou quelque chose comme ça. Lorsqu'un produit a une histoire mémorable, il est plus facile de gagner en traction.
C'est une humble opinion, mais git pourrait obtenir tout ce battage médiatique en raison de deux paramètres:
- C'est très efficace
- C'est amusant à utiliser (d'une manière informatique très spécifique)
De plus, git a obtenu une application tueur comme github, et certains projets très populaires ont décidé de l'utiliser, ce qui lui a donné beaucoup de visibilité.
C'est principalement juste un battage médiatique auto-renforçant. Git est le plus populaire, donc il reçoit le plus de publicité, ce qui le rend plus populaire.
Git, Hg et Bzr sont tous des systèmes DVCS parfaitement bons, mais un nombre effrayant de personnes assimile DVCS à Git, et pense que toutes les belles fonctionnalités d'un DVCS sont uniques à Git. Et donc ils utilisent Git, et recommandent Git, et disent des choses comme "Git est mieux parce qu'il peut faire des fusions de poulpe" (Tout comme Bazaar), ou "Git est mieux parce qu'il est distribué" (tout comme n'importe lequel DVCS, d'où le nom), ou "Git est meilleur parce que cela rend les branchements et les fusions faciles" (encore une fois, c'est vrai pour tous les DVCS).
Malheureusement, parce que je pense que les alternatives ont également beaucoup à offrir, et je préfère que les gens choisissent Git pour ses atouts uniques, plutôt que simplement parce qu'ils pensent que DVCS == Git.
Quand quelqu'un découvre à quel point les DVCS sont intelligents, en étant pointé vers un DVCS spécifique, ils ne vont souvent pas dire aux autres "hé, les DVCS sont géniaux, vous devriez les utiliser", mais plutôt "le DVCS qui - [[# #]] i [~ # ~] appris sur les DVCS est super, vous devriez l'utiliser ".
Il y a trois facteurs à l'œuvre ici, "beta geek media", "le moment est venu" et "suivez le leader"
Beta Geek Media
Il existe un certain nombre de canaux qui discutent des "activités geek". Ils couvriraient certainement l'apparition d'un nouveau système de contrôle de version, mais ils couvrent plus git. Pourquoi? Parce que Linus Torvalds l'a écrit initialement, en a discuté publiquement et l'a utilisé comme solution à son problème bien connu avec Bitkeeper. En effet, chaque fois qu'il y a une guerre des flammes sur lkml, les médias bêta geek écriront un article à ce sujet. La discussion Git a commencé sur lkml, donc elle a eu plus de couverture que d'autres alternatives. Et les bêta-geeks qui lisent slashdot comme si c'était Variété l'ont mangé. Le résultat final de cela est que git a dix fois plus d'articles que Mercurial.
Le moment est venu
Les grands projets open source avec beaucoup de contributeurs ont des problèmes avec le contrôle centralisé des sources. À mesure que l'open source se développe et que les projets sont plus susceptibles d'avoir de nombreux contributeurs, le problème s'aggrave. Linux est probablement le projet le plus connu qui en souffre, mais il y en a beaucoup d'autres. Avec de nombreux projets atteignant ce point, une sorte de VCS avancé était nécessaire. Git, Mercurial et Bazaar ont été les grands gagnants ici. Arch et Monotone étaient juste un peu trop tôt et ont raté la vague de battage médiatique.
Suivez le guide
Les grands projets ont des followers qui vérifient et construisent le code régulièrement, même s'ils ne contribuent pas. Les abonnés se familiarisent avec les outils nécessaires pour récupérer le projet qu'ils suivent, afin que ces outils soient plus utilisés. Jetons un coup d'œil aux projets de "gros tirage" pour les trois grands DVCS:
- Git: Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
- Mercurial: Java, Mozilla, Python
- Bazar: Ubuntu, Emacs
Git a plus de projets "big draw" l'utilisant, donc plus de gens connaissent git, il y a plus de tutoriels git écrits.
Github. Github est un pionnier du codage social. Il a transformé le contrôle de version en une plate-forme sociale qui a attiré beaucoup d'attention, et il ne prend évidemment en charge que Git. Médias sociaux = plus d'adoption. Bitbucket gagne de la vapeur grâce à de nombreuses nouvelles fonctionnalités, ce qui en fait un rival probable :)
Eh bien, en fait, je pense que le battage médiatique concerne tous les DSVC ensemble.
Mais les défenseurs des git sont juste plus vocaux, souvent plus agressifs dans leurs commentaires pour être honnêtes et aiment en parler partout.
Je soupçonne Mercurial d'être largement utilisé, certainement aussi souvent que Git, peut-être plus (Microsoft et d'autres grandes entreprises l'utilisent maintenant), mais les gens qui utilisent Mercurial voulaient le plus souvent juste un DSVC qu'ils peuvent saisir rapidement, pas quelque chose sur lequel baser une religion. Ils sont donc moins vocaux et plus réactifs dans les discussions que proactifs comme certains utilisateurs de git.
On ne parle pas beaucoup de Bazaar certainement parce que seuls quelques grands projets connus l'utilisent et aucune autre grande entreprise que Canonical n'est connue pour l'utiliser. Comparez à Google (git, Mercurial, svn) et aux grands projets open source par exemple et vous pouvez voir pourquoi on n'en parle pas vraiment. Fossil est un autre qui est intéressant pour une niche de développeurs, donc je suppose qu'il est normal et bien pour eux d'être entendus uniquement par ceux qui recherchent les fonctionnalités qu'ils fournissent (comme le wiki intégré, le suivi des problèmes et le forum).
Cela étant dit, je pense que nous descendons lentement le cycle de battage médiatique et beaucoup de développeurs ayant utilisé plusieurs solutions différentes peuvent commencer à voir lequel correspond à leurs besoins.
En outre, Google Code Hosting et SourceForge autorisent désormais à la fois git et Mercurial, ce qui devient plus un choix spécifique au projet qu'auparavant lorsque vous avez choisi git en raison des fonctionnalités de GitHub.
Il n'y a pas de véritable guerre, juste une variété intéressante d'outils.
Je sais qu'il y a déjà beaucoup de réponses à cette question, mais j'ai senti que je pourrais ajouter un peu plus de perspective.
J'ai utilisé Bazaar à peu près depuis qu'il a été créé pour diverses choses. La plus grande chose pour laquelle je l'ai utilisé était le projet AllTray, pour lequel je suis (actuellement) le seul développeur et mainteneur. Le bazar est sympa. Cela fonctionne, il reste hors de mon chemin, et je n'ai presque jamais à consulter une page --help ou la page de manuel pour cela. Cela dit, il y a quelques inconvénients:
- Beaucoup de fonctionnalités qu'il possède, qui devraient sans doute faire partie du noyau VCS, ne le sont pas. Des choses comme la possibilité d'effectuer une bissection de l'historique, d'exécuter une sortie longue via un pager ou d'avoir des branches "colocalisées" (par exemple, des référentiels de style git) sont fournies sous forme de plugins.
- Beaucoup de plugins ne sont pas du tout stables. Par exemple, la fonctionnalité des branches colocalisées ne semble pas bien fonctionner côté serveur (au moins, je ne l'ai jamais fait fonctionner, elle a tendance à se tromper en disant que la branche sur le chemin donné n'existe pas lorsqu'elle est juste devant vous et vous pouvez voir la chose sanglante).
- Il n'a pas d'opération de "clonage", vous tirez les branches une à la fois. Vous devez faire un travail supplémentaire si vous voulez avoir un référentiel afin de pouvoir tirer efficacement de nouvelles branches.
- Pour certains projets, c'est douloureusement lent. Essayez parfois "bzr branch lp: mysql".
- Il manque un support solide pour les crochets; vous pouvez écrire des plugins bzr qui fournissent des hooks, mais il n'y a pas de moyen standard d'avoir des scripts de hook arbitraires côté serveur.
Je suis récemment passé à git pour le développement AllTray et j'envisage très rapidement de migrer tous mes projets vers git. Il y a un peu plus de temps passé à apprendre à connaître les cordes, mais cela semble en valoir la peine. Certaines choses que j'ai remarquées:
git cloneest une opération relativement rapide et vous donne des informations sur toutes les branches qui existent dans le référentiel que vous avez cloné.- L'ajout de référentiels distants supplémentaires est indolore, et vous pouvez donc suivre de nombreux référentiels différents qui ont plusieurs branches si vous le souhaitez.
- Le livre Pro Git est disponible en ligne et en plusieurs formats, y compris pour les lecteurs de livres électroniques - et ce n'est pas une lecture difficile .
- git semble beaucoup plus facile à étendre que Bazaar, et vous n'avez pas besoin d'utiliser une API particulière pour le faire. (NB: c'est à la fois un avantage et un inconvénient.)
- git a une bissection intégrée, et je ne saurais trop insister sur l'utilité de cette fonctionnalité.
- GitHub est plutôt sympa.
- Le système
gitosisest également assez sympa. Je ne sais même pas comment on pourrait l'implémenter autrement qu'en tant que plugin dans Bazaar, et je ne peux pas imaginer que ce serait aussi efficace.
Pour faire court: j'utilise bzr depuis très longtemps, mais git me prouve rapidement son caractère génial.
Avec git, vous avez tendance à toujours rester dans le même répertoire local lorsque vous faites du développement, et faites simplement git checkout branchname pour basculer entre les branches (j'utilise tout le temps des branches de fonctionnalités "légères", c'est donc une fonctionnalité très importante pour moi).
En regardant la documentation et les tutoriels de Mercurial, il semble que la façon préférée de traiter les différentes branches de développement est de créer de nouveaux référentiels par clonage. Ce tutoriel est un exemple.
Je pense que vous pouvez faire la même chose dans Mercurial que dans git, mais pour une raison quelconque, la documentation Mercurial (que j'ai lue) montre presque toujours une ramification en créant un clone de référentiel.
(J'utilise git quotidiennement. J'ai peu d'expérience avec Mercurial, j'ai joué avec et j'ai suivi quelques tutoriels)
Je ne sais pas combien de ces diatribes j'ai vues ces dernières semaines, mais elles semblent toutes le considérer comme un fait que Mercurial et/ou Bazaar sont objectivement meilleurs que Git. La convivialité semble être un thème commun. Oui, apprendre Git a été étonnamment difficile après avoir utilisé CVS et Subversion, mais à ce stade, je ne voudrais pas l'échanger contre un autre VCS à moins qu'il n'en constitue un autre changement de paradigme. Et pointer vers un tableau de fonctionnalités va me dire très peu de choses sur la flexibilité, l'extensibilité, la sécurité ou sans effort . Par exemple, par défaut git-diff utilise des couleurs et un téléavertisseur. Bien sûr, je peux obtenir la même chose avec diff ... | colordiff | less -R ou quelque chose, mais il devrait être évident pourquoi l'un est supérieur à l'autre.
Pour être juste, je pense que les avocats de Git contre Mercurial sont peu nombreux par rapport aux avocats de Git contre centralisés. Cependant, les raisons sont faciles à résumer:
Git est le contrôle de version pour les programmeurs. Mercurial est le contrôle de version pour les entreprises. La centralisation a été un premier essai adéquat pour inventer le contrôle de version, d'autant plus qu'il a été conçu avant la révolution des ordinateurs personnels.
Ce que j'entends par contrôle de version pour les programmeurs, c'est que les programmeurs en général préfèrent la flexibilité à la facilité d'apprentissage. Après tout, nous sommes prêts à passer des années à apprendre des langues ésotériques afin d'avoir la flexibilité de faire faire aux ordinateurs ce que les non-formés ne peuvent pas faire. Git donne aux programmeurs la flexibilité de l'utiliser comme bon leur semble, au détriment du temps nécessaire pour apprendre à utiliser cette flexibilité en toute sécurité. Il permet de mettre en place des restrictions pour appliquer les politiques, mais ne sort pas de cette façon. Notez que j'ai dit facilité de apprentissage plutôt que facilité de tilisation. Une fois que vous l'avez appris, git est aussi facile à tiliser que tout autre VCS, et souvent plus facile en raison de la vitesse et des fonctionnalités accrues.
Certains programmeurs apprennent suffisamment pour faire ce qu'ils veulent, puis refusent d'apprendre de nouvelles façons de le faire. Les entreprises embauchent et emploient un grand nombre de ces personnes, elles souhaitent donc que les modifications apportées aux outils qu’elles utilisent aient une certaine familiarité. Les entreprises veulent également que leurs programmeurs aient suffisamment de flexibilité pour faire leur travail, mais pas au point de rendre la formation ou la migration initiale difficile. C'est là que Mercurial s'intègre. Il a la plus grande puissance de git, mais un chemin de migration un peu plus facile.
Je ne pense pas qu'il soit juste de dire que git n'est populaire qu'à cause du battage médiatique ou de l'approbation de Linus. Cela représente probablement beaucoup de gens essayant cela, mais ils s'en tiennent à lui et le promeuvent parce que cela fonctionne bien pour eux, pur et simple.
Le développement de NetBSD utilise CVS et c'est tout ce qui est important.
Il a un nom plus vif et plus concis qui se prête bien aux jeux de mots.
Je cherchais récemment un système de contrôle de version pour des projets personnels, alors j'en ai essayé un tas. Je suis pratiquement analphabète sur la ligne de commande, et j'avais entendu dire que bien que les interfaces graphiques soient disponibles, Git était vraiment destiné à être utilisé via la ligne de commande, ce qui m'a rendu un peu hésitant. Honnêtement cependant, c'était ridiculement facile à ramasser, et je l'apprécie vraiment. La documentation est un facteur énorme dans l'adoption d'une nouvelle technologie, et Git a des tonnes de documentation ridiculement simple, claire et disponible. Les autres alternatives telles que SVN et Bazaar étaient excellentes, elles ne le rendaient pas aussi facile que Git. Github est également un facteur important, car il est devenu si central pour le mouvement open source en ce moment. Avoir un emplacement centralisé (ironiquement) pour échanger du code et des projets est un changement en soi en soi.
Juste mon 2 ¢ - J'ai choisi git plutôt que les alternatives parce qu'il est écrit en C plutôt que dans un langage radtool ou un langage de haut niveau trop académique. Les avantages sont que c'est rapide et efficace et que je peux réellement RTFS si je rencontre des bugs ou des comportements que je ne peux pas expliquer. Il permet également d'utiliser sur de minuscules environnements de développement auto-hébergés qui n'incluent pas de gigantesques interprètes/runtimes, ce qui signifie que je peux directement tirer d'un dépôt git et compiler sur de tels systèmes plutôt que d'avoir à chercher la dernière source ailleurs et rsync.
Vous pourriez être intéressé de lire pourquoi le projet de bureau GNOME a choisi git plutôt que hg et bzr, quand il a décidé de passer de svn il y a quelques années. Il y a eu beaucoup de discussions religieuses animées en cours de route, bien sûr, mais cela page Wiki GNOME résume bien les avantages et les inconvénients tels qu'ils s'appliquent à cette communauté particulière.
Sans parler de Apple est maintenant impliqué dans la transmission à la communauté Objective C, si vous avez créé une nouvelle application dans Xcode 4 récemment, vous auriez remarqué qu'il vous demande automatiquement si vous aimerait faire un repo Git.
Certes, Xcode 4 n'existe que depuis quelques mois et n'influence pas le succès précédent de Gits, mais nous savons tous à quel point Apple peut faire avancer les choses en peu de temps).