Quelle est la différence entre Mercurial et Git ?

StackOverflow https://stackoverflow.com/questions/35837

Question

J'utilise git depuis un certain temps maintenant sous Windows (avec msysGit) et j'aime l'idée du contrôle de source distribué.Tout récemment, j'ai regardé Mercurial (hg) et cela semble intéressant.Cependant, je n’arrive pas à comprendre les différences entre hg et git.

Quelqu'un a-t-il fait une comparaison côte à côte entre git et hg ?Je suis intéressé de savoir ce qui diffère de hg et git sans avoir à me lancer dans une discussion de fanboy.

Était-ce utile?

La solution

Ces articles peuvent aider :

Modifier:Comparer Git et Mercurial à des célébrités semble être une tendance.En voici un de plus :

Autres conseils

Je travaille sur Mercurial, mais fondamentalement je pense que les deux systèmes sont équivalents.Ils travaillent tous les deux avec les mêmes abstractions :une série d'instantanés (changesets) qui constituent l'historique.Chaque ensemble de modifications sait d'où il vient (l'ensemble de modifications parent) et peut avoir plusieurs ensembles de modifications enfants.Le récent hg-git L'extension fournit un pont bidirectionnel entre Mercurial et Git et montre en quelque sorte ce point.

Git se concentre fortement sur la mutation de ce graphe historique (avec toutes les conséquences que cela implique) alors que Mercurial n'encourage pas la réécriture de l'historique, mais c'est facile à faire de toute façon et les conséquences de cette opération sont exactement celles auxquelles vous devriez vous attendre (c'est-à-dire que si je modifie un ensemble de modifications que vous avez déjà, votre client le verra comme nouveau si vous le tirez de moi).Donc Mercurial a un biais vers des commandes non destructives.

Quant aux branches légères, Mercurial a pris en charge les référentiels avec plusieurs succursales depuis..., toujours je pense.Les dépôts Git avec plusieurs branches sont exactement cela :plusieurs volets de développement divergents dans un seul référentiel.Git ajoute ensuite des noms à ces brins et vous permet d'interroger ces noms à distance.Le Signets L'extension pour Mercurial ajoute des noms locaux, et avec Mercurial 1.6, vous pouvez déplacer ces signets lorsque vous poussez/tirez.

J'utilise Linux, mais apparemment, TortoiseHg est plus rapide et meilleur que son équivalent Git sous Windows (en raison d'une meilleure utilisation du mauvais système de fichiers Windows).Les deux http://github.com et http://bitbucket.org fournir un hébergement en ligne, le service chez Bitbucket est excellent et réactif (je n'ai pas essayé github).

J'ai choisi Mercurial car il semble propre et élégant - j'ai été rebuté par les scripts shell/Perl/Ruby que j'ai reçus avec Git.Essayez de jeter un oeil à git-instaweb.sh déposer si tu veux savoir ce que je veux dire :c'est un coquille script qui génère un Rubis script, qui, je pense, exécute un serveur Web.Le script shell génère un autre script shell pour lancer le premier script Ruby.Il y a aussi un peu de Perl, pour faire bonne mesure.

J'aime le article de blog qui compare Mercurial et Git à James Bond et MacGyver – Mercurial est en quelque sorte plus discret que Git.Il me semble que les utilisateurs de Mercurial ne sont pas si facilement impressionnés.Cela se reflète dans la façon dont chaque système fait ce que Linus a décrit comme étant : "la fusion la plus cool JAMAIS!".Dans Git, vous pouvez fusionner avec un référentiel non lié en faisant :

git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit

Ces commandes semblent assez mystérieuses à mes yeux.Chez Mercurial, nous faisons :

hg pull --force <project-to-union-merge>
hg merge
hg commit

