Popularité de Git / Mercurial / Bazaar contre qui recommander
D'après le nombre de questions sur ce site pour ces trois systèmes de contrôle de version distribués, il semble que Git soit
- est plus populaire, ou
- est plus difficile (nécessitant donc plus de questions), ou
- a plus de fonctionnalités (nécessitant donc plus de questions).
Ou très probablement une combinaison des trois. (Disons que la popularité sur ce site équivaut à la popularité au sens large.) Voici les chiffres:
Ce n’est pas tout à fait satisfaisant d’avoir le choix entre trois produits open source concurrents mais largement équivalents. Personnellement, j'utilise Git et je vais bien avec les deux autres. Mais quand il s'agit de recommander un système plutôt que d'autres, j'aimerais demander: pouvons-nous commencer à en recommander un en toute sécurité?
Commentaires de la mi-2009 : La popularité récente de Subversion est clairement reflétée par le nombre de questions, indiquant au moins un léger basculement de la balance vers Git sur le Mercurial ou le Bazar.
Commentaires de la mi-2010 : Regardez cette énorme augmentation relative du nombre de Mercurial. Il est évident que deux points de données ne suffisent pas pour indiquer une tendance, mais il semble que Git et Subversion soient largement enracinés, Mercurial a connu une croissance importante et Bazaar est resté relativement calme.
Bref commentaire, mi-2011 : Pouvons-nous simplement appeler Git le gagnant? :) Non, j’accepte l’argument selon lequel le nombre de questions n’est pas équivalent à la popularité. Les nombres sont sûrs, cependant.
Codes pour reproduire les graphiques 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")
Mise à jour novembre 2011:
Git est maintenant beaucoup plus mature que 2009:
- smart http est maintenant pris en charge, ce qui signifie que vous pouvez proposer à votre client le protocole https pour extraire/cloner et Push, avec une authentification capable de s’interfacer avec un LDAP (important pour l'utilisateur dans une entreprise)
- Une couche d'autorisation mature existe maintenant avec Gitolite , ce qui signifie que vous pouvez fournir une isolation pour un référentiel "confidentiel" (là encore, important pour les grandes entreprises).
- Le support Windows, qui existait déjà en 2009, fonctionne toujours très bien et TortoiseGit est relativement stable
- L'intégration avec IDE comme Eclipse est en cours (la plupart des projets Eclipse sont maintenant sur GitHub)
Cependant, installer Git dans un environnement centralisé n’est pas trivial:
Voir " Systèmes de contrôle de version distribués et entreprise: un bon mélange? "
Un point systématiquement omis est:
ils sont différents dans leur nature.
- SVN est un système REVISION (il stocke les branches et les tags uniquement par copie à bon marché! Le support de fusion n’est pas très efficace), et il est centralisé.
- Mercurial ou Bazar sont FILE VCS (ils stockent les versions de fichiers) et sont distribués.
Arne Babenhauserheide modifie cela pour Mercurial en indiquant que le modèle historique de Mercurial content-changes , les chemins de fichiers étant réutilisés dans la couche de stockage pour optimiser l'accès au système de fichiers. - Git, et il est très difficile à saisir, est un [~ # ~] contenu [~ # ~] VCS (il stocke le delta de contenu, pas le fichier lui-même: deux fichiers avec le même contenu ne seront stockés qu'une fois)
Cela signifie:
- si vous avez un flux de travail de fusion simple , restez sur SVN avec SVN
- si vous avez plusieurs emplacements de développement, un VCS distribué est plus adapté.
- si vous avez un processus de fusion complexe , tout VCS moderne est meilleur que SVN, qui a du mal à conserver les informations de fusion au bon endroit pendant des années. Cela dépend ensuite des outils (Mercurial dispose d’un support Windows plus avancé, par exemple)
- si vous avez principalement des fichiers texte et des fichiers binaires pas trop volumineux, Git est excellent, à condition que vous connaissiez ses limites.
Selon le nombre de questions sur ce site pour ces trois systèmes de contrôle de version distribués, il semble que Git soit
- est plus populaire, ou
- est plus difficile (nécessite donc plus de questions), ou
- a plus de fonctionnalités (nécessitant donc plus de questions).
À propos de SCM popularité - consultez la question StackOverflow suivante: Existe-t-il des statistiques de popularité/utilisation disponibles? pour les systèmes Free RCS/SCM/VCS? . Nous avons ici des questions comme quel ensemble de fichiers ignorés utiliser pour un type de projet spécifique, agnostiques de SCM, mais auxquels Git est demandé (et utilisant la balise 'git'), car c’est la personne qui a posé la question.
À propos de Git étant plus difficile (et donc avoir plus de questions à propos de SO) - Git a certainement une courbe d'apprentissage plus abrupte . Il utilise également peu de concepts (tout à fait) uniques, tels que la zone de préparation (l'indice) ou toutes les branches égales, qui sont responsables de son pouvoir, mais peuvent être difficiles à comprendre au début (surtout si elles proviennent d'un autre SCM). . De plus, l'interface utilisateur de Git n'est pas complètement cohérente (même si elle s'améliore), car elle a été développée plutôt que développée; qui est responsable de son pouvoir, mais pourrait conduire à une interface utilisateur sous-optimale.
À propos de Git ayant plus de fonctionnalités - il vous faudrait vérifier combien SO = les questions portent sur des fonctionnalités avancées/peu communes de Git. Notez toutefois que les projets open source empruntent des idées les uns aux autres ou ont des fonctionnalités similaires développées indépendamment: un exemple serait de trouver des bogues en coupant en deux l'historique (commit) de commit introduisant le À ma connaissance, ce bogue a été développé d’abord dans Git, puis mis en œuvre sous forme de plug-in dans Bazaar, ainsi que de première extension et de fonctionnalités actuellement centrales dans Mercurial.Un autre serait la sélection interactive de fragments de modifications à valider, inspirés par le comportement de Darcs. Une autre idée serait l’idée globale de Git, empruntée à un concept similaire dans Mercurial.
Encore une autre possibilité de source d'un plus grand nombre de SO question pourrait être manque de bonne documentation ... bien que cela s'améliore de nos jours avec Manuel de l'utilisateur Git (distribué avec Git) et Livre de la communauté Git (disponible sur la page d'accueil Git). Il existe toujours ce meme persistant que Git a une documentation pire que, disons, Subversion avec ses Contrôle de version avec Subversion (également appelé 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 satisfaisant d’avoir le choix entre trois produits open source concurrents mais largement équivalents. Personnellement, j'utilise Git et je vais bien avec les deux autres. Mais quand il s'agit de recommander un système plutôt qu'un autre, j'aimerais demander: pouvons-nous commencer à en recommander un en toute sécurité?
Eh bien, Git et Mercurial ont été développés indépendamment en commençant à peu près au même moment dans la réponse de la licence libre de BitKeeper pour utilisation par les développeurs du noyau Linux, en remplacement de celle-ci. Subversion était hors de question en tant que SCM centralisé, avec un manque de support (à l’époque) pour le suivi des fusions; cela le rendait totalement inadapté au modèle de développement largement distribué du noyau Linux. Bazar était probablement trop lent (du moins à ce moment-là) et un peu centralisé (je suppose).
Git est plus puissant (à mon avis), Mercurial est plus simple (aux yeux des gens) et un peu plus portable (Python); Git est scriptable et est basé sur un modèle de données permettant des réimplémentations indépendantes (voir par exemple JGit, git écrit en Java), tandis que Mercurial possède des liaisons Python pour l'écriture d'extensions) et repose largement sur l'API permettant le changement de format de dépôt sous-jacent (revlog - revlog-ng) ... mais ce n’est que ma supposition: ils occupent des niches légèrement différentes.
D'ailleurs, 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 des distributions basées sur rpm (par exemple, Fedora Core, Mandriva, SuSE) et basées sur deb (Debian, Ubuntu) et tgz (Slackware) et basées sur la source (Gentoo); nous avons KWord, AbiWord et OpenOffice.org ... et nous avons Git, Mercurial et Bazaar.
J'utilise et recommande Mercurial
- plutôt que Subversion car il prend en charge le développement distribué. Je peux travailler sur plusieurs machines et valider localement. Vous ne pouvez pas faire cela avec Subversion, du moins pas sans des sauts périlleux comme des référentiels supplémentaires
- plutôt que Bazaar parce que le support des fenêtres de Bazaar est ... bien.
- plutôt que git car il est a) plus simple à apprendre et à utiliser et b) le support de windows est bien meilleur
D'après mon expérience, à en juger par le nombre de questions, la comparaison avec git et contre Mercurial est nettement biaisée. La raison est double:
Examinez
hg update --helpPar rapport àgit checkout -hEtgit --help checkout. Avec Mercurial, j’ai rarement trouvé des questions auxquelles on ne répondait pas en en regardant quelques instants danshg help.Vérifiez le Wiki Mercurial - si vous avez besoin d'aide , vous le trouverez probablement ici , y compris de nombreux conseils et astuces: http://Mercurial-scm.org/wiki/TipsAndTricks
[REMARQUE: Avec la sortie de Subversion 1.7, le premier paragraphe de ma réponse ci-dessous est obsolète, car Subversion ne crée plus qu'un seul dossier ".svn" dans le dossier de base, semblable aux autres maintenant.]
L’un des avantages de l’un des trois par rapport à Subversion est qu’il ne crée pas l’équivalent d’un dossier ".svn" dans chaque dossier du projet. Il n’ya généralement qu’un (".hg", ".bzr" ou ".git") dans le dossier de base. Cela seul peut être une bonne raison d'utiliser l'un d'eux sur svn même si vous utilisez un modèle de référentiel centralisé. (À part: en fait, j'utilise souvent svk comme mon client svn lors de l'utilisation d'un référentiel svn rien que pour cette fonctionnalité (linux seulement, svk n'est pas bien sous windows)).
Bien entendu, l'un des avantages de Subversion est que vous n'avez pas à extraire l'intégralité du projet si vous n'avez besoin que de l'un de ses sous-dossiers.
Les pistes Canonical (Ubuntu) tilisation du progiciel pour leur distribution, il n’est donc pas nécessaire de compter sur le nombre de problèmes de Stack Exchange pour mesurer leur popularité. Cependant, comme d'autres l'ont souligné, cela ne fait que suivre les utilisateurs d'Ubuntu et Canonical (Ubuntu) utilise et recommande bzr (biais de l'échantillon). Toutefois...
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%
La baisse du nombre de votes pour le paquet git-core me fait penser que j'ai fait quelque chose de mal comme greple nom de paquet incorrect dans la table de popularité d'ubuntu. Ou peut-être même que ce "vote" compte est lié aux installations et non à l'utilisation réelle du logiciel.
Voici quelques données historiques pour les tendances. J'ai utilisé le <install> plutôt que <vote> statistiques d’Ubuntu dans ce tableau, mais elles montrent une poussée de croissance dans Bazaar et Mercurial à partir de 2011. Néanmoins, bzr était derrière git en 2011, mais les statistiques récentes de 2011 montrent que il a passé git au 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, année où j'ai travaillé sur des équipes utilisant exclusivement git. Bzr joue bien avec tous les autres VCS, ce qui vous permet d'utiliser une syntaxe cohérente et intuitive en ligne de commande bzr. Mon passage à git était pour des raisons sociales plutôt que techniques.
Depuis l'origine du codage social avec Git sur GitHub , Git semble avoir attiré de nombreux adeptes.
Eh bien, la raison pour laquelle git compte autant d'utilisateurs est que le noyau Linux l'utilise, donc si vous voulez faire du développement Linux, utilisez git.
Étant donné que tant de personnes sont impliquées dans git, je recommanderais d'utiliser git, simplement en raison de la base d'utilisateurs plus étendue. En fait, les chiffres que vous montrez ci-dessus en sont un signe clair.
En ce qui concerne la difficulté, tout contrôle de version est difficile, en particulier le type distribué. SVN et CVS n’ont pas été faciles au premier abord (pour moi du moins). Cela fait partie de la courbe d'apprentissage nécessaire pour s'habituer à un système de contrôle de version.
EDIT: Depuis que vous avez ajouté une référence Subversion, j’ai pensé que j’y répondrais. Je pense que la plupart des gens vont utiliser svn car il a toutes sortes de jolies interfaces graphiques. En général, les utilisateurs détestent utiliser la ligne de commande, y compris certains développeurs. git ne fonctionne généralement pas très bien sous Windows (ou du moins pas de manière aussi transparente). Étant donné que de nombreuses personnes utilisent Windows, cela tue le nombre d'utilisateurs potentiels.
De plus, je pense que les concepts de SVN sont un peu plus faciles à comprendre puisque svn utilise un référentiel central plutôt qu'un système distribué. Il est plus facile de comprendre, "Voici la grande montagne de code, veuillez ajouter votre code ici", à "Voici un code, le mien peut être différent du sien, mais du sien, mais vous pouvez ajouter quelque chose si vous le souhaitez."
À mon avis, svn a un système beaucoup mieux mis en place pour la documentation. La documentation de git vise un niveau de connaissance un peu plus élevé (du programme, pas une intelligence de programmeur) et est donc logique après avoir utilisé le système, mais au premier démarrage, cela ressemble à un tas de gobbeldy-gook.
Globalement, je pense que svn est et sera toujours plus répandu, car ses concepts de fonctionnement généraux sont plus faciles à comprendre, ses outils sont faciles à utiliser et son support est formidable sous Windows.
Permettez-moi de terminer avec mes deux derniers centimes et de dire que je préfère de loin git parce que je pense que c'est beaucoup plus puissant que tout autre système que j'ai utilisé. Monter la courbe d'apprentissage est définitivement rentable une fois que vous commencez à mieux comprendre le programme.
Vérifiez le lien suivant vers un sondage sur le sujet:
Je ne poste pas normalement mais ..
J'ai essayé git, bzr et quelques autres que j'oublie et trouve que bzr a un point très très faible. Pour les gros fichiers, il insiste sur le chargement du fichier entier dans la mémoire. Cela crée des problèmes pour les fichiers binaires volumineux.
Git était beaucoup mieux à cet égard. Quant à la difficulté. J'utilise Git dans les fenêtres de Git Bash. Fonctionne très bien et a appris en moins d'une semaine (cela incluait le travail réel et l'expérimentation avec d'autres VCS)
Un intéressant article de blog de Eric Sink à propos de tous.