GitとMercurial-比較とコントラスト
しばらくの間、私は個人的なプロジェクトにSubversionを使用しています。
GitとMercurial、およびDVCS全般について、私はどんどん耳を傾けています。
私はDVCS全体を旋回させたいと思いますが、どちらのオプションにもあまり詳しくありません。
MercurialとGitの違いは何ですか？
注：私はnotのどれが「最良」であるか、またはどれから始めるべきかを見つけようとしています。実装と哲学の点でどのように異なるのかを知りたいので、私は主にそれらが類似している主要な分野を探しています。
これらの2つのビデオをうなずくことで、これらのシステムの類似点または相違点を把握できると思います。
GitのLinus Torvalds（ http://www.youtube.com/watch?v=4XpnKHJAok8 ）
Bryan O'Sullivan on Mercurial（ http://www.youtube.com/watch?v=JExtkqzEoHY ）
どちらも設計は非常に似ていますが、実装は大きく異なります。
Mercurialを使用しています。私がGitを理解している限り、gitの主な違いの1つは、ファイル自体ではなくファイルの内容を追跡することです。 Linusによれば、あるファイルから別のファイルに関数を移動すると、Gitは移動中のその単一の関数の履歴を通知します。
彼らはまた、gitはHTTPよりも遅いが、独自のネットワークプロトコルとサーバーを持っていると言っています。
Gitは、MercurialよりもSVNシッククライアントとして適切に機能します。 SVNサーバーに対してプルおよびプッシュできます。この機能はまだMercurialで開発中です
MercurialとGitの両方には、非常に素晴らしいWebホスティングソリューション（BitBucketとGitHub）がありますが、Google CodeはMercurialのみをサポートしています。ところで、どちらをサポートするかを決定するために行ったMercurialとGitの非常に詳細な比較があります（ http://code.google.com/p/support/wiki/DVCSAnalysis ）。たくさんの良い情報があります。
少し前にMercurialの分岐モデルに関するブログエントリを書き、gitの分岐モデルとの比較を含めました。面白いかもしれません： http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-Mercurial/
私は両方を非常に定期的に使用しています。主な機能上の違いは、リポジトリ内でのGitとMercurialの名前の分岐方法です。 Mercurialでは、ブランチ名がクローン化され、それらの変更セットとともにプルされます。 Mercurialの新しいブランチに変更を追加し、別のリポジトリにプッシュすると、ブランチ名が同時にプッシュされます。そのため、Mercurialではブランチ名は多かれ少なかれグローバルであり、ブックマーク拡張機能を使用してローカルのみの軽量名にする必要があります（必要な場合、Mercurialはデフォルトで匿名の軽量コードラインを使用します。 「ヘッド」と呼ばれます）。 Gitでは、ブランチ名とそのリモートブランチへの単射マッピングはローカルに保存されるため、それらを明示的に管理する必要があります。つまり、その方法を知っている必要があります。これは、GitがMercurialよりも学習や使用が難しいという評判を得ているところです。
他の人がここで注意するように、たくさんの小さな違いがあります。枝を持つものは大きな差別化要因です。
Git vs. Mercurial：Please Relax Patrick Thomsonによるブログ投稿をご覧ください。
GitはMacGyver、MercurialはJames Bond
このブログ投稿は2008年8月7日のものであり、SCMは両方とも大幅に改善されていることに注意してください。
Mercurialはほぼ完全にPythonで書かれています。 GitのコアはCで記述され（Mercurialよりも高速でなければなりません）、sh、Perl、tclで記述され、標準のGNU utilsを使用するツールです。したがって、これらすべてのユーティリティとインタープリターを、それらを含まないシステム（Windowsなど）に持ってくる必要があります。
両方のサポートはSVNで機能しますが、WindowsのgitではAFAIK svnサポートが壊れています（私は単に不幸な人であるかもしれません）。 gitとMercurialの相互運用を可能にする拡張機能もあります。
Mercurialにはすてきな Visual Studio統合 があります。前回確認したとき、 Gitのプラグイン は動作していましたが、非常に低速でした。
基本的なコマンドセットは非常に似ています（init、clone、add、status、commit、push、pullなど）。したがって、基本的なワークフローは同じです。また、両方にTortoiseSVNのようなクライアントがあります。
Mercurialの拡張機能はpython（驚くことではありません！）で記述でき、gitの場合は任意の実行可能形式（実行可能バイナリ、シェルスクリプトなど）で記述できます。 git bisectなど、一部の拡張機能は非常に強力です。
適切なWindowsサポートが必要な場合は、Mercurialをお勧めします。 TortoiseHg （Windows Explorerプラグイン）は、かなり複雑なツールへの使いやすいグラフィカルインターフェイスを提供します。ここでの状態として、 Visual Studioプラグイン もあります。ただし、前回試したとき、SVNインターフェースはWindowsではうまく機能しませんでした。
コマンドラインインターフェイスを気にしない場合は、Gitをお勧めします。技術的な理由ではなく、戦略的な理由です。 gitの採用率はmuchより高くなっています。 cvs/svnからMercurialに切り替えている有名なオープンソースプロジェクトの数と、Gitに切り替えている数を確認してください。 Mercurialホスティングと比較して、gitサポートで見つけることができるコード/プロジェクトホスティングプロバイダーの数を確認してください。
GitとMercurialを使い始めたとき、Mercurialの方がずっと簡単に読んだ後（インターネットコミュニティがすべての意見であると信じています）、Gitの方が比較的簡単に適応できると感じました（私は始めました） TortoiseHgでMercurialを使用）コマンドラインから作業する場合、主にgitコマンドは私に従って適切に命名され、数が少ないためです。MercurialはGitコマンドは、状況に応じて多目的に使用できます（たとえば、checkout）。 Gitは当時はより困難でしたが、現在ではその違いはほとんどありません。 YMMV .. TortoiseHgのような優れたGUIクライアントを使用すると、Mercurialでの作業がはるかに簡単になり、少し混乱するコマンドを覚える必要がありませんでした。同じアクションのすべてのコマンドがどのように変化したかについては詳しく説明しませんが、2つの包括的なリストがあります： Mercurial自身のサイトから1 および wikivsから2番目 .
╔═════════════════════════════╦════════════════════════════════════════════════════════════════════════════════════════════════╗
║ Git ║ Mercurial ║
╠═════════════════════════════╬════════════════════════════════════════════════════════════════════════════════════════════════╣
║ git pull ║ hg pull -u ║
║ git fetch ║ hg pull ║
║ git reset --hard ║ hg up -C ║
║ git revert <commit> ║ hg backout <cset> ║
║ git add <new_file> ║ hg add <new_file> (Only equivalent when <new_file> is not tracked.) ║
║ git add <file> ║ Not necessary in Mercurial. ║
║ git add -i ║ hg record ║
║ git commit -a ║ hg commit ║
║ git commit --amend ║ hg commit --amend ║
║ git blame ║ hg blame or hg annotate ║
║ git blame -C ║ (closest equivalent): hg grep --all ║
║ git bisect ║ hg bisect ║
║ git rebase --interactive ║ hg histedit <base cset> (Requires the HisteditExtension.) ║
║ git stash ║ hg shelve (Requires the ShelveExtension or the AtticExtension.) ║
║ git merge ║ hg merge ║
║ git cherry-pick <commit> ║ hg graft <cset> ║
║ git rebase <upstream> ║ hg rebase -d <cset> (Requires the RebaseExtension.) ║
║ git format-patch <commits> ║ hg email -r <csets> (Requires the PatchbombExtension.) ║
║ and git send-mail ║ ║
║ git am <mbox> ║ hg mimport -m <mbox> (Requires the MboxExtension and the MqExtension. Imports patches to mq.) ║
║ git checkout HEAD ║ hg update ║
║ git log -n ║ hg log --limit n ║
║ git Push ║ hg Push ║
╚═════════════════════════════╩════════════════════════════════════════════════════════════════════════════════════════════════╝
Gitはコミットされたファイルのすべてのバージョンの記録を内部的に保存しますが、Hgはフットプリントの小さい変更セットのみを保存します。 Gitを使用すると、Hgと比較して履歴を変更するのが簡単になりますが、それでもヘイトイットオアラブイット機能です。前者はHg、後者はGitが好きです。
Hgで見落としているのは、Gitのサブモジュール機能です。 Hgにはサブリポジトリがありますが、Gitサブモジュールではありません。
2つの周りの生態系は、選択に影響を与える可能性があります。Gitはより人気が高い必要があります（しかし、それは簡単です）、Gitには GitHub があり、Mercurialには BitBucket があります。 Gitに適した同等物は見ていません。
それぞれに長所と短所があり、どちらも失うことはありません。
スコットチャコンの投稿 しばらく前から確認してください。
Gitは「より複雑」であるという評判があると思いますが、私の経験では、必要以上に複雑ではありません。 IMO、gitモデルはwayわかりやすいです（タグにはコミット（および0個以上の親コミットへのポインター）が含まれ、ツリーにはBLOBや他のツリーが含まれます）。 .. done）。
GitがMercurialよりも混乱しないというのは私の経験だけではありません。もう一度 Scott Chaconからのこのブログ投稿 を読んでお勧めします。
私は現在の仕事でGitを1年以上使用しており、それ以前は以前の仕事で1年以上Mercurialを使用していました。ユーザーの観点から評価を提供します。
まず、両方とも分散バージョン管理システムです。分散型バージョン管理システムでは、従来のバージョン管理システムから考え方を変える必要がありますが、実際に理解すると、多くの点ではるかにうまく機能します。このため、私はGitとMercurialの両方がSubversion、Perforceなどよりはるかに優れていると考えています。分散バージョン管理システムと従来のバージョン管理システムの違いは、GitとMercurialの違いよりもはるかに大きいです。
ただし、GitとMercurialには大きな違いもあり、それぞれがユースケースのサブセットに適しています。
Mercurialの学習は簡単です。 Mercurialを数週間使用した後、ドキュメントやメモを参照することはほとんどありませんでした。 Gitを1年間使用した後でも、Gitで定期的にメモを参照する必要があります。 Gitはかなり複雑です。
これは、Mercurialが単なるクリーナーであるためです。 Mercurialで手動で分岐する必要はほとんどありません。 Mercurialは、必要に応じて匿名ブランチを自動的に作成します。水銀の命名法はより直感的です。 Gitの場合のように「フェッチ」と「プル」の違いを心配する必要はありません。 Mercurialは少しバグが少ないです。 GitとMercurialの両方を備えたプラットフォーム間でプロジェクトをプッシュするときに問題を引き起こすために使用されるファイル名の大文字と小文字の区別の問題があります。これは先ほどMeritialで修正されていましたが、前回チェックしたGitでは修正されていませんでした。ファイルの名前変更についてMercurialに通知できます。 Gitでは、名前の変更が自動的に検出されない場合（私の経験では命題が非常にヒットまたはミスです）、名前の変更はまったく追跡できません。
しかし、Gitの追加の複雑さのもう1つの理由は、追加の機能とパワーをサポートするためにGitの多くが必要だからです。はい、Gitでブランチを処理するのはより複雑です-一方、ブランチを取得したら、Mercurialでは事実上不可能なブランチで処理を行うことはそれほど難しくありません。ブランチのリベースは次のいずれかです。ブランチを移動して、ブランチのベースがブランチの状態ではなく、トランクの状態になるようにすることができます。同じコードベースで作業する人が多い場合、バージョン履歴が大幅に簡素化されます。これは、トランクへのプッシュのそれぞれが、絡み合っているのではなく、シーケンシャルに見えるようにできるためです。同様に、ブランチ上の複数のコミットを単一のコミットにまとめるのがはるかに簡単です。これはバージョン管理履歴をきれいに保つのに役立ちます：理想的には、機能のすべての作業はトランクで単一のコミットとして表示され、すべてのマイナーを置き換えます開発者が機能の開発中に作成したコミットおよびサブブランチ。
最終的には、MercurialとGitのどちらを選択するかは、バージョン管理プロジェクトの規模に依存し、同時に作業する人の数で測定する必要があると思います。たとえば、単一のモノリシックWebアプリケーションで多数のグループが作業している場合、Gitのより強力なブランチ管理ツールを使用すると、プロジェクトにより適したものになります。一方、チームが1つのコンポーネントで同時に作業する開発者が1人または2人だけの異種分散システムを開発している場合、各コンポーネントプロジェクトにMercurialリポジトリを使用すると、より少ないリソースでよりスムーズに開発を進めることができますリポジトリ管理のオーバーヘッド。
結論：単一の巨大なアプリケーションを開発している大きなチームがある場合は、Gitを使用します。個々のアプリケーションが小さく、規模がそのようなアプリケーションのサイズではなく数である場合は、Mercurialを使用してください。
DVCS自体とはまったく関係のない1つの違い：
GitはC開発者に非常に人気があるようです。 GitはLinuxカーネルの事実上のリポジトリであり、これがC開発者に非常に人気がある理由です。これは、Linux/Unixの世界でのみ働く贅沢を持っている人に特に当てはまります。
Java開発者はGitよりもMercurialを好むようです。その理由はおそらく2つあります。1つは、JDK自体を含む非常に大きなJavaプロジェクトがMercurialでホストされていることです。もう1つは、Mercurialの構造と明確なドキュメントがJavaキャンプから来ている人々にアピールするのに対し、そのような人々はGitの一貫性のないwrtコマンドの命名とドキュメントの欠如を見つけます。私はそれが実際に真実であると言っているのではなく、人々が彼らの通常の生息地から何かに慣れていると言っているのです。
Python開発者はほとんどMercurialを好んでいると思います。 MercurialがPythonに基づいているという事実以外には、実際には合理的な理由はありません。 （私もMercurialを使用しており、DVCSの実装言語について人々が大騒ぎする理由を本当に理解していません。Pythonの言葉を理解していません。 Pythonに基づいていることがどこかにリストされている場合、私は知らなかったでしょう）。
あるDVCSが別のDVCSに適しているとは言えないので、その中から選択すべきではありません。しかし、実際には、人々は、コミュニティの一部として最もDVCSにさらされるDVCSに基づいて（部分的に）選択します。
（いいえ、私は上記の主張をバックアップする使用統計を持っていません..それはすべて私自身の主観に基づいています）