La popularité de Git/Mercurial/Bazar vs qui de recommander [fermé]

en se basant sur le nombre de questions sur ce site pour ces trois systèmes de contrôle de version distribués, il semble que Git soit

  1. est plus populaire, ou
  2. est plus difficile( nécessitant donc plus de questions), ou
  3. a plus de caractéristiques (nécessitant donc plus de questions).

ou très probablement une combinaison des trois. (Disons que la popularité sur ce site équivaut à la popularité.) Voici les numéros:

enter image description here

il n'est pas entièrement satisfaisant de pouvoir choisir entre trois produits libre concurrence mais largement équivalents. Personnellement, J'utilise Git et je suis bien avec les deux autres. Mais quand il s'agit de recommander un système plutôt que les autres, j'aimerais poser la question suivante: pouvons-nous commencer à en recommander un en toute sécurité?

commentaires de à la mi-2009 : La popularité historique récente de Subversion est clairement reflétée par le nombre de questions, indiquant au moins un petit basculement des échelles vers Git sur le Mercurial ou Bazar.

commentaires de mi-2010 : Regardez cette énorme augmentation relative des nombres mercuriels. De toute évidence, seuls deux points de données ne sont pas suffisants pour montrer une tendance, mais il semble que Git et Subversion soient largement retranchés, Mercurial a vu beaucoup de croissance, et Bazaar est resté relativement calme.

bref commentaire, mi-2011 : On peut appeler Git le gagnant? :) Non, j'accepte l'argument que le nombre de questions n'est pas équivalent à la popularité. Mais les nombres sont forts.

Code pour reproduire le tracé ci-dessus: 

import datetime as dt
import matplotlib.pyplot as plt


dates = [
    "01/06/2009",
    "01/07/2010",
    "01/07/2011",
    "01/07/2012",
    "01/07/2013",
    "01/07/2014",
    "01/07/2015",
    "01/07/2016",
    "01/06/2017",
    "28/08/2018",
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]

git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525]
mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765]
bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539]

ax = plt.gca()

ax.grid()
plt.plot(x, git, label="[git]")
plt.plot(x, svn, label="[svn]")
plt.plot(x, mercurial, label="[mercurial]")
plt.plot(x, bazaar, label="[bazaar]")
plt.gcf().autofmt_xdate()
plt.ylim(0)

plt.legend()

# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")
138
demandé sur Will Robertson 2009-06-15 15:38:45

11 réponses

Mise À Jour Novembre 2011:

Git est maintenant beaucoup plus mature par rapport à 2009:

  • smart http est désormais supporté, ce qui signifie que vous pouvez proposer à votre client https le protocole pull/clone et push , avec une authentification capable d'interfacer avec un LDAP (important pour l'utilisateur dans une entreprise)
  • une couche d'autorisation mature existe maintenant avec la Gitolite , ce qui signifie que vous pouvez fournir l'isolement pour le dépôt" confidentiel " (encore une fois, important pour les grandes entreprises).
  • le soutien de fenêtres qui était déjà là en 2009, va toujours fort, et TortoiseGit est assez stable
  • l'intégration avec IDE comme Eclipse est en cours (la plupart des projets Eclipse sont maintenant sur GitHub)

cependant, l'installation de Git dans un l'environnement n'est pas anodin:

Voir " Distribué Systèmes de Contrôle de Version et de l'Entreprise - un Bon mélange? "

un point constamment omis est:

ils sont différents dans leur nature.

  • SVN est un RÉVISION (c'magasins de la branche et de marque pas cher copie seulement! Fusion de soutien est pas très efficace), et il est centralisé.
  • Mercurial ou bazaar sont FILE VCS (ils stockent des versions de files ), et distribué.

    Arne Babenhauserheide modifie celui pour Mercurial en soulignant que Mercurial modèle D'histoire pistes contenu-changements , avec file-chemins réutilisés dans la couche de stockage pour optimiser système de fichiers d'accès.
  • Git, et qui est très difficile à saisir , est un "1519560920 contenu VCS (il stocke delta de contenu , pas le fichier lui-même: deux fichiers avec le même contenu ne sera stocké qu'une seule fois)

qui signifie:

  • si vous avez un simple flux de travail de fusion , dans un seul développement emplacement, coller avec SVN
  • si vous avez plusieurs places de développement, un VCS distribué est plus adapté.
  • si vous avez un workflow de fusion complexe , n'importe quel VCS moderne est meilleur que SVN qui lutte pour garder les informations de fusion aux bons endroits pendant des années. Il dépend alors des outils (Mercurial a un support Windows plus avancé par exemple)
  • si vous avez principalement un fichier texte et pas trop de binaire fichiers, Git est excellent, à condition que vous êtes au courant de ses limites .
115
répondu VonC 2018-05-14 09:34:43

vu le nombre de questions sur ce site pour ces trois systèmes de contrôle de version distribués, il semble que Git soit

  1. est plus populaire, ou
  2. est plus difficile (nécessitant donc plus de questions), ou
  3. présente plus de caractéristiques (nécessitant donc plus de questions).

  1. à propos de SCM popularity -- voir la question suivante: y a-t-il des statistiques de popularité / usage disponibles pour les systèmes gratuits RCS/SCM/VCS? . Ici, nous avons des questions comme quel ensemble de fichiers ignorer à utiliser pour le type de projet spécifique, qui sont agnostiques SCM, mais sont demandés pour Git( et en utilisant la balise "git"), parce que c'est ce qui question utiliser.

  2. à propos de Git étant plus difficile (et donc ayant plus de questions à propos de ON SO) -- certainement Git a plus forte courbe d'apprentissage. Il utilise aussi peu de concepts (tout à fait) uniques, comme la zone de transit (l'index), ou toutes les branches étant égales, qui sont responsables de son pouvoir, mais peuvent être difficiles à obtenir droit au début (surtout si l'un vient d'autres SCM). Aussi l'INTERFACE utilisateur de Git pas tout à fait cohérent (bien qu'il s'améliore), parce qu'il a été développé plutôt que développé; qui est responsable de sa puissance, mais pourrait conduire à l'interface utilisateur sous-optimale.

  3. à propos de Git ayant plus de fonctionnalités -- vous devriez vérifier combien de questions sont ainsi sur les fonctionnalités avancées / peu communes de git. Vous devez être conscient cependant que les projets open source empruntent des idées les uns aux autres, ou avoir des fonctionnalités similaires développées indépendamment: un exemple serait de trouver des bogues en bisectant (cherchant) l'historique de commit qui a introduit le bogue qui a été (pour autant que je sache) développé d'abord dans Git, puis implémenté comme plugin dans Bazaar, et première extension et actuellement fonctionnalité de base dans Mercurial. Une autre serait de interactif la sélection de fragments de changements de commettre, inspiré par Darcs comportement. Une autre serait l'idée de faisceau de Git, emprunté à un concept similaire dans Mercurial.

  4. une autre possibilité de source de plus grand nombre de question pourrait être manque de bonne documentation ... bien qu'il s'améliore de nos jours avec Git Manuel de L'utilisateur (distribué avec Git) et Git Community Book (trouvé sur la page d'accueil Git). Il y a encore ce mème persistant que Git possède une documentation pire que, disons, Subversion avec son Version Control with Subversion (aussi connu sous le nom svnbook ) et Mercurial: The Definitive Guide (aussi connu sous le nom hg-book )... et les gens ne lisent pas la documentation avant de poser des questions sur StackOverflow, parfois.

Il n'est pas entièrement satisfaisante de trois concurrents, mais largement équivalent open source de produits à choisir de. Personnellement, J'utilise Git et je suis bien avec les deux autres. Mais quand il s'agit de recommander un système plutôt que les autres, j'aimerais poser la question suivante: pouvons-nous commencer à en recommander un en toute sécurité?

Eh bien, Git et Mercurial ont été développés indépendamment à partir presque en même temps dans la réponse de mettre fin à la licence libre pour BitKeeper pour l'utilisation par les développeurs du noyau Linux, comme un remplacement pour elle. Subversion était hors de question car centralisé SCM, avec un manque de support (à ce moment-là) dans le noyau pour le suivi des fusions, ce qui le rendait totalement inadapté au modèle de développement largement distribué du noyau Linux. Bazaar était probablement trop lent (au moins à l'époque), et un peu centralisé (je suppose).