Remarquez à quel point les commandes Mercurial sont simples et n'ont rien de spécial -- la seule chose inhabituelle est le --force drapeau à hg pull, ce qui est nécessaire puisque Mercurial abandonnera sinon lorsque vous extrayez d'un référentiel non lié.Ce sont des différences comme celle-ci qui font que Mercurial me semble plus élégante.

Git est une plateforme, Mercurial n'est « que » une application.Git est une plate-forme de système de fichiers versionnée qui est livrée avec une application DVCS dans la boîte, mais comme d'habitude pour les applications de plate-forme, elle est plus complexe et présente des bords plus rugueux que les applications ciblées.Mais cela signifie également que le VCS de git est extrêmement flexible et qu'il existe une énorme quantité de choses non liées au contrôle de source que vous pouvez faire avec git.

C'est l'essence de la différence.

Git est mieux compris à partir de zéro – à partir du format du référentiel. Git Talk de Scott Chacon est une excellente introduction à cela.Si vous essayez d’utiliser git sans savoir ce qui se passe sous le capot, vous finirez par être confus à un moment donné (à moins que vous ne vous en teniez à des fonctionnalités très basiques).Cela peut paraître stupide quand tout ce que vous voulez c'est un DVCS pour votre routine de programmation quotidienne, mais le génie de git est que le format du référentiel est en réalité très simple et que vous peut comprendre l’ensemble du fonctionnement de git assez facilement.

Pour des comparaisons plus techniques, les meilleurs articles que j’ai personnellement vus sont ceux de Dustin Sallings :

Il a en fait beaucoup utilisé les deux DVCS et les comprend bien tous les deux – et a fini par préférer git.

La grande différence se situe sous Windows.Mercurial est pris en charge nativement, Git ne l'est pas.Vous pouvez obtenir un hébergement très similaire à github.com avec bitbucket.org (en fait, c'est encore mieux puisque vous obtenez un référentiel privé gratuit).J'utilisais msysGit depuis un certain temps, mais j'ai migré vers Mercurial et j'en ai été très satisfait.

Si vous êtes un développeur Windows à la recherche d'un contrôle de révision de base déconnecté, optez pour Hg.J'ai trouvé Git incompréhensible alors que Hg était simple et bien intégré au shell Windows.J'ai téléchargé Hg et suivi ce tutoriel (hginit.com) - dix minutes plus tard, j'avais un repo local et j'étais de retour au travail sur mon projet.

Je pense que la meilleure description de "Mercurial vs."Git" est :

"C'est Wesley Snipes.Mercurial est Denzel Washington"

Ils sont presque identiques.La différence la plus importante, de mon point de vue (je veux dire, la raison qui m'a poussé à choisir un DVCS plutôt qu'un autre) est la manière dont les deux programmes gèrent les branches.

Pour démarrer une nouvelle branche, avec Mercurial, il vous suffit de cloner le dépôt vers un autre répertoire et commencer à développer.Ensuite, vous tirez et fusionnez.Avec git, vous devez explicitement donner un nom à la nouvelle branche thématique que vous souhaitez utiliser, puis vous commencez à coder en utilisant le même répertoire.

En bref, chaque branche de Mercurial a besoin de son propre répertoire ;dans git, vous travaillez généralement sur un seul répertoire.Changer de branche dans Mercurial signifie changer de répertoire ;dans git, cela signifie demander à git de modifier le contenu du répertoire avec git checkout.

Je suis honnête:Je ne sais pas s'il est possible de faire la même chose avec Mercurial, mais comme je travaille habituellement sur des projets web, utiliser toujours le même répertoire avec git me semble très confortable, puisque je n'ai pas besoin de reconfigurer Apache et de redémarrer et je ne gâche pas mon système de fichiers à chaque fois que je branche.

