Quelle est la différence entre Mercurial et Git?


727

J'utilise git depuis un certain temps maintenant sur Windows (avec msysGit) et j'aime l'idée du contrôle de source distribué. Récemment, j'ai regardé Mercurial (hg) et ça a l'air intéressant. Cependant, je ne peux 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 hg et git sans avoir à sauter dans une discussion fanboy.

Réponses:


345

Ces articles peuvent aider:

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


1
"Git vs Mercurial Please Relax" est sérieusement obsolète, bien qu'il soit aussi ancien que cette question. Peut-être que cette question devrait être supprimée et rouverte maintenant que les deux outils ont ajouté plus de 3 ans de fonctionnalités.
gman

238

Je travaille sur Mercurial, mais fondamentalement, je crois que les deux systèmes sont équivalents. Ils fonctionnent tous les deux avec les mêmes abstractions: une série d'instantanés (changesets) qui composent l'histoire. Chaque changeset sait d'où il vient (le changeset parent) et peut avoir de nombreux changesets enfants. La récente extension hg-git fournit un pont à double sens entre Mercurial et Git et montre en quelque sorte ce point.

Git se concentre fortement sur la mutation de ce graphique historique (avec toutes les conséquences que cela implique) alors que Mercurial n'encourage pas la réécriture de l'histoire, mais c'est facile à faire de toute façon et les conséquences de le faire sont exactement ce que vous devriez vous attendre à ce qu'elles soient (c'est-à-dire , si je modifie un ensemble de modifications que vous avez déjà, votre client le verra comme nouveau si vous retirez de moi). Mercurial a donc une préférence pour les commandes non destructives.

En ce qui concerne les branches légères, Mercurial prend en charge les référentiels avec plusieurs branches depuis ..., je pense toujours. Les référentiels 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. L' extension Signets 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 l'équivalent Git sur Windows (en raison d'une meilleure utilisation du pauvre système de fichiers Windows). Les deux http://github.com et http://bitbucket.org fournissent l' hébergement en ligne, le service à Bitbucket est grande et réactif (je n'ai pas essayé github).

J'ai choisi Mercurial car il est propre et élégant - j'ai été rebuté par les scripts shell / Perl / Ruby que j'ai obtenus avec Git. Essayez de jeter un œil au git-instaweb.shfichier si vous voulez savoir ce que je veux dire: c'est un script shell qui génère un script Ruby , 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 billet 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 "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 me semblent assez obscures. Chez Mercurial, nous faisons:

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

Remarquez à quel point les commandes Mercurial sont simples et pas spéciales du tout - la seule chose inhabituelle est le --forcedrapeau hg pull, qui est nécessaire car Mercurial abandonnera sinon lorsque vous tirez d'un référentiel non lié. Ce sont des différences comme celle-ci qui font que Mercurial me semble plus élégant.


21
Notez que TortoiseHg fonctionne également avec Nautilus, le gestionnaire de fichiers Gnome sous Linux.
oenli

4
Le script Ruby n'est généré que si le httpd est Webrick, le serveur web ruby.
alternative

4
Comme Git, Mercurial stocke des instantanés de vos fichiers lorsque vous vous engagez. Je ne suis pas d'accord que les renommages ne peuvent être suivis qu'avec une heuristique comme dans Git, il n'y a rien dans le modèle qui empêche d'ajouter des informations supplémentaires à un instantané, par exemple, renommer des informations. Nous le faisons dans Mercurial.
Martin Geisler

63
de fusion (pull) un projet sans lien avec git, vous pouvez simplement faire: git pull <url-of-project>. le courrier que vous avez cité provient des tout premiers jours de git (2005)
knittl

5
knittl: ah, bien, je suis content d'entendre que Git devient moins mystérieux. Pourtant, je pense que l'exemple montre un peu comment les systèmes diffèrent dans ce que nous pensons qu'il est cool et Git me semble plus bas niveau que Mercurial (mais pas plus puissant).
Martin Geisler

73

Git est une plateforme, Mercurial est «juste» 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 a des bords plus rugueux que les applications focalisées. Mais cela signifie également que le VCS de git est extrêmement flexible, et il y a une énorme profondeur de choses sans contrôle de source que vous pouvez faire avec git.

Voilà l'essence de la différence.

Git est mieux compris à partir du sol - 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 vous retrouverez confus à un moment donné (à moins que vous ne vous en teniez qu'à des fonctionnalités très basiques). Cela peut sembler stupide quand tout ce que vous voulez 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 fait très simple et vous pouvez comprendre toute l'opération de git assez facilement.

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

Il a en fait largement utilisé les deux DVCS et les comprend bien - et a fini par préférer git.


78
J'ai souvent lu que les gens mentionnaient que git était une "plate-forme", mais c'est plus une théorie ou un mythe commun parce qu'il n'y a pas d'exemples majeurs comme plate-forme pour faire autre chose que d'exécuter git.
Ian Kelling

@Ian - Si je ne me trompe pas, Aptana Studio 3 l'utilise pour son système de mise à jour interne.
mac

22
Donc, en un mot: Mercurial est un système de contrôle de révision distribué open source, et git est un choix de style de vie.
Tim Keating

51

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


64
Donc "nativement" n'est pas tout à fait le bon mot, mais ce n'est pas bien pris en charge sous Windows, c'est sûr.
Ian Kelling

14
git est supporté jusqu'à un certain point sur Windows. Mais essayez d'utiliser les noms de fichiers Unicode multiplateforme et voyez quelle douleur vous ressentez.
Craig McQueen

@Craig: C'est plus un défaut de plate-forme. Une plate-forme compétente vous permettrait de passer à un environnement local approprié. Si vous vous en tenez à utf-8, tout ira bien, sauf que Mac OS X a une normalisation légèrement différente de utf-8, cependant, je ne suis pas sûr que Windows vous permette même d'utiliser utf-8 ...
Arafangion

23
Windows prend en charge Unicode, bien que MS ait choisi d'opter pour UTF-16 dans son API plutôt que UTF-8. Malgré cela, il serait tout à fait possible pour git de prendre en charge les plates-formes Unicode. SVN a assez bien résolu ce problème. Mais ce n'est tout simplement pas une priorité élevée pour le développement msysGit pour le moment. code.google.com/p/msysgit/issues/detail?id=80
Craig McQueen

38

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 dépôt local et j'étais de retour pour travailler sur mon projet.


1
J'ai suivi le même tutoriel. C'est définitif.
Nathan


20

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

Pour démarrer une nouvelle branche, avec Mercurial, il vous suffit de cloner le référentiel dans un autre répertoire et de commencer à développer. Ensuite, vous tirez et fusionnez. Avec git, vous devez explicitement donner un nom à la nouvelle branche de sujet 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 changer le contenu du répertoire avec git checkout.

Je suis honnête: je ne sais pas s'il est possible de faire de même 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, car je n'ai pas besoin de re -configurez Apache et redémarrez-le et je ne salis pas mon système de fichiers à chaque fois que je branche.

Edit: Comme Deestan l'a noté, Hg a nommé des branches , qui peuvent être stockées dans un seul référentiel et permettre au développeur de changer de branche dans la même copie de travail. Les branches git ne sont pas exactement les mêmes que les branches nommées Mercurial, de toute façon: elles sont permanentes et ne jettent pas les 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 des tâches expérimentales de courte durée et des branches nommées pour des 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 à la branche nommée est beaucoup 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 changesets.

De l'autre côté, git invite à utiliser des "branches nommées" qui ne sont pas permanentes et ne sont pas stockées en tant que 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 basculer entre une branche et une autre avec le même répertoire; hg peut faire la même chose avec des branches nommées, mais pourtant, cela encourage l'utilisation de clones, que je n'aime pas trop personnellement.


6
Ce n'est pas une différence; Hg a également nommé des succursales. Nous les utilisons tout le temps pendant le développement normal au lieu de branches de clones.
Deestan

2
AFAIK, branche nommée dans Hg, est obtenue en stockant des métadonnées dans chaque commit; Je me trompe peut-être, mais j'ai lu qu'une fois que vous avez créé une branche, ses métadonnées seront intégrées dans chaque ensemble de modifications et feront partie de l'historique. C'est une énorme différence avec git. "Les clones sont parfaits pour des expériences rapides où vous ne voulez pas enregistrer un nom de branche, et les branches nommées sont bonnes pour les branches à long terme" tinyurl.com/2wz39qx Ce que j'essayais de dire avec mon message, c'est que le flux de travail standard de git vous invite utiliser une seule copie de travail; Le flux de travail standard Hg comprend des clones, qui ne répondent pas à mes besoins personnels.
Arialdo Martini

Pour une bonne explication des similitudes / différences concernant la ramification dans Git & Hg, voir: mercurial.selenic.com/wiki/GitConcepts#Branch_model
sampablokuper

2
les branches nommées en hg n'ont rien à voir avec les branches en git. En hg, il y a un vrai chemin. Toutes les branches sont des branches hors de ce chemin. Dans git, il n'y a pas un seul vrai chemin. Il y a juste différents états du dépôt et des pointeurs dans cet état. Chaque branche est juste un pointeur différent. Quel pointeur est le principal à utiliser. Les succursales sont toutes des pairs.
gman

17

Il y a une énorme différence entre git et mercurial ; la façon dont les représentent chaque commit. git représente les commits comme des instantanés, tandis que mercurial les représente comme des diffs.

Qu'est-ce que cela signifie dans la 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 il n'y a aucun avantage à l'approche de mercurial.


29
L'avantage des changesets (diffs) est de prendre moins de place. Git récupère l'espace utilisé pour les validations en utilisant la compression, mais cela nécessite une étape de recompression explicite occasionnelle ("git pack").
quark

8
Il s'appelle désormais «git gc», mais il existe différents niveaux de récupération de place, et certains niveaux sont exécutés automatiquement dans les versions récentes de git.
FelipeC

6
mercurial utilise également des instantanés
Ronny

13
Je n'arrive pas à comprendre la distinction que vous faites entre «instantanés» et «diffs». Hg et git store sont validés en tant que (groupes de) deltas de fichier . Ces deltas sont basés sur la révision précédente choisie par le SCM respectif. Avez-vous des chiffres qui montrent que git est en fait plus rapide pour les opérations que vous avez mentionnées? La mise à jour vers un autre commit passe la plupart de son temps à écrire dans le répertoire de travail, sans lire le dépôt, de toute façon.
Kevin

2
Diff de l'instantané vs diff - totalement hors de propos. Cependant, le dépôt est stocké en interne n'a aucune incidence sur ce que l'utilisateur voit. Git et mercurial présentent à l'utilisateur des «instantanés». Il n'y a aucune raison pour qu'un format de référentiel implémenté de la même manière que git ne puisse pas être ajouté à mercurial, tout comme je pense que Bazaar l'a fait.
Mark Booth

11

Rien. Ils font tous les deux la même chose, tous les deux se comportent à peu près également. La seule raison pour laquelle vous devriez choisir l'un plutôt que l'autre est si vous aidez un projet qui en utilise déjà un.

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


6
On dirait que votre réponse était beaucoup trop pragmatique. :)
Arafangion


11

Si je les comprends bien (et je suis loin d'être un expert dans chacun), ils ont fondamentalement chacun une philosophie différente. J'ai d'abord utilisé du mercure pendant 9 mois. Maintenant, j'ai utilisé git pour 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 qu'il fonctionne à merveille en tant que VCS est un sous-produit de sa conception.

Dans hg, il y a un historique de l'ensemble du projet qu'il essaie toujours de maintenir. Par défaut, je crois que hg souhaite que tous les changements soient apportés à tous les objets par tous les utilisateurs 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, ce qui est 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 tous dans le même dépôt et git s'en ficherait. Chacun pourrait être géré séparément dans le même référentiel et bien vivre.

Le concept de succursales de Hg est des succursales hors du projet principal ou des succursales, etc. Git n'a pas un tel concept. Une branche dans git n'est qu'un état de l'arbre, tout est une branche dans git. Quelle branche est officielle, actuelle ou la plus récente n'a aucun sens 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 uno

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

Un arbre avec une seule racine et des branches qui s'en détachent. Bien que git puisse le faire et souvent les gens l'utilisent de cette façon qui n'est pas appliquée. Une image git, s'il y a une telle chose, 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 de montrer les branches dans git.

Une chose qui est très déroutante pour la discussion, git et mercurial ont tous les deux quelque chose appelé une "branche" mais ils ne sont pas à distance les mêmes choses. Une branche dans mercurial se produit lorsqu'il y a des conflits entre différents repos. Une branche en git est apparemment similaire à un clone en hg. Mais un clone, bien qu'il puisse donner un comportement similaire, n'est certainement pas le même. Considérez-moi les essayer en git vs hg en utilisant le repo de chrome qui est assez grand.

$ 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

Ces deux sont des points chauds. C'est à dire, je les ai courus deux fois et c'est la deuxième manche. Le clone hg est en fait le même que git-new-workdir. Les deux font un répertoire de travail entièrement nouveau 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 beaucoup plus lourd. S'il existe un véritable équivalent de la ramification de git en hg, je ne sais pas ce que c'est.

Je comprends qu'à un certain niveau, hg et git pourraient être capables de faire des choses similaires. Si c'est le cas, il y a encore une énorme différence dans le flux de travail vers lequel ils vous mènent. Dans git, le workflow 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 y a un moyen dans git de faire ces 1 ligne chacune au lieu de 2)

Maintenant, pour travailler sur celui que je fais

git checkout fix-game-save-bug

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

Une autre grande différence. L'étape de Git.

Git a cette idée d'une scène. Vous pouvez le considérer comme un dossier caché. Lorsque vous vous engagez, vous ne validez que ce qui est sur la scène, pas les changements dans votre arborescence de travail. Cela peut sembler étrange. Si vous souhaitez valider toutes les modifications dans votre arborescence de travail, vous feriez ce git commit -aqui ajoute tous les fichiers modifiés à la scène, puis les valide.

Quel est l'intérêt de la scène alors? Vous pouvez facilement séparer vos commits. Imaginez que vous avez modifié joypad.cpp et gamesave.cpp et que vous souhaitez 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 a même des 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 que les commits séparés, les autres ne peuvent extraire que ceux qu'ils veulent ou s'il y a eu un problème, ils peuvent annuler uniquement le commit qui avait le problème.


"Git a même des 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." Quelles sont ces commandes?
James McMahon

1
@James:, git add --patchvoir linux.die.net/man/1/git-add ou utilisez git add -i, comme dans stackoverflow.com/questions/2372583/…
tanascius

@gman: au lieu de vérifier le maître et de créer des branches avec checkout -b <name>vous, vous pouvez simplement utiliser git branch <name>pour créer une nouvelle branche sans y basculer
tanascius

8

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

Voici un tableau de comparaison entre git, hg et bzr.


1
Les informations sur Mercurial ne sont pas tout à fait exactes: Mercurial a des "fusions intelligentes après des mouvements ou des renommages". Concrètement, cela signifie que si je renomme dir-a/foo.cpour dir-b/foo.cet continuer à travailler sur dir-b/foo.c, votre travail sur dir-a/foo.csera fusionné correctement avec mon travail après une traction.
Martin Geisler

Les informations (provenant de la comparaison de l' Initiative Better SCM , IIRC) sur Git sont également inexactes ou même inavlides à quelques endroits.
Jakub Narębski


7

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

Parce que s'il y en a, l'interface graphique Git-for-Windows semble maladroite, difficile, hostile.

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


J'aime git, mais je dois être d'accord ici. Git a une ligne de commande plus agréable avec la scène et une meilleure documentation. Je serais heureux d'utiliser les commandes git avec un shell posix. Cependant tortoiseHG sur Windows est génial, il s'intègre même avec plusieurs outils de diff (au-delà de la comparaison) et a un support complet pour les sous-dépôts, et de nombreux plugins hg comme strip / mq
Keyo

Il existe au moins une très bonne interface graphique Git pour Windows (et OS X + Linux).
Mot

7

Une chose à noter 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 github vous devez passer à un compte payant. C'est pourquoi je choisis Bitbucket qui utilise mercurial.


5

L'an dernier, j'ai évalué à la fois git et hg pour mon propre usage, et j'ai décidé d'y aller avec hg. Je sentais que cela ressemblait à une solution plus propre et fonctionnait mieux sur plus de plates-formes à l'époque. Mais c'était surtout un coup sec.

Plus récemment, j'ai commencé à utiliser git en raison de git-svn et de la possibilité d'agir en tant que client Subversion. Cela m'a conquis et je suis maintenant passé complètement à git. Je pense qu'il a une courbe d'apprentissage légèrement plus élevée (surtout si vous devez 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.


4
Jetez un oeil à hgsubversion: bitbucket.org/durin42/hgsubversion . Il nécessite actuellement une version de développement de Mercurial, mais ils feront une version pour Mercurial 1.3, qui est prévue pour le 1er juillet.
Martin Geisler

4

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 plus ou mieux implémentées, je pense que l'intégration avec Windows est un peu meilleure pour mercurial, avec TortoiseHg. Je sais qu'il y a aussi Git Cheetah (j'ai essayé les deux), mais la solution mercurielle semble juste plus robuste.

Voyant comment ils sont tous deux open-source (non?) Je ne pense pas non plus qu'il manquera de fonctionnalités importantes. Si quelque chose est important, les gens le demanderont, les gens le coderont.

Je pense que pour les pratiques courantes, Git et Mercurial sont plus que suffisants. Ils ont tous les deux de grands 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'il manque vraiment quelque chose.

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


1
Oui, ce sont deux projets open source.
Martin Geisler


3

Je me rends compte que cela ne fait pas partie de la réponse, mais sur cette note, je pense également que la disponibilité de plugins stables pour des plates-formes comme NetBeans et Eclipse jouent un rôle dans lequel l'outil est le mieux adapté à la tâche, ou plutôt, quel outil est la meilleure solution pour "vous". Autrement dit, sauf si vous voulez vraiment le faire de 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 pour moi aussi en ce moment .. et j'ai résumé les candidats à Git ou Mercurial .. merci à tous d'avoir fourni des contributions utiles sur ce sujet sans devenir religieux.


2
+1, car l'expérience "transparente" est plus importante que ne le pensent les personnes qui ne travaillent pas avec ces choses. Un plugin solide pour l'IDE fait beaucoup de différence.
eksortso

2

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


2

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

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



2

Si vous migrez depuis SVN, utilisez Mercurial car sa syntaxe est BEAUCOUP plus compréhensible pour les utilisateurs de SVN. A part ça, vous ne pouvez pas vous tromper non plus. Mais vérifiez le tutoriel GIT et HGinit avant de sélectionner l'un d'entre eux.



1

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 nombreux doctorats sur le sujet seraient intéressants. 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: l'ingénierie logicielle. Mercurial permet aux utilisateurs d'utiliser et d'abuser avec plaisir du système sans les laisser faire des erreurs non récupérables.

Tout outil professionnel doit être livré avec une CLI clairement conçue et intuitive. Les utilisateurs de Mercurial peuvent faire la plupart 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 effectuez une validation par erreur. Vous avez oublié de modifier certains fichiers. Pour annuler votre action dans Mercurial, il vous suffit de taper:

$ hg rollback

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

Dans Git, vous devez taper:

$ git reset --soft HEAD^

Donc, supposons que vous ayez une idée de 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 au nom de Ritchie, c'est que ...)

L'intégration de Mercurial avec des outils tiers tels que kdiff3 et meld est également bien meilleure. Générez vos patchs fusionnez vos branches sans trop de tracas. 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 fait Mercurial, 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 voulez faire le travail VCS sans vous en soucier et concentrez-vous sur vos tâches réelles.


1
En fait, vous pouvez alias les commandes dans git , ce qui rend la CLI moins compliquée à utiliser. Il y en a un tas dans cette question SuperUser (StackExchange) .
Spoike

1
Vraiment oui, vous pouvez également écrire des scripts shell pour gérer certaines tâches courantes. Finalement, vous commencez à réaliser que vous construisez une interface de ligne de commande wrapper pour gérer un VCS qui a une CLI mal conçue et contre-intuitive. Et ce n'est pas seulement ça. Git introduit un tas de concepts avec une facilité d'utilisation douteuse que l'utilisateur est finalement obligé d'apprendre et de comprendre afin de se sentir à l'aise avec la documentation et les messages CLI.
Kostas
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.