La popularité de Git/Mercurial/Bazar vs qui à recommander
En passant par le nombre de questions sur ce site pour ces trois distribués, systèmes de contrôle de version, il semble que Git soit
- est de plus en plus populaire, ou
- est plus difficile (et donc nécessitant plus de questions), ou
- a plus de fonctionnalités (et donc nécessitant plus de questions).
Ou plus probablement une combinaison des trois. (Disons que la popularité sur ce site correspond à la popularité en général.) Voici les numéros:
Il n'est pas entièrement satisfaisante de trois concurrents, mais largement équivalent open source de produits à choisir. Personnellement, j'utilise Git et je suis très bien avec les deux autres. Mais quand il s'agit de recommander un système sur les autres, je voudrais vous demander: pouvons-nous commencer à recommander un en toute sécurité encore?
Commentaires à partir de la mi-2009:
La récente popularité historique de la Subversion est clairement reflété par le nombre de questions, en indiquant au moins un petit renversement de la balance vers Git à l'Mercurial ou Bazar.
Commentaires à partir de la mi-2010:
Regardez cette énorme augmentation relative Mercurial numéros. Évidemment, seuls les deux points de données ne suffit pas de montrer une tendance, mais il semble que Git et Subversion sont largement ancrées, Mercurial a vu beaucoup de la croissance, et le Bazar est restée relativement calme.
Bref commentaire, à la mi-2011:
Peut-on seulement appeler Git le gagnant? :)
Pas, j'accepte l'argument selon lequel le nombre de questions n'est pas l'équivalent de la popularité. Les numéros sont forts, bien que.
Codes de reproduire les parcelles 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",
"27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]
git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]
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.ylabel("number of tags on stackoverflow")
plt.ylim(0)
plt.legend()
# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")
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",
"27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]
git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
mrc = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
bzr = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]
n = len(dates)
intervals = [x[i+1] - x[i] for i in range(n-1)]
git_per_day = [(git[i+1] - git[i]) / intervals[i].days for i in range(n-1)]
svn_per_day = [(svn[i+1] - svn[i]) / intervals[i].days for i in range(n-1)]
mrc_per_day = [(mrc[i+1] - mrc[i]) / intervals[i].days for i in range(n-1)]
bzr_per_day = [(bzr[i+1] - bzr[i]) / intervals[i].days for i in range(n-1)]
ii = [0] + [val for val in range(1, n-1) for _ in (0, 1)] + [n-1]
jj = [val for val in range(n-1) for _ in (0, 1)]
ax = plt.gca()
ax.grid()
plt.plot([x[i] for i in ii], [git_per_day[j] for j in jj], label="[git]")
plt.plot([x[i] for i in ii], [svn_per_day[j] for j in jj], label="[svn]")
plt.plot([x[i] for i in ii], [mrc_per_day[j] for j in jj], label="[mercurial]")
plt.plot([x[i] for i in ii], [bzr_per_day[j] for j in jj], label="[bazaar]")
plt.gcf().autofmt_xdate()
plt.ylabel("average daily tags on stackoverflow")
plt.legend()
plt.ylim(0)
# plt.show()
plt.savefig("comparison-daily.png", transparent=True, bbox_inches="tight")
- Vous pouvez consulter une comparaison globale entre Git, Mercurial et le Bazar ici: techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison
- Depuis, il est maintenant à juillet 2011, une mise à jour peut être dans l'ordre. Une comparaison récente du nombre total d'utilisateurs est fourni sur la bzr site.
- Je suis d'accord que la question de la balise de compte ne sont pas l'équivalent de la popularité et en fait peut-être anti-corrélés. Au lieu de cela, la question des comptages sont en corrélation directe avec le débordement de pile utilisateur des problèmes avec chacun des systèmes VCS.
- Voici quelques chiffres d'utilisateurs réguliers de chaque vcs (et tous les autres paquets d'Ubuntu): popcon.ubuntu.com/by_inst
bzr
semble avoir le double de l'actif de l'utilisateur de la base degit
, au moins sur Ubuntu linux, oùbzr
est la valeur par défaut de développement de l'outil de collaboration. - Quelqu'un devrait soulever une bonne question sur Meta. L', DONC l'équipe ont accès à des données précises à ce sujet, comme la façon dont beaucoup de gens ont demandé vs tags vs réponses etc. Peut-être que cela de données est dans cette célèbre dump XML de la base de données?
- Si le monde open source est représentatif de systèmes de gestion de l'utilisation en général, puis un autre moyen de vérifier la popularité de divers systèmes est en regardant Ohloh de l'analyse de systèmes de gestion de l'utilisation, qui couvre près de 60 000 des projets. Ce serait vraiment sympa d'avoir un temps-parcelle de que. mais il n'y en a pas une que je peux voir.
- Merci à ceux qui aident à garder les données en vie! Malgré la question étant fermée, je pense toujours que c'est un moyen intéressant d'examiner comment ces Vcs ont grandi.
Vous devez vous connecter pour publier un commentaire.
Mise À Jour Novembre 2011:
Git est maintenant beaucoup plus mature par rapport à 2009:
Toutefois, l'installation de Git dans un environnement centralisé n'est pas trivial:
Voir "Distribué Systèmes de Contrôle de Version et de l'Entreprise - un Bon mélange?"
Un point constamment manquer:
ils sont différents dans leur nature.
Arne Babenhauserheide modifie que pour Mercurial en soulignant que de Mercurial L'histoire du modèle pistes contenu changements, avec "fichier" -les chemins de ré-utilisé dans la couche de stockage pour optimiser le système de fichiers d'accès.
Qui signifie:
git-mv
. Il n'a absolument rien à voir avec le contenu explicite de suivi. C'est littéralement un raccourci pourmv
, puisgit-rm
sur l'ancien nom et git-ajouter sur le nouveau nom.Sur SCM popularité - voir la suite de StackOverflow question: Il y a aucune popularité et l'utilisation de statistiques disponibles pour la Libre RCS/SCM/VCS systèmes?. Ici, nous avons des questions comme ce jeu d'ignorer les fichiers à utiliser pour un type spécifique de projet, qui sont SCM agnostique, mais ils sont invités pour Git (et à l'aide de git tag), parce que c'est ce que la personne qui a posé la question de l'utilisation.
Sur Git être plus difficile (et donc avoir plus de questions au sujet de sur DONC) -- certainement Git a plus raide de la courbe d'apprentissage. Il utilise également quelques (très) concepts uniques, comme la zone de transit (l'index), ou toutes les branches égales, qui sont responsables de sa puissance, mais il peut être difficile d'obtenir le droit au premier abord (surtout si l'on vient d'autres SCM). Aussi Git de l'INTERFACE utilisateur n'est pas complètement cohérent (même si ça va mieux), parce qu'il a été cultivé plutôt que développés; qui est responsable de sa puissance, mais pourrait conduire à sous-optimale de l'interface utilisateur.
Sur Git avoir plus de fonctionnalités -- vous avez pour vérifier la façon dont beaucoup de questions à propos de advanced /rare fonctionnalités de Git. Vous devez être conscient, cependant, que les projets open source emprunter des idées de l'un à l'autre, ou ont des caractéristiques similaires développées de manière indépendante: un exemple serait de trouver des bugs par bissectrice (la recherche) histoire de s'engager, qui a introduit le bug qui a été (autant que je sache) est développé d'abord dans Git, puis mis en œuvre en tant que plugin dans le Bazar, et la première extension et actuellement à la fonctionnalité de base de Mercurial. Une autre serait de interactif la sélection de fragments de changements de commettre, inspiré par Darcs comportement. Encore une autre serait de Git du bundle idée, emprunté à un concept similaire dans Mercurial.
Encore une autre possibilité de la source du plus grand nombre de DONC, la question pourrait être manque d'une bonne documentation... même si ça va mieux aujourd'hui avec Git Manuel de l'Utilisateur (distribué avec Git) et Git Community Book (trouvé sur Git page d'accueil). Il n'y a toujours cette persistance de mème que Git a pire documentation que, disons, la Subversion avec ses Le Contrôle de Version avec Subversion (aussi connu comme svnbook) et Mercurial: The Definitive Guide (aussi connu comme hg-livre)... et les gens ne lisent pas la documentation avant de poser une question sur StackOverflow, parfois.
Bien, Git et Mercurial ont été élaborées indépendamment de départ à peu près au même moment dans la réponse de la résiliation de licence gratuite pour BitKeeper pour une utilisation par les développeurs du noyau Linux, comme un remplacement pour elle. Subversion était hors de question de la centralisation de l'SCM, avec le manque de soutien (à l'époque) en base pour le suivi de fusion, ce qui a complètement inadapté pour la largement distribué modèle de développement du noyau Linux. Bazar était probablement trop lente (au moins à l'époque), et un peu sur centralisée côté (je suppose).
Git est plus puissant (à mon avis), Mercurial est plus simple (dans l'opinion de personnes) et un peu plus portable (Python); Git est scriptable, et est basé sur le modèle de données permettant indépendant reimplementations (voir, par exemple, JGit, git écrit en Java), tandis que l'Mercurial a liaisons Python pour écrire des extensions, et est largement basé sur l'API permettant le changement de référentiel sous-jacent format (revlog - revlog-ng)... mais c'est juste ma supposition. Ils remplissent légèrement différentes niches.
D'ailleurs n'est pas d'avoir un choix considéré comme une bonne chose? Nous avons KDE et nous avons GNOME et XFCE (et d'autres gestionnaires de fenêtres et de bureau envirionments); nous avons Emacs et Vim (et d'autres du programmeur éditeurs), nous nous sommes basé sur rpm (par exemple, Fedora Core, Mandriva, SuSE) et deb-basé (Debian, Ubuntu) et tgz base (Slackware) et source (Gentoo) distributions, nous avons KWord, AbiWord et OpenOffice.org... et nous avons Git, Mercurial et le Bazar.
J'utilise et je recommande mercurial
Dans mon expérience, à en juger par le nombre de questions sensiblement biaise la comparaison avec git et contre Mercurial. La raison en est double:
Ont un coup d'oeil à
hg update --help
contregit checkout -h
etgit --help checkout
. Avec Mercurial j'ai rarement trouvé des questions qui ne sont pas répondues par quelques regards àhg help
.Vérifier la Mercurial Wiki — si vous besoin d'aide, vous aurez probablement trouver là, y compris de nombreux Trucs et Astuces: http://mercurial-scm.org/wiki/TipsAndTricks
bzr help update
oubzr update --help
oubzr --help update
oubzr -h update
(avis bzr peut gérer tous la commune de la syntaxe et vocabulaire). Remplacement de votre favori hg ou git ou svn VCS commande et vous verrez que bzr peut vous aider avec cela aussi. Pas besoin de poster sur stackoverflow quand hg et bzr répondre à vos questions en mode hors connexion.[REMARQUE: Avec la version de Subversion 1.7, le premier paragraphe de ma réponse ci-dessous est à jour, comme de la Subversion maintenant juste crée un seul ".svn" dossier dans le dossier de base, semblable aux autres maintenant.]
L'un des avantages de l'un des trois plus de la subversion, c'est qu'il ne crée pas un équivalent de ".svn" dossier dans chaque dossier du projet. Généralement, il existe un seul (".hg", ".bzr" ou ".git") dans le dossier de base. Rien que cela peut être une bonne raison pour utiliser l'un d'eux sur svn, même si vous utilisez un référentiel centralisé modèle. (Aparté: En fait, j'utilise souvent svk que mon client svn lors de l'utilisation d'un dépôt svn juste pour cette fonction (linux seulement si, svk est pas bon sur windows)).
Bien sûr, un avantage de la subversion est que vous n'avez pas à vérifier-l'ensemble du projet, si vous avez seulement besoin de l'un de ses sous-dossiers.
Canonical (Ubuntu) pistes package de logiciels d'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 souligné, cela ne les pistes les utilisateurs d'Ubuntu et Canonical (Ubuntu) utilise et recommande bzr (l'échantillon). Néanmoins...
Le déclin de la voix pour le git-core package me fait penser que j'ai fait quelque chose de mal comme
grep
ed le mauvais nom de paquet d'ubuntu popularité de la table. Ou peut-être même ce "vote" le compte est lié à des installations et non sur l'utilisation réelle du logiciel.Voici quelques données historiques pour l'analyse des tendances. J'ai utilisé le
<install>
plutôt que<vote>
stats de Ubuntu dans ce tableau, mais il montre une poussée de croissance dans le Bazar et Mercurial départ en 2011. Néanmoins,bzr
était derrièregit
en 2011, mais les récentes statistiques de 2011 montrent qu'il est passégit
dans le total des instances installées (sur Ubuntu).Discalaimer: j'ai utilisé bzr sur Ubuntu, jusqu'en 2012, lorsque j'ai travaillé sur des équipes qui ont utilisé
git
exclusivement.Bzr
joue agréable avec tous les autres VCSes, vous permettant d'utiliser cohérente, intuitive bzr syntaxe de ligne de commande. Mon interrupteur àgit
était social plutôt que des raisons techniques.<vote>
colonne à (popcon.ubuntu.com/by_inst) Comme de 9/11 les "coincés" ratio est git=2%, bzr=4%, hg=5%. Donc bzr passé git comme les plus utilisés VCS sur Ubuntu, il y a des mois, et hg devrait passer à git bientôt.Depuis l'origine de codage social avec Git à GitHub, Git semble avoir attiré beaucoup de fans.
Bien la raison que git a donc beaucoup d'utilisateurs, c'est que le noyau Linux utilise, donc si vous voulez faire le développement de Linux, vous utilisez git.
Comme de nombreuses personnes se sont impliqués avec git, je vous recommande d'utiliser git, simplement en raison de la plus grande base d'utilisateurs. En fait, les chiffres vous montrer ci-dessus sont un signe clair de cela.
Que pour la difficulté, tout le contrôle de version est difficile, en particulier dans les distribué genre. SVN et CVS n'étaient pas exactement facile (pour moi au moins) au premier coup d'œil. Ce n'est qu'une partie de l'apprentissage nécessaire de la courbe de s'habituer à un système de contrôle de version.
EDIT: Depuis que vous avez ajouté une subversion de référence, j'ai pensé que je voudrais aborder. Je pense que la plupart des gens vont utiliser svn, car il a toutes sortes de jolies interfaces GUI pour elle. En général, les gens détestent utiliser la ligne de commande, y compris certains développeurs. git en général ne fonctionne pas très bien sur Windows (ou du moins pas de manière aussi transparente). Car beaucoup de personnes sont sur Windows, cela tue le nombre d'utilisateurs potentiels.
En outre, je pense que les concepts de SVN sont un peu plus faciles à saisir depuis le svn utilise un référentiel central plutôt que d'un système distribué. C'est plus facile à comprendre, "Ici est la grande montagne de code, s'il vous plaît ajouter votre code ici" que "Voici un peu de code, la mine pourrait être différente de son, de son à partir de la sienne, mais vous pouvez ajouter quelque chose si vous le souhaitez."
À mon avis, svn a un bien meilleur système de documentation mis en place. git de la documentation est destinée à un peu plus élevé au niveau de la connaissance (du programme, pas un des programmeurs de l'intelligence) et donc de sens une fois que vous utilisez le système, mais lors du premier démarrage, il ressemble à un tas de gobbeldy-gook.
Dans l'ensemble, je pense que svn est et sera toujours de plus en plus répandus, car son fonctionnement général concepts sont plus faciles à comprendre, les outils sont faciles à utiliser, et il est magnifique sur Windows.
Permettez-moi de terminer avec mon dernier deux cents si et dire que je préfère de beaucoup de git parce que je pense que c'est beaucoup plus puissant que n'importe quel autre système que j'ai utilisé. L'escalade de la courbe d'apprentissage est certainement paie une fois que vous commencez à comprendre le programme de meilleurs.
Consulter le lien suivant à un sondage sur le sujet:
http://www.debian-administration.org/polls/160
Une intéressante post de blog de Eric Évier sur eux tous.
Je ne suis pas normalement post mais..
J'ai essayé de git,bzr et quelques autres que j'oublie et trouvé bzr a un très très gros point faible. Pour les gros fichiers, il insiste sur le chargement de la totalité du fichier en mémoire. Cela crée des problèmes pour les gros fichiers binaires.
Git était beaucoup mieux à cet égard. Comme pour la difficulté. J'utilise git sous windows à partir de git bash. Fonctionne très bien et a appris en moins d'une semaine (qui inclus le travail réel et à expérimenter avec d'autres VCS)