Modifier:Comme Deestan l'a noté, Hg a branches nommées, qui peut être stocké dans un référentiel unique et permettre au développeur de changer de branche au sein de la même copie de travail.De toute façon, les branches git ne sont pas exactement les mêmes que les branches nommées Mercurial :ils sont permanents et ne jettent pas de branches, comme dans git.Cela signifie que si vous utilisez une branche nommée pour des tâches expérimentales, même si vous décidez de ne jamais la fusionner, elle sera stockée dans le référentiel.C'est la raison pour laquelle Hg encourage l'utilisation de clones pour les tâches expérimentales de courte durée et de branches nommées pour les tâches de longue durée, comme pour les branches de publication.

La raison pour laquelle de nombreux utilisateurs de Hg préfèrent les clones aux branches nommées est bien plus sociale ou culturelle que technique.Par exemple, avec les dernières versions de Hg, il est même possible de fermer une branche nommée et de supprimer récursivement les métadonnées des ensembles de modifications.

D'un autre côté, git invite à utiliser des "branches nommées" qui ne sont pas permanentes et ne sont pas stockées sous forme de métadonnées sur chaque ensemble de modifications.

De mon point de vue personnel, le modèle de git est donc profondément lié au concept de branches nommées et de basculement entre une branche et une autre au sein du même répertoire ;hg peut faire la même chose avec des branches nommées, mais cela encourage néanmoins l'utilisation de clones, ce que personnellement je n'aime pas trop.

Il y en a un énorme différence entre git et mercuriel;la façon dont ils représentent chaque commit. git représente les commits sous forme d'instantanés, tandis que mercuriel les représente comme des différences.

Qu’est-ce que cela signifie en pratique ?Eh bien, de nombreuses opérations sont plus rapides dans git, comme passer à un autre commit, comparer les commits, etc.Surtout si ces commits sont loin.

AFAIK, l'approche de Mercurial ne présente aucun avantage.

Rien.Ils font tous les deux la même chose, tous deux ont des performances à peu près égales.La seule raison pour laquelle vous devriez choisir l’un plutôt que l’autre est si vous contribuez à un projet qui en utilise déjà un.

L'autre raison possible pour en choisir un est une application ou un service qui ne prend en charge qu'un seul des systèmes.Par exemple, j'ai choisi d'apprendre git à cause de github..

Aussi la comparaison de Google (même si elle est un peu ancienne, réalisée en 2008)

http://code.google.com/p/support/wiki/DVCSAnalysis

Si je les comprends bien (et je suis loin d'être un expert dans chacun d'eux), ils ont fondamentalement chacun une philosophie différente.J'ai utilisé Mercurial pour la première fois pendant 9 mois.Maintenant, j'utilise git depuis 6.

hg est un logiciel de contrôle de version.Son objectif principal est de suivre les versions d'un logiciel.

git est un système de fichiers basé sur le temps.Son objectif est d'ajouter une autre dimension à un système de fichiers.La plupart ont des fichiers et des dossiers, git ajoute du temps.Le fait que cela fonctionne à merveille en tant que VCS est un sous-produit de sa conception.

Dans hg, il existe un historique de l'ensemble du projet qu'il essaie toujours de conserver.Par défaut, je pense que hg souhaite que tous les utilisateurs modifient tous les objets lorsqu'ils poussent et tirent.

Dans git, il n'y a qu'un pool d'objets et ces fichiers de suivi (branches/têtes) qui déterminent quel ensemble de ces objets représente l'arborescence de fichiers dans un état particulier.Lorsque vous poussez ou tirez, git envoie uniquement les objets nécessaires aux branches particulières que vous poussez ou tirez, qui sont un petit sous-ensemble de tous les objets.

En ce qui concerne git, il n'y a pas de "1 projet".Vous pourriez avoir 50 projets dans le même dépôt et git s'en moquerait.Chacun pourrait être géré séparément dans le même dépôt et fonctionner correctement.

Le concept de branches de Hg est constitué de branches hors du projet principal ou de branches hors branches, etc.Git n'a pas un tel concept.Une branche dans git n'est qu'un état de l'arborescence, tout est une branche dans git.Quelle branche est officielle, actuelle ou la plus récente n'a aucune signification dans git.

