Pourquoi Git a-t-il eu autant de battage publicitaire? … Tandis que d'autres ne le font pas? [fermé]

Au cours des dernières années, le battage publicitaire autour de Git a fortement augmenté. Tout le monde connaît Git, personne ne connaît les alternatives.

D'autres comme Mercurial semblent passer inaperçus. Les deux ont été publiés en 2005 et offrent des fonctionnalités similaires. En outre, Mercurial est généralement considéré comme étant plus facile à utiliser, plus intuitif et bénéficiant depuis longtemps de meilleures interfaces utilisateur. Par conséquent, on peut supposer que ce serait une alternative populaire, en particulier pour les débutants en contrôle de version distribué. Pourtant, cela semble inconnu à la plupart des gens, contrairement à Git qui a très bien réussi.

Le but de cet article est d'essayer de mieux comprendre ce phénomène.

Comment se fait-il que Git obtienne toute la part du gâteau? Ont-ils en quelque sorte utilisé un meilleur marketing? Est-ce parce que sa communauté est plus ... heu ... "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 sont un facteur important. Il est important pour les personnes de pouvoir héberger leurs contenus quelque part et GitHub est un excellent service.

Pour mercurial, il n'y avait pas de tel service lorsque DVCS est devenu populaire (du moins aucun que je sache). Vous avez Bitbucket maintenant et probablement d’autres, mais GitHub est là depuis un certain temps, il est bien connu et cela s’améliore de mieux en mieux.

Je vois beaucoup de réponses à cette question qui s'appuient sur les sentiments de l'auteur lorsqu'il a entendu parler de l'un ou l'autre SMC. D'autres disent que tout était pur hasard. Je crois que la chance peut être retracée dans l'histoire.

Je vais parler de l'histoire.

Git et Mercurial ont été créés simultanément afin de résoudre le même problème. À cette époque, le noyau Linux était obligé de cesser d'utiliser BitKeeper , un SCM distribué exclusif qu'il utilisait depuis 3 ans. La raison en est 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 de la communauté Linux l'avait fait évoluer.

Linus Torvalds, insatisfait de ce qui existait déjà, a ensuite commencé à travailler sur un tout nouveau SCM qu'il appellerait bientôt Git. Peu de temps après, Matt Mackall a lancé le projet Mercurial pour des raisons similaires.

Après avoir mis au point 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 (elle-même âgée de seulement deux semaines). Linus envisagea de l'utiliser au lieu de Git pour le développement du noyau, mais abandonna l'idée lorsqu'il réalisa que Mercurial utilisait Changeset pour enregistrer les modifications de révision . Il craignait que cela soit trop proche de la façon dont BitKeeper travaillait, et il ne voulait certainement rien qui puisse faire dire à quelqu'un: "Ils ont construit un clone BitKeeper".

Git était donc utilisé pour le développement du noyau au lieu de Mercurial, mais les deux étaient pertinents sur le plan technique. Le résultat final est que Git a commencé par être réellement utilisé là où il avait été conçu, alors que Mercurial n'a pas été aussi rapide que sa première grande utilisation de FOSS. 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 a été utilisé pour de grands projets dans le monde réel.

Aujourd'hui, ils sont tous 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 que Mercurial l’utilisait depuis longtemps. Beaucoup de projets vraiment grands et célèbres utilisent soit.

Je suppose que ce que je veux dire, c’est que lorsque la raison même pour laquelle vous avez démarré un projet disparaît, il est plus difficile de gagner en popularité, mais cela reste réalisable.

Bazaar est un autre SCM très célèbre dans le monde GNU, mais pas tellement en dehors de cela, car il a été construit dans le but de satisfaire la communauté GNU. Les logiciels vont souvent là où leurs créateurs veulent aller, et pas plus loin.

D'autre part, les GDS distribués sont clairement gagnants. Je ne vois pas beaucoup de GDS non distribués largement utilisés.

Linus Torvalds

Linus est un ardent défenseur de Git et l’a fortement promu au sein du groupe Linux central pendant des années. 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 la fusion de branches .

Vous devez avoir essayé quand cela ne fonctionne pas pour comprendre à quel point cela peut être douloureux et à quel point il est important de travailler pour pouvoir travailler librement avec des branches.

