Pourquoi Mercurial est-il considéré comme plus facile que Git?
Quand on regarde les comparaisons, il me semble qu'il pourrait y avoir un mappage 1: 1 entre leurs ensembles de fonctionnalités. Pourtant, une affirmation souvent citée est que "Mercurial est plus facile". Quelle est la base de cette déclaration? (si seulement)
Exemple: disons que vous souhaitez modifier le nom d'utilisateur de tous vos validations précédentes. J'ai dû faire cela plusieurs fois pour diverses raisons.
Version Git
git filter-branch --commit-filter '
if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
then
GIT_COMMITTER_NAME="<New Name>";
GIT_AUTHOR_NAME="<New Name>";
GIT_COMMITTER_EMAIL="<New Email>";
GIT_AUTHOR_EMAIL="<New Email>";
git commit-tree "$@";
else
git commit-tree "$@";
fi' HEAD
Version Mercurial:
fichier auteurs.convert.list:
<oldname>=<newname>
Ligne de commande:
hg convert --authors authors.convert.list SOURCE DEST
Maintenant, lequel semble plus facile à utiliser?
Remarque: J'ai passé 2 ans à travailler uniquement avec Git, donc ce n'est pas une diatribe "Je déteste ça, je ne l'ai pas eu en 2 secondes".
Pour moi, c'est la convivialité. Git est très orienté linux avec une façon linux de faire les choses. Cela signifie la ligne de commande, les pages de manuel et le découvrir par vous-même. Il avait une interface graphique très pauvre (note: je basais cela sur msysGit il y a environ un an), qui semblait juste me gêner. Je pouvais à peine l'utiliser
La ligne de commande était pire. Étant un programme orienté Linux, sur Windows, il était très difficile à utiliser. Au lieu d'un port natif, ils ont simplement enveloppé git avec MinGW (Think cygwin), ce qui a rendu le travail beaucoup plus difficile. MinGW n'est pas l'invite de commande Windows et agit simplement différemment. C'est fou que ce soit la seule façon de travailler avec Git. Même sous Linux, il semblait que le seul moyen était de travailler avec une ligne de commande directe. Des projets comme RabbitVCS ont aidé certains, mais n'étaient pas très puissants.
L'approche orientée ligne de commande et le fait d'être un programme Linux signifiaient que presque tous les guides pratiques, la documentation d'aide et les questions du forum/QA reposaient sur l'exécution de commandes monstrueuses comme ci-dessus. Les commandes SCM de base (commit, pull, Push) ne sont pas aussi complexes, mais la complexité augmente de façon exponentielle.
Je déteste également le seul endroit où de nombreux utilisateurs de git OSS semblent traîner: Github. Lorsque vous accédez pour la première fois à une page github, il vous claque avec tout ce que vous pouvez faire. Pour moi, ne page de projets git semble chaotique, effrayant et trop puissant. Même l'explication de ce qu'est le projet est poussée vers le bas. Github blesse vraiment les gens qui n'ont pas de site Web complet déjà configuré. Son traqueur de problème est également terrible et déroutant. Surcharge de fonctionnalité.
Les utilisateurs de Git semblaient également être très cultes. Les utilisateurs de Git semblent toujours être ceux qui déclenchent des "guerres saintes" sur lesquelles DVCS est meilleur, ce qui oblige ensuite les utilisateurs de Mercurial à se défendre. Des sites comme http://whygitisbetterthanx.com/ montrent de l'arrogance et une mentalité presque "Utiliser mon logiciel ou mourir". Plusieurs fois, je suis allé dans divers endroits pour être flâné pour ne pas connaître X, utiliser X au préalable, utiliser Windows, etc. C'est fou.
Mercurial, d'autre part, semble aller vers une approche plus douce. Leur propre page d'accueil semble beaucoup plus convivial pour les nouveaux utilisateurs que Git's . Dans une simple recherche Google, le 5ème résultat est TortoiseHg, une interface graphique très agréable pour Mercurial. Toute leur approche semble être la simplicité d'abord, la puissance ensuite.
Avec Mercurial, je n'ai pas de non-sens SSH (SSH est l'enfer sous Windows), je n'ai pas de commandes stupidement complexes, je n'ai pas d'utilisateur culte, je n'ai pas de folie. Mercurial fonctionne juste.
TortoiseHg fournit une interface réellement utilisable (même si elle semble se développer récemment) qui fournit des fonctionnalités réellement utiles. Les options sont limitées à ce dont vous avez besoin, supprimant l'encombrement et les options rarement utilisées. Il fournit également de nombreux paramètres par défaut décents
Mercurial, étant très sympathique avec les nouveaux arrivants, était très facile à prendre. Même certains des sujets les plus complexes comme les différents modèles de branchement et l'édition de l'historique étaient très faciles à suivre. J'ai ramassé Mercurial rapidement et sans douleur.
Mercurial fonctionne également la première fois avec peu de configuration. Sur N'IMPORTE QUEL OS, je peux simplement installer TortoiseHg et obtenir toutes les fonctionnalités que je veux (principalement les commandes du menu contextuel) sans avoir à chercher différents Guis. Il manque également la configuration de SSH (la moitié des guides disent utiliser PuTTY, Plink et Pagent tandis que l'autre moitié dit d'utiliser ssh-keygen). Pour les nouveaux utilisateurs, TortoiseHg prend quelques minutes à configurer tandis que Git prend 30 minutes à une heure avec beaucoup de recherches sur Google.
Enfin, vous avez les dépôts en ligne. L'équivalent de Githubs est BitBucket, qui présente certains des problèmes que j'ai décrits ci-dessus. Mais il y a aussi Google Code. Quand je vais à n projet Google Code , je ne reçois pas de surcharge de fonctionnalités, je reçois une belle interface propre. Google Code est plus un ensemble repo/site Web en ligne, qui aide vraiment les projets OSS qui n'ont pas de configuration de site existante. Je me sentirais très à l'aise d'utiliser Google Code comme site Web de mes projets pendant un certain temps, ne construisant un site Web qu'en cas de nécessité absolue. Son traqueur de problème est également puissant, s'intégrant parfaitement entre le traqueur de problème presque inutile de Github et la monstruosité de Bugzilla .
Mercurial fonctionne juste, la première fois, à chaque fois. Git me gêne et ne me met en colère que plus je l'utilise.
Mercurial est généralement considéré comme plus simple et plus facile à apprendre que Git. À son tour, il y a souvent la perception que Git est plus flexible et plus puissant. Cela est dû, en partie, au fait que Git a tendance à fournir plus de commandes de bas niveau, mais aussi en partie parce que le Mercurial par défaut a tendance à masquer les fonctionnalités avancées , laissant aux utilisateurs le soin de modifier le fichier de configuration Mercurial pour activer les fonctionnalités avancées qu'ils aiment. Cela conduit souvent à la perception que les fonctionnalités avancées ne sont pas disponibles dans Mercurial.
Mercurial s'est toujours concentré davantage sur les aspects d'interface, ce qui a facilité à l'origine l'apprentissage. Par rapport à Git, une compréhension moins approfondie est nécessaire pour fonctionner avec Mercurial de manière utile. À long terme, une telle encapsulation a donné à Mercurial la fausse apparence d'être moins puissant et fonctionnel qu'il ne l'est vraiment.
Contexte: J'utilise à la fois Mercurial (pour le travail) et Git (pour les projets parallèles et l'open source) au quotidien. J'utilise principalement des outils textuels avec les deux (pas des IDE) et je suis sur un Mac.
En général, je trouve Mercurial plus facile à travailler. Quelques choses que je trouve facilitent Mercurial:
- Manque de l'index. L'index est un outil puissant permettant de nombreuses fonctionnalités de Git mais c'est aussi une couche supplémentaire qui ajoute une étape dans de nombreuses choses que je fais régulièrement. Le flux de travail de Mercurial est plus similaire à quelque chose comme svn.
- Numéros de révision au lieu de shas. C'est une petite chose qui rend le travail avec les commandes quotidiennes beaucoup plus facile dans Mercurial. Il est beaucoup plus facile de pousser quelques numéros de révision dans votre tête lors d'un rebase, d'une fusion, etc. lors de l'écriture d'une commande que de faire de même avec des shas même raccourcis.
- Branches. L'approche de Git pour les branches en nommant les commits est puissante et sensiblement différente des autres systèmes de contrôle de version. Cela rend certaines choses beaucoup plus faciles. Je trouve que l'approche de Mercurial correspond un peu mieux à la pensée svn et facilite la compréhension visuelle de l'historique de la branche. C'est peut-être juste une préférence.
Ceci est très subjectif et dépend d'une personne à l'autre, mais oui, j'irais vers quelqu'un complètement nouveau sur VCS ou quelqu'un venant de l'un des VCS "old school", Mercurial semblera plus facile.
Par exemple, l'ajout de fichiers, l'inexistence de l'index dans Hg, la facilité de revenir à certaines anciennes révisions et de créer des branches à partir de là (juste mettre à jour et valider) sont quelques-uns des exemples les plus "évidents". Maintenant, la plupart des fonctionnalités d'un système peuvent être émulées dans un autre et vice versa, mais cela nécessite des connaissances dans Git, tandis que dans Mercurial, les valeurs par défaut (si vous me permettez de les appeler ainsi) sont plutôt "conviviales". Ces petites choses - le commutateur ici et là, le comportement non évident dans une commande et ainsi de suite ... ces choses s'additionnent, et au final, un système semble plus facile à utiliser que l'autre.
Juste pour compléter la réponse; J'utilise git, mais lorsque je recommande un VCS à quelqu'un qui est "nouveau pour eux", je recommande presque toujours Mercurial. Je me souviens, quand il est venu entre mes mains, c'était très intuitif. D'après mon expérience, Mercurial produit moins de wtf/minute que Git.
Je pense que c'est aussi simple que cela: Mercurial a une syntaxe plus familière (en particulier pour les utilisateurs SVN) et est assez bien documentée. Une fois que vous vous serez habitué à la syntaxe Git, vous la trouverez aussi facile à utiliser que n'importe quoi d'autre.
Les perceptions pourraient changer avec le temps, à ce sujet. Mercurial est très bien conçu, tout comme Git. Mercurial semble être plus facile à apprendre (du moins c'était pour moi), et il y a eu des difficultés que j'ai rencontrées dans Git, que je n'ai pas de parallèle pour dans Mercurial. J'ai essayé d'apprendre Python et Ruby, et je suis allé plus loin, plus vite avec Python. Cela ne signifie pas Python est toujours et partout meilleur que Ruby, ou même que c'est mieux pour moi. C'est juste ce que j'ai appris et avec lequel je suis resté. Les programmeurs font souvent des guerres sacrées par préférence personnelle. D'autres êtres humains le font aussi.
Je suis un utilisateur de Mercurial qui essaie de garder un esprit ouvert à propos de Git, et j'admets librement qu'il n'est pas "devenu mon nouveau truc préféré" dans la même mesure que Mercurial. Je pense que Git est vraiment très sympa.
Un contre-exemple pour la complexité GIT/Mercurial: la prise en charge de Nice GIT est intégrée à XCode, sur Mac. XCode moins facile à utiliser avec Mercurial que GIT.
Mon expérience avec GIT jusqu'à présent a été que je suis confus et perdu et que je dois consulter davantage la documentation tout en l'utilisant. Je crois que beaucoup de documentation a été écrite, mais rien qui m'a permis de la "bouder". Deuxièmement, je peux facilement modifier et étendre Mercurial en Python, et comme je suis adepte de Python, et comme n'importe qui pourrait vraiment apprendre python rapidement, cela me semble un avantage. Je connais aussi C, et écrire Python extensions en C, donc je suppose qu'un jour, si j'en avais besoin, je pourrais facilement écrire une extension Git en C.
La facilité d'utilisation n'est pas quelque chose de facile à quantifier. C'est là, et je ne pense pas que ce soit entièrement subjectif, mais nous n'avons pas de bonnes techniques de mesure objectives. Quelles seraient les unités de facilité d'utilisation? Milli-iPods?
Je ne suis pas assez partisan pour être 100% pro-mercurial et 100% anti-git. Je suis plus à l'aise sur Mercurial en ce moment, sur Windows et sur Linux, et quand je commencerai à travailler davantage sur Mac, je m'attends à ce que j'essaye de m'en tenir à XCode + GIT.
Mise à jour 2013: J'ai maintenant utilisé Mercurial ET GIT assez longtemps pour trouver certaines fonctionnalités que j'aurais aimé que Git possède, comme ce question sur les stratégies de fusion. Vraiment, Git est incroyable, s'il est difficile à apprendre, et parfois d'une complexité exaspérante.
Il y a quelques choses que l'OMI est susceptible de dissuader Git de nouveaux utilisateurs:
La culture Git est plus centrée sur la ligne de commande. Bien que les deux outils aient tendance à trop se concentrer sur la ligne de commande (comme je l'ai dit plusieurs fois, les instructions de ligne de commande peuvent être puissantes et plus fluides, mais ce ne sont pas une bonne stratégie marketing ) c'est beaucoup plus le cas avec Git. Alors que Mercurial a un outil GUI standard de facto dans TortoiseHg, qui est même l'option de téléchargement par défaut pour les utilisateurs de Windows sur la page d'accueil Mercurial, Git a plusieurs frontaux GUI concurrents (TortoiseGit, Git Extensions, gitk, etc.) qui ne sont pas bien annoncés sur le site Web de Git, et qui sont tous une horreur complète de toute façon. (Texte noir sur les étiquettes rouges? Allez, TortoiseGit, vous pouvez faire mieux que ça!) Il y a aussi une attitude beaucoup plus omniprésente dans la communauté Git selon laquelle les gens qui utilisent des outils GUI ne sont pas de vrais développeurs de logiciels.
Git a plusieurs valeurs par défaut prêtes à l'emploi qui ont un sens parfait pour les utilisateurs avancés, mais sont susceptibles d'être surprenantes sinon intimidantes pour les nouveaux utilisateurs. Par exemple, il est beaucoup plus agressif d'automatiser des tâches telles que la fusion (par exemple, git pull fusionne et valide automatiquement si possible). Il existe un cas pour les fusions entièrement automatisées , mais la plupart des utilisateurs inexpérimentés sont terrifiés par la fusion et doivent avoir la possibilité de gagner la confiance dans leurs outils avant de libérer toute leur puissance sur leur code source.
Documentation et complexité inhérente:
$ hg help log | wc -l 64 $ git help log | wc -l 912
Parce que c'est.
Git expose bien plus ses tripes que Mercurial. Vous pouvez utiliser Mercurial avec plaisir quelques minutes après l'avoir récupéré, mais je trouve que git est toujours très difficile à gérer après quelques mois de lutte avec lui (j'ai fait très peu au cours des deux derniers mois à part essayer d'apprendre git ). J'utilise à la fois à partir de la ligne de commande et principalement sous Linux, ce n'est donc pas seulement une aversion pour l'interface de ligne de commande.
Un exemple simple est le nombre relativement faible de drapeaux et d'arguments de ligne de commande nécessaires pour Mercurial par rapport à git. La zone de transfert et le comportement de la commande add dans git ajoutent également plus de complexité que nécessaire. Le trio de réinitialisation, de paiement et de retour et leurs multiples permutations ajoute une énorme complexité, ce qui était tout à fait inutile lorsque vous êtes témoin de la nature simple du retour et de la mise à jour sur Mercurial.
Je suis également d'accord avec le commentaire ci-dessus concernant Hginit , cela a certainement rendu Mercurial beaucoup plus facile à comprendre. Bien écrit et très facile à comprendre. Aucune documentation écrite pour git ne se rapproche. Pour ma part, je trouve la plupart de ce qui est écrit par Scott Chacone (qui a écrit à lui seul la plupart de la documentation/des livres sur git) particulièrement déroutant.
Une chose à laquelle je peux penser est
git add .
git commit -am "message"
vs.
hg ci -Am "message"
git commit -a n'ajoute pas de fichiers nouvellement créés, hg ci -A le fait, ce qui signifie que quelque chose qui nécessite deux commandes avec git peut être fait avec une seule commande dans Mercurial. Là encore, "moins de frappe" ne signifie pas nécessairement "plus convivial".