Je ne sais pas si cela avait un sens.Si je pouvais dessiner des images, hg pourrait ressembler à ceci où chaque commit est un o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

Un arbre avec une seule racine et des branches qui en sortent.Bien que git puisse le faire et que souvent les gens l'utilisent de cette façon, cela n'est pas appliqué.Une image git, si une telle chose existe, pourrait facilement ressembler à ceci

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

En fait, à certains égards, cela n'a même pas de sens d'afficher les branches dans git.

Une chose qui est très déroutante pour la discussion, git et mercurial ont tous deux ce qu'on appelle une "branche" mais ce ne sont pas du tout les mêmes choses.Une branche dans Mercurial se produit lorsqu'il y a des conflits entre différents dépôts.Une branche dans git est apparemment similaire à un clone dans hg.Mais un clone, même s'il peut donner un comportement similaire, n'est certainement pas le même.Pensez-moi à les essayer dans git vs hg en utilisant le dépôt chrome qui est plutôt volumineux.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

Et maintenant en hg en utilisant clone

$ time hg clone project/ some-clone/

updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real   0m58.196s
user   0m19.901s
sys    0m8.957

Ce sont tous deux des passages à chaud.C'est-à-dire que je les ai exécutés deux fois et c'est la deuxième fois.hg clone est en fait le même que git-new-workdir.Les deux créent un tout nouveau répertoire de travail presque comme si vous aviez tapé cp -r project project-clone.Ce n'est pas la même chose que de créer une nouvelle branche dans git.C'est un poids beaucoup plus lourd.S'il existe un véritable équivalent du branchement de git dans hg, je ne sais pas ce que c'est.

Je comprends à un certain niveau hg et git pourrait être capable de faire des choses similaires.Si tel est le cas, il existe encore une énorme différence dans le flux de travail vers lequel ils vous mènent.Dans git, le flux de travail typique consiste à créer une branche pour chaque fonctionnalité. 

git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support