En apprenant que Linus Torvalds a écrit git pour faire cela correctement, et que dans une situation, il aurait utilisé git pour fusionner douze branches à la fois, c’est un argument très convaincant pour que git soit intéressant.

Il y a environ un an, je me trouvais dans une situation où je devais choisir entre hg et git, et la fusion ci-dessus était un facteur important dans le choix de git. La seconde est que l’organisation Eclipse est passée à git. L’outillage Eclipse devait donc être utile pour les projets Java. Avec la sortie d'Eclipse 3.7, cela s'est produit. Nous étions peut-être 6 à 9 mois plus tôt.

Pour des besoins différents, hg pourrait être tout aussi utile. Sun a choisi pour leur VCS basée sur 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 que Mercurial ne peut rien faire, mais pour Java avec Eclipse - notre principal objectif - les forces du marché sont actuellement les plus puissantes pour git, même sous Windows, et nous devons rester sur nos épaules des autres, pas leurs pieds.

Au lieu de dire pourquoi git ou mercurial est meilleur et d’en dire que c’est la seule raison pour laquelle il est populaire, je vais me concentrer sur la communauté.

Comme je l'ai souligné plus tôt , la communauté Git est très bruyante et arrogante. La plupart défendront vigoureusement leur précieux programme. La plupart des guerres entre Git et Mercurial que j'ai vues ont été lancées par des git, qui se demandaient pourquoi tout le monde sur Terre n'utilisait pas le saint git. Des sites comme whygitisbetterthanx.com montrent même cette arrogance dans l'introduction, qui est écrite pour incendier les autres.

Je ne dis pas que tout le monde est comme ça, mais la plupart du temps, lorsque je rencontrais des git, des sites Web pro-git et des blogs pro-git, je me sentais comme si on m'avait poussé dans la gorge au lieu de le proposer 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 avant de voir un "Quel est le meilleur DVCS?" question sur SO. Alors que git apparaît partout, les autres DVCS mettent du temps à trouver.

Je ne pense pas que Mercurial soit particulièrement discret. Kiln est construit sur Hg et les IDE comme Eclipse & Netbeans sont bien supportés depuis un certain temps.

La plupart des développeurs avec lesquels je parle semblent préférer Hg en raison du meilleur support Windows. Si nous étions des développeurs Linux, la situation serait peut-être différente.

Vous manquez également "Bazaar" qui est le véritable "DVCS oublié".

Je conviens certainement que Linus est un type très charismatique et un alpha nerd presque sans égal, de sorte que beaucoup de gens aimeraient bien Git à cause de cela. En outre, le "mythe de la création" de Git est très convaincant. Linus a passé six jours à travailler à la création de Git et à se reposer le septième - ou quelque chose du genre. Quand un produit a une histoire mémorable, il est plus facile de gagner du terrain.

C'est une opinion humble, mais git pourrait avoir tout ce battage publicitaire à cause de deux paramètres:

1. C'est très efficace
2. C'est amusant à utiliser (à la manière d'un informaticien très spécifique)

De plus, git a eu une application géniale comme github, et des projets très populaires ont décidé de l'utiliser, ce qui lui a donné beaucoup de visibilité.

Il y a trois facteurs à l’œuvre ici, «beta geek media», «le moment est propice» et «suivez le leader»

Beta Geek Media

Il existe un certain nombre de chaînes qui discutent des "activités geek". Ils couvriraient certainement l’apparence d’un nouveau système de contrôle de version, mais ils en couvriraient davantage. Pourquoi? Parce que Linus Torvalds l’a écrit au début, en a débattu publiquement et l’a utilisée comme solution à son problème très médiatisé avec Bitkeeper. En effet, chaque fois qu'il y a une guerre de flammes sur Lkml, les médias beta geek écriront un article à ce sujet. La discussion entre git a commencé sur lkml, elle a donc eu plus de couverture que d’autres alternatives. Et les geeks bêta qui lisent slashdot comme si c'était Variety en mangeaient. Le résultat final est que git a dix fois plus d'articles que mercurial.

Le moment est venu

Les grands projets open source ayant de nombreux contributeurs rencontrent des problèmes de contrôle centralisé des sources. À mesure que l’open source se développe et que les projets ont de plus en plus de chances 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 manqué le battage médiatique.

Suivez le guide

