Question Quelle est la différence entre Mercurial et Git?


J'utilise git depuis quelque temps sur Windows (avec msysGit) et j'aime l'idée du contrôle de source distribué. Tout récemment, j'ai regardé Mercurial (hg) et ça a l'air intéressant. Cependant, je ne peux pas envelopper ma tête autour des différences entre hg et git.

Quelqu'un at-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 de fanboy.


729


origine


Réponses:


Ces articles peuvent aider:

modifier: Comparant Git et Mercurial aux célébrités semble être une tendance. En voici un de plus:


345



Je travaille sur Mercurial, mais fondamentalement, je crois 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 composent l'histoire. Chaque changeset sait d'où il vient (le parent changeset) et peut avoir beaucoup de changesets enfants. Le récent hg-git l'extension fournit un pont bidirectionnel entre Mercurial et Git et sorte de montre ce point.

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

Comme pour les branches légères, Mercurial a pris en charge des dépôts avec plusieurs branches depuis ..., toujours je pense. Les dépôts Git avec plusieurs branches sont exactement cela: plusieurs brins divergents de développement dans un seul dépôt. Git ajoute ensuite des noms à ces brins et vous permet d'interroger ces noms à distance. le Signets 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 l'équivalent Git sur Windows (en raison d'une meilleure utilisation du mauvais système de fichiers Windows). Tous les deux http://github.com et http://bitbucket.org fournir un hébergement en ligne, le service à Bitbucket est super 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 eu avec Git. Essayez de jeter un coup d'œil à la git-instaweb.sh fichier si tu veux savoir ce que je veux dire: c'est un coquille script qui génère un Rubis script, qui je pense dirige 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 avec James Bond et MacGyver - Mercurial est en quelque sorte plus discret que Git. Il me semble que les gens qui utilisent 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 semblent assez mystérieuses à mes yeux. Chez Mercurial nous faisons:

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

Remarquez que les commandes de Mercurial sont claires et pas spéciales du tout - la seule chose inhabituelle est la --force drapeau à hg pull, ce qui est nécessaire puisque Mercurial va avorter autrement lorsque vous extrayez d'un référentiel non apparenté. Ce sont ces différences qui font que Mercurial me semble plus élégant.


238



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 brusques que les applications ciblées. Mais cela signifie aussi que le VCS de git est extrêmement flexible, et qu'il y a une énorme quantité de choses que vous pouvez faire avec git.

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

Git est mieux compris dès le départ - depuis le format du référentiel. Git Talk de Scott Chacon est un excellent début pour 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 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 dépôt est en fait très simple et vous pouvez comprendre l'opération entière de git assez facilement.

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

Il a réellement utilisé les deux DVCS et les comprend tous les deux - et a fini par préférer git.


73



La grande différence est sur Windows. Mercurial est soutenu nativement, Git ne l'est pas. Vous pouvez obtenir un hébergement très similaire à github.com avec bitbucket.org (en fait encore mieux que vous obtenez un dépôt privé gratuit). J'utilisais msysGit depuis un moment mais je suis passé à Mercurial et j'en étais très content.


51



Si vous êtes un développeur Windows à la recherche d'un contrôle de révision de base déconnecté, rendez-vous sur Hg. J'ai trouvé Git incompréhensible alors que Hg était simple et bien intégré avec le 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.


38



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

"Git est Wesley Snipes, Mercurial est Denzel Washington"


22



Ils sont presque identiques. La différence la plus importante, de mon point de vue (je veux dire, la raison pour laquelle j'ai choisi un DVCS plutôt qu'un autre) est de savoir comment 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 commencez à développer. Ensuite, vous tirez et fusionnez. Avec git, vous devez explicitement donner un nom à la nouvelle branche de sujet que vous voulez 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; en git vous travaillez habituellement dans 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 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 à -configurez Apache et redémarrez-le et je ne gâche pas mon système de fichiers chaque fois que je branche.

Edit: Comme l'a noté Deestan, Hg a branches nommées, qui peut être stocké 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 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 beaucoup d'utilisateurs de Hg préfèrent les clones sur une 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 changeset.

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


20