しばらく前に、グーグルはGitとMercurialの分析を行いました。あなたはそれをオンラインで読むことができます
あなたはstackoverflowでこの質問を読むことをお勧めします：
まず、どちらも古いシステムからの大きな一歩になるでしょう-悪い選択肢は本当にありません。
Gitは少し使いにくいですが、著しく高速で、間違いなくより強力です。
Mercurialはより使いやすく、TortoiseHgのおかげでWindowsではるかに使いやすくなっています。
どちらの場合でも、優れたホスティング（GitHub、Bitbucket、最終的にはGoogle Code）、多くのガイド、および他のシステムからの移行ツールのオプションがあります。 Windowsユーザーが必要な場合は、Mercurialをお勧めします。そうでない場合は、両方を試して、どちらを好むかを確認することをお勧めします。 Mercurialの方が快適だと思いますが、Gitはそれほど遅れておらず、いくつかの恐ろしいクールな機能があります（つまり、rebase -i）。
sysadminの場合、下位互換性、安定性、堅牢性、セキュリティ、およびバックアップが重要なトピックであり、新しいツールを展開することになると思います。 Mercurialに関するいくつかの情報を提供できます。
下位互換性：Mercurialには下位互換性に関する 規定のポリシー があります。ルールによると、Mercurialの異なるバージョンは常にHTTP（S）とSSHを介して相互に通信できる必要があります。
これは、サーバーを同時にアップグレードしなくても、クライアントを安全にアップグレードできることを意味します。逆の方法でサーバーを単独でアップグレードすることもできますが、新しい機能がクライアントに表示され、サーバーから何も必要としないことが多いため、これは通常それほど重要ではありません。
ディスク上のフォーマットは時々変更されます—これまでに4つの変更がありました。その場合、古いクライアントはディスク上のリポジトリでの操作を拒否します（ただし、ネットワークを介してプッシュ/プルできることを忘れないでください）。新しいクライアントは引き続き古いリポジトリ形式を読み取り/書き込みでき、リポジトリがNFSなどを介して古いクライアントと共有されている場合に、既存のリポジトリを新しい形式に自動的にアップグレードすることはありません。全体として、私たちは アップグレードを簡単にする を試みます。
出力の安定性：これは上記と密接に関連しています。 互換性ルール の一部として、Mercurialの出力が安定していることも確認します。これは、今日作成したシェルスクリプトが、明日も機能し続けることを意味します。
堅牢性：Gitと同様に、チェンジセットは、各チェンジと親チェンジセットに対して計算される暗号化ハッシュ値によって識別されます。これにより、気付かれることなく履歴の一部を変更することは不可能になります。ハッシュは、ファイルがチェックアウトされるたびに検証されます。
Mercurialリポジトリは多くの revlogファイル で構成されています。これらはappend-onlyになるように設計されており、ファイルを切り捨てるだけで、ある種のハードウェアの破損を修復できます。リポジトリでいつでも
hg verifyを使用して、Mercurialにすべてが正常であることを再確認させることができます。セキュリティ：リポジトリが[〜＃〜] ssh [〜＃〜]を使用してホストされている場合、すべてアクセス制御の通常のルールが適用されます—Mercurialは特別なことは何もしていません。したがって、ログインしてリポジトリ内のファイルを読み取ることができれば、クローンを作成することもできます。書き込みアクセス権もある場合は、リポジトリにプッシュできます。したがって、これを管理するのは簡単です。グループを設定し、グループのメンバーが新しいファイルを書き込み可能にするだけです。
HTTP（S）でホストする場合、認証を処理するのはフロントエンドWebサーバーです。リポジトリと対話するCGI（FastCGI、WSGI、およびISAPIフレーバーを使用）を提供していますが、スクリプトは認証を行っていません。これは、Mercurialを既存のセットアップと簡単に統合できることを意味します。既にActive Directoryを使用してユーザーを認証している場合は、MercurialでADを使用する準備が整っています。 ADとMercurialの詳細については、この質問 を参照してください。
最後に、提供されている
hgwebCGIスクリプトを使用する代わりに、 RhodeCode のようなものを使用できます。それはさらに議論されます この質問で 。バックアップ：追加専用の設計では、ほとんどの場合、「ライブ」リポジトリをコピーしてバックアップを作成できます。ただし、バックアッププログラムが「マニフェスト」をコピーする前に「変更ログ」をコピーする可能性があるのに対し、Mercurialは変更ログを書き込む前にマニフェストを書き込むため、この方法で取得するデータが多すぎる可能性があります。変更ログはマニフェストを参照するため、バックアップはマニフェストに参照されていないエントリで終了します。
hg verifyを実行するとこれが検出され、hg recoverは不完全なトランザクションをロールバックできます。バックアップを行うための適切な方法は、
hg cloneを使用することです。これにより、バックアップの実行中にユーザーがデータをリポジトリにプッシュしている場合でも、一貫性のあるスナップショットを確実にコピーできます。ネットワーク経由でクローンを作成できるため、データをオフサイトのマシンに簡単に送信して安全に保管できます。
gitとMercurialの違いは何ですか？
そこには多くの詳細なDVCS研究があります（上記の回答のリンクを参照してください）。私はこの最近のブログが好きでした： http://stevelosh.com/blog/2010/01/the-real-difference-between-Mercurial-and-git/ そしてそれに完全に同意します。今日（2010年の初め）のgitの主な利点は、おそらくgithubです！ :-)
それらを使用することの長所と短所は何ですか？
非常に特殊な要件がない限り、99％の時間、どちらも必要なことを実行するのに非常に優れていると言えます。
Git Windowsのサポートが良くなかったと聞きました（つまり、ほとんどのWindows開発者が持っていないCygwinが必要です）が、TortoiseGitのデモを見た後、それはもう真実ではないと思います。
また、MercurialではなくGitでファイル/ディレクトリを簡単に消去できると聞きましたが、convert --filemapを使用すると簡単に消去できることがわかりました。また、ShellまたはPythonは（コマンドの作成などに）非常に強力であり、Queue拡張機能を使用すると、Gitのようにリベースして履歴をクリーンアップできます。
要約すると、違いは小さくなる傾向があります。両方を見て、どちらかを選択してください。どちらも優れています。たとえば、Subversionをすでに知っている場合は、同様のコマンドがGitよりも一致するため、Mercurialの方が扱いやすいかもしれません。
windowsは両方のツールをどの程度サポートしていますか？
上記を参照。
お役に立てば幸いです。
乾杯、
クリストフ。
EricSinkによる分散SCMに関する記事は次のとおりです。
GitとMercurialには、異なるよりも多くの共通点があります。どちらも優れています。
私はMercurialを使用していますが、Gitの経験はありません。 Gitを使用している友人からは、慣れるのに少し時間がかかると聞いていますが、その後は素晴らしいです。
Windowsのサポート...両方にGUIフロントエンドがあると思います。 MercurialはPythonで書かれているので、問題はありません。
私は好きです 分散型リビジョン管理システム：Git vs. Mercurial vs. SVN ：
はunixと同じような一連のツールであり、配管やポーセリンなどのいくつかのレイヤーが含まれていますが、Mercurialは単一のツールです。
また、両方を学び始めたとき、Windowsでより効果的に機能するmecurialを見つけました。 Windows用の公平なgitは、現在かなり安定しています。
Gitの大きなメリットの1つは、Githubと、ソースホスティングとソーシャルネットワークを交差させてソフトウェアプロジェクトの文化を変える方法です。
他のdcvsはおそらく技術的には同等ですが、githubは私には文化的に前進した本当の一歩のように見えます。
GNOMEで分散SCMが見つかりました-> http://live.gnome.org/DistributedSCM
偏った比較については、 GitがXよりも優れている理由 を参照してください。