Les gros projets ont des suiveurs qui vérifient et construisent le code régulièrement, même s'ils ne contribuent pas. Les suiveurs se familiarisent avec les outils nécessaires pour récupérer le projet qu'ils suivent, afin que ces outils deviennent plus utiles. Jetons un coup d'oeil aux projets "grand tirage au sort" 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 "grand tirage" qui l'utilisent, donc plus de gens connaissent Git, plus il y a de tutoriels écrits.

Il s'agit principalement d'un battage publicitaire qui se renforce soi-même. Git est le plus populaire, il reçoit donc le plus de publicité, ce qui le rend de plus en plus populaire.

Git, Hg et Bzr sont de très bons systèmes DVCS, mais un nombre effrayant de personnes associent DVCS à Git et pensent que toutes les fonctionnalités attrayantes d’un DVCS sont uniques à Git. Et donc ils utilisent Git, et recommandent Git, et disent des choses comme "Git est meilleur parce qu'il peut faire de la fusion de pieuvre" (de même que Bazaar), ou "Git est meilleur parce qu'il est distribué" (comme tout DVCS, d'où le nom ), ou "Git est meilleur parce que cela facilite la création de branches et la fusion" (encore une fois, cela est vrai pour tous les DVCS).

Malheureusement, je pense que les alternatives ont également beaucoup à offrir, et je préférerais 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 se dirigeant 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 que je appris à propos de DVCS est génial, vous devriez l’utiliser ".

Github. Github est un pionnier du codage social. Il a transformé le contrôle de version en une plate-forme sociale qui a beaucoup attiré l'attention, et il ne fait évidemment que supporter Git. Médias sociaux = plus grande adoption. Bitbucket gagne du terrain bien qu’il obtienne de nombreuses nouvelles fonctionnalités, ce qui en fait un rival probable :)

En fait, je pense que le battage médiatique concerne toutes les rencontres DSVC.

Mais les défenseurs des droits sont simplement plus virulents, souvent plus agressifs dans leurs commentaires pour être honnêtes et aiment en parler partout.

Je pense que Mercurial sera largement utilisé, certainement aussi souvent que git, peut-être plus (Microsoft et d’autres grandes entreprises l’utilisent maintenant), mais les utilisateurs de Mercurial voulaient le plus souvent simplement un DSVC, qu’ils peuvent saisir rapidement, et non pas sur quoi fonder une religion. Donc, ils sont moins vocaux et plus réactifs dans les discussions que les discussions proactives comme certains utilisateurs git.

On ne parle certainement pas beaucoup de Bazar, car seuls quelques grands projets connus l'utilisent et aucune autre grande entreprise que Canonical n'est connue pour l'utiliser. Comparez-le à Google (git, mercurial, svn) et à de grands projets open-source, par exemple, et vous comprendrez pourquoi on n'en parle pas vraiment. Fossil est une autre source d’intérêt pour une niche de développeurs, je suppose donc qu’il est normal que ceux-ci soient entendus 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 commençons lentement à perdre du rythme et que beaucoup de développeurs ayant utilisé plusieurs solutions différentes peuvent commencer à voir laquelle correspond à leurs besoins.

De plus, Google Code Hosting et SourceForge permettent désormais à la fois git et mercurial. Il est donc devenu un choix spécifique à un projet qu'auparavant lorsque vous avez choisi git en raison de ses fonctionnalités GitHub.

Il n'y a pas de vraie guerre, juste une variété intéressante d'outils.

Je sais qu'il y a déjà beaucoup de réponses à cette question, mais je pensais pouvoir ajouter un peu plus de perspective.

J'ai utilisé Bazaar à peu près depuis qu'il a été créé pour diverses choses. La chose la plus importante 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, cela reste en dehors de mon chemin et je n’ai presque jamais à consulter une page --help ou la page de manuel correspondante. Cela dit, il y a quelques inconvénients:

1. La plupart de ses fonctionnalités, qui devraient sans doute faire partie du VCS principal, ne le sont pas. Des fonctionnalités telles que la possibilité d'effectuer une bissection de l'historique, d'exécuter une sortie longue via un pageur ou d'avoir des branches «colocalisées» (par exemple, des référentiels de style git) sont fournies sous forme de plugins.
2. Beaucoup de plugins ne sont pas si stables. Par exemple, la fonctionnalité de colocalisation de branches ne semble pas bien fonctionner côté serveur (du moins, je ne l’ai jamais fait fonctionner, elle a tendance à donner une erreur en disant que la branche au chemin donné n’existe pas juste en face de vous et vous pouvez voir la chose sanglante).
3. Il n’a pas d’opération «clone», vous tirez les branches une à la fois. Vous devez faire un travail supplémentaire si vous souhaitez disposer d'un référentiel afin de pouvoir extraire efficacement de nouvelles branches.
4. Pour certains projets, c'est extrêmement lent. Essayez «bzr branch lp: mysql» de temps en temps.
5. Il manque un fort soutien pour les crochets; vous pouvez écrire des plugins bzr qui fournissent des hooks, mais il n’existe pas de méthode standard pour avoir des scripts de hook arbitraires côté serveur.

Je suis récemment passé à git pour le développement AllTray et envisage très rapidement de migrer tous mes projets vers git. Il y a un peu plus de temps passé à apprendre à connaître les ficelles du métier, mais cela semble en valoir la peine. Certaines choses que j'ai remarquées:

1. git clone est une opération relativement rapide et vous donne des informations sur toutes les branches présentes dans le référentiel que vous avez cloné.
2. L'ajout de référentiels distants supplémentaires est simple et vous permet donc de suivre, si vous le souhaitez, de nombreux référentiels comportant plusieurs branches.
3. Le livre Pro Git est disponible en ligne et dans plusieurs formats, y compris pour les lecteurs de livres électroniques - et sa lecture n’est pas difficile.
4. 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.)
5. git a une bissection intégrée, et je ne saurais trop insister sur l’utilité de cette fonctionnalité.
6. GitHub est plutôt sympa.
7. Le gitosissystème est également très sympa. Je ne sais même pas comment on pourrait mettre en œuvre cela autrement que comme un plugin dans Bazaar, et je ne peux pas imaginer que cela serait aussi efficace.