Cela vient de créer 3 branches, chacune basée sur une branche appelée master.(Je suis sûr qu'il existe un moyen dans git de créer ces 1 lignes chacune au lieu de 2)

Maintenant, je vais travailler sur un, je viens de le faire

git checkout fix-game-save-bug

et commencez à travailler.Commettre des choses, etc.Passer d’une branche à l’autre, même dans un projet aussi important que Chrome, est presque instantané.En fait, je ne sais pas comment faire ça avec hg.Cela ne fait partie d'aucun tutoriel que j'ai lu.

Une autre grande différence.La scène de Git.

Git a cette idée de scène.Vous pouvez le considérer comme un dossier caché.Lorsque vous validez, vous validez uniquement ce qui se trouve sur la scène, pas les modifications apportées à votre arbre de travail.Cela peut paraître étrange.Si vous souhaitez valider toutes les modifications dans votre arbre de travail, vous le feriez git commit -a qui ajoute tous les fichiers modifiés à la scène puis les valide.

Alors à quoi sert la scène ?Vous pouvez facilement séparer vos commits.Imaginez que vous ayez modifié joypad.cpp et gamesave.cpp et que vous souhaitiez les valider séparément

git add joypad.cpp  // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp  // copies to stage
git commit -m "fixed game save bug"

Git dispose même de commandes pour décider quelles lignes particulières du même fichier vous souhaitez copier sur la scène afin que vous puissiez également diviser ces validations séparément.Pourquoi voudriez-vous faire ça ?Parce qu'en tant que validations distinctes, les autres peuvent extraire uniquement celles qu'ils souhaitent ou, en cas de problème, ils peuvent annuler uniquement la validation qui présentait le problème.

Il existe un tableau de comparaison dynamique sur le blog versioncontrol où vous pouvez comparer plusieurs systèmes de contrôle de version différents.

Voici un tableau comparatif entre git, hg et bzr.

Il existe des différences assez significatives lorsqu'il s'agit de travailler avec des succursales (surtout à court terme).

C'est expliqué dans cet article (BranchingExplained) qui compare Mercurial à Git.

Y a-t-il des collaborateurs Windows sur votre projet ?

Parce que s'il y en a, l'interface graphique de Git-pour-Windows semble maladroite, difficile et peu conviviale.

Mercurial-on-Windows, en revanche, est une évidence.

Une chose à remarquer entre Mercurial de bitbucket.org et git de github est que Mercurial peut avoir autant de référentiels privés que vous le souhaitez, mais sur Github, vous devez passer à un compte payant.C'est pourquoi j'opte pour Bitbucket qui utilise Mercurial.

L'année dernière, j'ai évalué à la fois git et hg pour mon propre usage et j'ai décidé d'opter pour hg.J'avais l'impression que cela ressemblait à une solution plus propre et fonctionnait mieux sur davantage de plates-formes à l'époque.Mais c’était surtout un coup de pile ou face.

Plus récemment, j'ai commencé à utiliser git grâce à git-svn et à la possibilité d'agir en tant que client Subversion.Cela m'a conquis et je suis maintenant complètement passé à git.Je pense que la courbe d'apprentissage est légèrement plus élevée (surtout si vous avez besoin de fouiller à l'intérieur), mais c'est vraiment un excellent système.Je vais aller lire ces deux articles comparatifs que John a publiés maintenant.

Je suis actuellement en train de migrer de SVN vers un DVCS (tout en bloguant sur mes découvertes, mon premier véritable effort de blogging...), et j'ai fait quelques recherches (= googler).Autant que je sache, vous pouvez faire la plupart des choses avec les deux packages.Il semble que Git ait quelques fonctionnalités avancées de plus ou mieux, je pense que l'intégration avec Windows est un peu meilleure pour Mercurial, avec TortoiseHG.Je sais qu'il existe également Git Cheetah (j'ai essayé les deux), mais la solution mercurielle semble simplement plus robuste.

Vu qu’ils sont tous les deux open source (n’est-ce pas ?), je ne pense pas qu’ils manqueront de fonctionnalités importantes.Si quelque chose est important, les gens le demanderont, le coderont.

Je pense que pour les pratiques courantes, Git et Mercurial sont largement suffisants.Ils ont tous les deux de gros projets qui les utilisent (Git -> noyau Linux, Mercurial -> projets de fondation Mozilla, les deux entre autres bien sûr), donc je ne pense pas qu'ils manquent vraiment de quelque chose.

Cela étant dit, je suis intéressé par ce que d'autres personnes disent à ce sujet, car cela constituerait une excellente source pour mes efforts de blogging ;-)

Il existe des tableaux et des graphiques de comparaison excellents et exhaustifs sur git, Mercurial et Bazaar sur Guide InfoQ sur le DVCS.

Je réalise que cela ne fait pas partie de la réponse, mais à ce propos, je pense également que la disponibilité de plugins stables pour des plates-formes comme NetBeans et Eclipse joue un rôle dans le choix de l'outil le mieux adapté à la tâche, ou plutôt, quel outil est la meilleure solution pour « vous ».Autrement dit, à moins que vous vraiment je veux le faire à la manière CLI.

Eclipse (et tout ce qui en découle) et NetBeans ont parfois des problèmes avec les systèmes de fichiers distants (tels que SSH) et les mises à jour externes des fichiers ;ce qui est encore une autre raison pour laquelle vous voulez que tout ce que vous choisissez fonctionne « de manière transparente ».

J'essaie de répondre à cette question par moi-même en ce moment aussi.et j'ai réduit les candidats à Git ou Mercurial ..merci à tous d'avoir fourni des contributions utiles sur ce sujet sans devenir religieux.

Encore une autre comparaison intéressante entre mercurial et git : Mercurial contre Git.L'accent est mis principalement sur les éléments internes et leur influence sur le processus de branchement.

Si vous êtes intéressé par une comparaison des performances de Mercurial et de Git, consultez Cet article.La conclusion est la suivante :

Git et Mercurial tournent tous deux en bon nombre mais font un compromis intéressant entre vitesse et taille du référentiel.Mercurial est rapide avec les ajouts et les modifications, et maintient en même temps la croissance du référentiel sous contrôle.Git est également rapide, mais son référentiel se développe très rapidement avec les fichiers modifiés jusqu'à ce que vous les remballiez – et ces reconditionnements peuvent être très lents.Mais le référentiel compressé est beaucoup plus petit que celui de Mercurial.

Le site Web Mercurial a un excellente description des similitudes et des différences entre les deux systèmes, expliquant les différences de vocabulaire et de concepts sous-jacents.En tant qu'utilisateur de longue date de Git, cela m'a vraiment aidé à comprendre l'état d'esprit de Mercurial.

Si vous migrez depuis SVN, utilisez Mercurial car sa syntaxe est BEAUCOUP plus compréhensible pour les utilisateurs SVN.A part ça, vous ne pouvez pas vous tromper non plus.Mais vérifie Tutoriel GIT et HGinit avant d’en sélectionner un.

Ce lien peut vous aider à comprendre la différencehttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

Certaines personnes pensent que les systèmes VCS doivent être compliqués.Ils encouragent à inventer des termes et des concepts sur le terrain.Ils penseraient probablement que de nombreuses thèses sur le sujet seraient intéressantes.Parmi ceux-ci se trouvent probablement ceux qui ont conçu Git.

Mercurial est conçu avec une mentalité différente.Les développeurs ne devraient pas se soucier beaucoup de VCS, et devraient plutôt consacrer leur temps à leur fonction principale :génie logiciel.Mercurial permet aux utilisateurs d'utiliser et d'abuser volontiers du système sans les laisser commettre des erreurs irrécupérables.

Tout outil professionnel doit être accompagné d’une CLI clairement conçue et intuitive.Les utilisateurs de Mercurial peuvent effectuer la majeure partie du travail en émettant des commandes simples sans aucune option étrange.Dans Git double dash, les options folles sont la norme.Mercurial a un avantage substantiel si vous êtes une personne CLI (et pour être honnête, tout ingénieur logiciel qui se respecte devrait l'être).

Pour donner un exemple, supposons que vous effectuiez un commit par erreur.Vous avez oublié de modifier certains fichiers.Pour annuler votre action dans Mercurial, vous tapez simplement :

$ hg rollback

Vous recevez alors un message indiquant que le système annule votre dernière transaction.

Dans Git, vous devez taper :

$ git reset --soft HEAD^

Alors ok, supposons que vous ayez une idée de ce qu'est la réinitialisation.Mais en plus, vous devez savoir ce que sont les réinitialisations "--soft" et "--hard" (des suppositions intuitives ?).Oh et bien sûr, n'oubliez pas le caractère '^' à la fin !(Maintenant, qu'est-ce que c'est que ça, au nom de Ritchie...)

L'intégration de Mercurial avec des outils tiers comme kdiff3 et meld est également bien meilleure.Générez vos patchs, fusionnez vos branches sans trop de complications.Mercurial comprend également un simple serveur http que vous activez en tapant

hg serve

Et laissez les autres parcourir votre référentiel.

En fin de compte, Git fait ce que Mercurial fait, d'une manière beaucoup plus compliquée et avec une CLI bien inférieure.Utilisez Git si vous souhaitez transformer le VCS de votre projet en un domaine de recherche scientifique.Utilisez Mercurial si vous souhaitez effectuer le travail VCS sans vous en soucier et concentrez-vous sur vos tâches réelles.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top