Git est plus puissant( à mon avis), Mercurial est plus simple (à l'avis des gens) et un peu plus portable (Python); Git est scriptable et est basé sur un modèle de données permettant des réimplementations indépendantes (voir par exemple JGit, git écrit en Java), tandis que Mercurial a des fixations Python pour écrire des extensions, et est basé en grande partie sur L'API permettant de modifier le format de dépôt sous - jacent (revlog-revlog-ng)... mais c'est juste ma supposition. Ils remplissent des niches légèrement différentes.

de plus, n'avoir pas le choix n'est-il pas considéré comme une bonne chose? Nous avons KDE et nous avons GNOME et XFCE (et d'autres gestionnaires de fenêtres et environnements de bureau); nous avons Emacs et Vim (et d'autres éditeurs de programmeurs); nous avons rpm-basé (par exemple Fedora Core, Mandriva, SuSE) et des distributions basées sur deb (Debian, Ubuntu) et tgz (Slackware) et des distributions basées sur les sources (Gentoo); nous avons des distributions OpenOffice.org ... et nous avons Git, Mercurial et Bazaar.

47
répondu Jakub Narębski 2017-05-23 12:02:20

j'utilise et je recommande mercurial

  • plutôt que subversion car il supporte le développement distribué. Je peux travailler sur plusieurs machines et m'engager localement. Vous ne pouvez pas faire cela avec subversion, du moins pas sans somersaults comme des dépôts supplémentaires
  • plutôt que bazaar parce que le support Windows de bazaar est ... bien.
  • plutôt que git parce que c'est a) plus simple à apprendre et à utiliser et b) soutien de windows est beaucoup mieux
20
répondu Rad 2009-06-15 12:30:53

d'après mon expérience, à en juger par le nombre de questions, la comparaison entre git et Mercurial est nettement faussée. La raison est double:

  1. regardez hg update --help versus git checkout -h et git --help checkout . Avec Mercurial j'ai trouvé des questions qui ne sont pas répondues par quelques regards à hg help .

  2. cochez la case Mercurial Wiki - si vous besoin d'aide , vous aurez probablement trouver là , y compris de nombreux Tipps et astuces: http://mercurial-scm.org/wiki/TipsAndTricks

15
répondu Arne Babenhauserheide 2018-05-14 09:22:33

[NOTE: avec la version 1.7 de Subversion, le premier paragraphe de ma réponse ci-dessous est dépassé, car Subversion ne crée qu'un seul paragraphe.svn " folder dans le dossier de base, comme les autres maintenant.]

l'un des avantages des trois par rapport à subversion est qu'il ne crée pas l'équivalent d'un ".svn" dossier dans chaque dossier du projet. Généralement, il existe un seul (".hg",".bzr" ou ".git") dans le dossier de base. Cela seul peut être une bonne raison d'utiliser l'un des même si vous utilisez un modèle de dépôt centralisé. (Mis à part: en fait, j'utilise souvent svk comme client svn lorsque j'utilise un dépôt svn juste pour cette fonctionnalité (linux seulement, svk n'est pas bon sous windows)).

bien sûr, l'un des avantages de subversion est que vous n'avez pas à vérifier l'intégralité du projet si vous n'avez besoin que d'un de ses sous-dossiers.

14
répondu Evan 2012-02-08 09:57:18

Canonical (Ubuntu) les pistes "1519120920 logiciel en utilisation pour leur distro, donc il n'y a pas besoin de s'appuyer sur Stack Exchange question compte pour mesurer la popularité. Cependant, comme d'autres l'ont fait remarquer, cela ne fait que suivre les utilisateurs Ubuntu et les utilisations canoniques (Ubuntu) et recommande bzr (biais d'échantillon). Néanmoins... 

            2011    2011    2011           
Package     Aug 3   Sep 29  Dec 9   Change 
------      ------  ------  ------  ------ 
git-core    3647    3402    3236    -11%   
bzr         4975    5286    6070    +22%   
mercurial   3411    3387    3461     +1%

le déclin des votes pour le paquet git-core me fait penser que j'ai fait quelque chose de mal comme grep ed the wrong nom du paquet de la table de popularité ubuntu. Ou peut-être même que ce comptage de "voix" est lié à des installations et non à l'utilisation réelle du logiciel.

voici quelques Données historiques pour la tendance. J'ai utilisé les statistiques <install> plutôt que <vote> D'Ubuntu dans ce tableau, mais il montre une poussée de croissance dans Bazaar et Mercurial à partir de 2011. Néanmoins, bzr était derrière git en 2011, mais les récentes statistiques de 2011 montrent qu'il est passé git total des instances installées (sur Ubuntu). 

        June    Aug     Dec     Growth  Oct   Growth
        2010    2011    2011            2013 
----    -----   ----    ----    ------  ----  ------
git      94k    159k    171k      80%   165k   -3.5%
bzr      52k    121k    135k     160%   170k   26.0%
hg       36k     68k     75k     110%    95k   26.7%

Discalaimer: J'ai utilisé bzr sur Ubuntu jusqu'en 2012 quand j'ai travaillé sur des équipes qui ont utilisé git exclusivement. Bzr joue bien avec tous les autres VCSes, vous permettant d'utiliser une syntaxe de ligne de commande BZR cohérente et intuitive. J'ai opté pour git pour des raisons sociales plutôt que techniques.

10
répondu hobs 2013-10-11 17:50:44

depuis l'origine du codage social avec Git à GitHub , Git semble avoir attiré beaucoup d'adeptes.

7
répondu Alan Haggai Alavi 2009-06-15 11:51:47

la raison pour laquelle git a autant d'utilisateurs est que le noyau Linux l'utilise, donc si vous voulez faire du développement Linux, vous utilisez git.

comme tant de gens sont impliqués dans git, je recommande d'utiliser git, simplement en raison de la plus grande base d'utilisateurs. En fait, les chiffres que vous montrez ci-dessus en sont un signe clair.

quant à la difficulté, tout le contrôle de version est difficile, en particulier le type distribué. SVN et CVS n'ont pas été très faciles (pour moi à moins) au premier coup d'œil. C'est juste une partie de la courbe d'apprentissage nécessaire pour s'habituer à un système de contrôle de version.

EDIT: puisque vous avez ajouté une référence à subversion, je me suis dit que j'y répondrais. Je pense que la plupart des gens utiliseront svn parce qu'il a toutes sortes d'interfaces graphiques pour lui. En général, les gens détestent utiliser la ligne de commande, y compris certains développeurs. Git ne fonctionne généralement pas très bien sur Windows non plus (ou du moins pas aussi facilement). Puisque beaucoup de gens sont Windows, cela tue le nombre d'utilisateurs potentiels.

en outre, je pense que les concepts de SVN sont un peu plus faciles à saisir puisque svn utilise un dépôt central plutôt qu'un système distribué. Il est plus facile de comprendre, " voici la grande montagne de code, s'il Vous Plaît ajouter votre code ici," que "voici un peu de code, le mien pourrait être différent du sien, le sien du sien, mais vous pouvez ajouter quelque chose si vous le souhaitez."

À mon avis, svn a un bien meilleur système de ensemble de la documentation. la documentation de git est ciblée sur un niveau un peu plus élevé de connaissance (du Programme, pas une intelligence de programmeurs) et donc logique après que vous utilisez le système, mais au premier départ, il ressemble juste à un tas de gobeldy-gook.

dans l'ensemble, je pense que svn est et sera toujours plus répandu parce que ses concepts généraux d'exploitation sont plus faciles à comprendre, les outils sont faciles à utiliser, et il a un soutien merveilleux sur Windows.

permettez-moi de conclure avec mes deux derniers cents et dire que je préfère beaucoup git parce que je pense qu'il est beaucoup plus puissant que tout autre système que j'ai utilisé. Gravir la courbe d'apprentissage paie certainement une fois que vous commencez à mieux comprendre le programme.

6
répondu samoz 2009-06-15 11:58:27

Vérifier le lien suivant vers un sondage sur le sujet:

http://www.debian-administration.org/polls/160

2
répondu Dkyc 2012-11-08 12:07:29

intéressant blog post d'Eric Évier sur eux tous.

1
répondu pjbelf 2009-06-15 11:52:03

Je ne Poste pas normalement mais..

j'ai essayé git,bzr et peu d'autres que j'oublie et j'ai constaté que bzr a un point très très faible. Pour les gros fichiers, il insiste pour charger l'ensemble du fichier en mémoire. Cela crée des problèmes pour les binaires de grande taille.

Git était beaucoup mieux à cet égard. Comme pour la difficulté. J'utilise git sous windows à partir de git bash. Travaille bien et a appris en moins d'une semaine (qui comprenait le travail réel et l'expérimentation avec d'autres VCS)

1
répondu Mustafa 2012-12-26 17:28:18