Longue histoire courte: j'ai utilisé bzr pendant très longtemps, mais git me prouve rapidement son caractère génial.

En utilisant git, vous avez toujours tendance à rester dans le même répertoire local lorsque vous faites du développement, et vous vous contentez git checkout branchnamede changer de branche (j'utilise tout le temps des fonctionnalités "légères", donc c'est une fonctionnalité très importante pour moi).

En examinant la documentation et les didacticiels Mercurial, il semble que la manière privilégiée de traiter différentes branches du développement consiste à 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 et dans Git, mais pour une raison quelconque, la documentation de Mercurial (que j'ai lue) montre presque toujours des ramifications 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 suivi quelques tutoriels)

Je ne sais pas combien de commérages de ce genre j'ai vu ces dernières semaines, mais ils semblent tous considérer le fait que Mercurial et / ou Bazaar sont objectivement meilleurs que Git. La convivialité semble être un thème commun. Oui, apprendre Git était étonnamment difficile après l'utilisation de CVS et de Subversion, mais pour le moment, je ne voudrais pas l'échanger contre un autre VCS, à moins que cela ne représente un changement de paradigme . Et pointer vers un tableau de fonctionnalités me dira très peu de savoir à quel point il est flexible, extensible, sécurisé et sans effort . Par exemple, utilise par défaut git-diff des couleurs et un pager. Bien sûr, je peux obtenir la même diff ... | colordiff | less -Rchose ou quelque chose du genre, mais il devrait être évident pourquoi l’un est supérieur à l’autre.

Pour être juste, je pense que les avocats git vs. mercurial sont peu nombreux et comparés aux avocats git vs centralisés. Cependant, les raisons sont faciles à résumer:

Git est un contrôle de version pour les programmeurs. Mercurial est un contrôle de version pour les entreprises. Centralisé était un premier essai adéquat pour inventer le contrôle de version, d'autant plus qu'il avait é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 privilégient la flexibilité à la facilité d'apprentissage. Après tout, nous sommes disposés à passer des années à apprendre les langues ésotériques afin de pouvoir faire en sorte que les ordinateurs fassent ce que les non-initiés ne peuvent pas. Git donne aux programmeurs la flexibilité de l’utiliser à leur guise, au prix de perdre plus de temps à apprendre à utiliser cette flexibilité en toute sécurité. Cela permet de mettre en place des restrictions pour appliquer les politiques, mais cela ne sort pas de la boîte. Notez que j'ai parlé de facilité d' apprentissage plutôt que de facilité d' utilisation . Une fois que vous l’apprenez, git est aussi facile à utiliser que tout autre VCS, et souvent plus facile en raison de sa vitesse et de ses fonctionnalités accrues.

Certains programmeurs en apprennent assez pour faire ce qu'ils veulent, puis résistent pour 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 présentent un certain degré de familiarité. Les entreprises souhaitent également que leurs programmeurs disposent de suffisamment de flexibilité pour effectuer leur travail, sans toutefois rendre la formation ou la migration initiale difficile. C'est là qu'intervient mercurial. Il a la majeure partie de la puissance de git, mais une voie de migration un peu plus facile.

Je ne pense pas qu'il soit juste de dire que git n'est populaire que pour le battage publicitaire ou l'approbation de Linus. Cela explique probablement pourquoi de nombreuses personnes l’ essaient , mais ils s’y tiennent et en font la promotion, car cela leur convient parfaitement, purement et simplement.

Le développement de NetBSD utilise CVS et c'est tout ce qui compte.

Il a un nom plus vif, plus pithy qui se prête bien aux jeux de mots.

Récemment, je recherchais un système de contrôle de version pour des projets personnels, alors je viens d’en essayer plusieurs. Je suis pratiquement illettré sur la ligne de commande et j'avais entendu dire que, bien que des 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 à prendre en main et je l'apprécie vraiment. La documentation est un facteur déterminant dans l’adoption d’une nouvelle technologie, et Git dispose de tonnes de documents ridiculement simples, clairs et disponibles. Les autres alternatives telles que SVN et Bazaar étaient excellentes, elles ne rendaient tout simplement pas cela aussi facile que Git. Github est également un facteur important, car il est devenu si central pour le mouvement open source pour le moment. Avoir un emplacement (ironiquement) centralisé pour échanger du code et des projets est un jeu en soi.

Juste mes 2 ¢ - j'ai choisi git plutôt que les alternatives parce que c'est écrit en C plutôt que dans un langage radical ou un langage trop académique de haut niveau. L'avantage est 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 est également possible d'utiliser des environnements de développement auto-hébergés minuscules qui n'incluent pas d'interprètes / runtimes gigantesques, ce qui signifie que je peux directement extraire d'un dépôt git et compiler sur de tels systèmes plutôt que de devoir extraire la dernière source ailleurs et rsync.

Vous serez peut-être intéressé de lire pourquoi le projet de bureau GNOME a choisi git plutôt que hg et bzr, alors qu'il avait décidé de quitter svn il y a quelques années. Bien sûr, il y a eu beaucoup de discussions religieuses houleuses au cours de ce processus, mais cette page du wiki de GNOME résume bien les avantages et les inconvénients de leur application à cette communauté.

Sans compter qu'Apple s'est impliqué dans la transmission du message à la communauté objective c, si vous avez récemment créé une nouvelle application dans Xcode 4, vous auriez remarqué qu'il vous demande automatiquement si vous souhaitez créer un dépôt Git.

Certes, Xcode 4 n'existe que depuis quelques mois et n'influence en rien sur le succès précédent de Gits, mais nous savons tous à quel point Apple peut créer des choses en un temps record.

Je suis en train de passer de hg (kiln) à git (github). J'ai utilisé le four depuis environ un an maintenant. Pour moi, l'hg n'a pas d'inconvénient. Je peux faire tout ce que je dois faire. Donc c'est génial.

Pourquoi est-ce que j'utilise maintenant?

Il n'y a que trois raisons pour le moment.

1. gitHub offre des idées géniales qui sont géniales
2. gitHub offre d'excellentes fonctionnalités sociales
3. Lors des présentations et des ateliers pour les développeurs, j'ai toujours publié mes exemples sur hg et git. Sur git j'ai environ 10 fois plus de visiteurs que sur hg !!

Je pense que le troisième est le plus important.

Thorsten

La chance pure, je suppose, jusqu'à présent presque impossible de prouver pourquoi quelque chose a fonctionné et d'autres pas. Linus peut construire autre chose de spectaculaire et sans succès.