私はWindows（msysGitを使用）でしばらくの間gitを使用しており、分散ソース管理のアイデアが好きです。つい最近、Mercurial（hg）を見てきましたが、面白そうです。ただし、hgとgitの違いに頭を悩ませることはできません。
gitとhgを並べて比較した人はいますか？ファンボーイの議論に飛び込むことなく、hgとgitの違いを知りたいです。
632043 次
25 に答える
345
これらの記事は役立つかもしれません：
- Git vs. Mercurial：リラックスしてください（GitはMacGyverで、MercurialはJames Bondです）
- MercurialとGitの違い
編集：GitとMercurialを有名人と比較するのはトレンドのようです。もう1つあります：
于 2008-08-30T09:57:01.963 に答える
237
私は Mercurial に取り組んでいますが、基本的には両方のシステムが同等であると信じています。どちらも同じ抽象化、つまり履歴を構成する一連のスナップショット (変更セット) で動作します。各変更セットは、それがどこから来たか (親変更セット) を認識しており、多くの子変更セットを持つことができます。最近のhg-git拡張機能は、Mercurial と Git の間の双方向ブリッジを提供し、この点を示しています。
Git はこの履歴グラフを変更することに重点を置いています (それに伴うすべての結果を伴います) が、Mercurial は履歴の書き換えを推奨していませんが、とにかく簡単に行うことができ、そうすることの結果はまさに期待どおりです (つまり、 、あなたがすでに持っている変更セットを私が変更した場合、あなたが私から引っ張ると、あなたのクライアントはそれを新しいものと見なします）。そのため、Mercurial は非破壊的なコマンドに偏っています。
軽量ブランチに関しては、Mercurial はそれ以来、複数のブランチを持つリポジトリをサポートしてきました...、いつも私は思います。複数のブランチを持つ Git リポジトリは、まさにそれです: 単一のリポジトリ内の複数の分岐した開発ストランド。次に、Git はこれらのストランドに名前を追加し、これらの名前をリモートでクエリできるようにします。MercurialのBookmarks拡張機能はローカル名を追加し、Mercurial 1.6 では、プッシュ/プル時にこれらのブックマークを移動できます。
私は Linux を使用していますが、どうやら TortoiseHg は Windows 上の Git よりも高速で優れているようです (貧弱な Windows ファイルシステムをより適切に使用するため)。http://github.comとhttp://bitbucket.orgの両方がオンライン ホスティングを提供しています。Bitbucket のサービスは素晴らしく、反応が良いです (私は github を試していません)。
私が Mercurial を選んだのは、クリーンでエレガントな感じがするからです。Git で取得したシェル/Perl/Ruby スクリプトに気が進まなかったのです。私の言いたいことを知りたい場合は、git-instaweb.shファイルをのぞいてみてください。Rubyスクリプトを生成するシェルスクリプトであり、Web サーバーを実行していると思います。シェル スクリプトは、最初の Ruby スクリプトを起動する別のシェル スクリプトを生成します。また、 Perlも少しあります。
Mercurial と Git を James Bond と MacGyver と比較したブログ記事が気に入っています。Mercurial は Git よりも地味です。私には、Mercurial を使用している人はそれほど簡単には感銘を受けないように思えます。これは、Linus が「これまでで最もクールなマージ!」と表現したことを、各システムがどのように行うかに反映されています。. Git では、次のようにして無関係なリポジトリとマージできます。
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
これらのコマンドは、私の目には非常に難解に見えます。Mercurial では次のことを行います。
hg pull --force <project-to-union-merge>
hg merge
hg commit
Mercurial のコマンドが平易で特別なものではないことに注意してください。唯一変わっているのは--forceto フラグhg pullです。これは、関係のないリポジトリからプルするときに Mercurial が中止されるため必要です。Mercurial がよりエレガントに見えるのは、このような違いです。
于 2009-05-21T12:27:32.567 に答える
73
Git はプラットフォームであり、Mercurial は「単なる」アプリケーションです。Git はバージョン管理されたファイルシステム プラットフォームであり、たまたま DVCS アプリが同梱されていますが、通常のプラットフォーム アプリと同様に、Git はより複雑で、特化したアプリよりも粗いエッジを持っています。しかし、これはまた、git の VCS が非常に柔軟であり、git で実行できる非ソース管理の奥深さを意味します。
それが違いの本質です。
Git は、基礎から、つまりリポジトリの形式から理解するのが一番です。Scott Chacon の Git Talkは、これに関する優れた入門書です。内部で何が起こっているのかを知らずに git を使おうとすると、ある時点で混乱することになります (非常に基本的な機能だけに固執しない限り)。日常のプログラミング ルーチンに DVCS だけが必要な場合、これはばかげているように聞こえるかもしれませんが、git の優れた点は、リポジトリの形式が実際には非常にシンプルであり、git の操作全体を非常に簡単に理解できることです。
より専門的な比較については、私が個人的に見た中で最も優れた記事は、Dustin Sallings の次の記事です。
彼は実際に両方の DVCS を広範に使用しており、両方をよく理解しており、最終的には git を好むようになりました。
于 2008-11-03T12:30:57.260 に答える
51
大きな違いは Windows にあります。Mercurial はネイティブでサポートされていますが、Git はサポートされていません。bitbucket.orgを使用すると、github.com と非常によく似たホスティングを利用できます(実際には、無料のプライベート リポジトリを利用できるため、さらに優れています)。しばらく msysGit を使用していましたが、Mercurial に移行してとても満足しています。
于 2008-11-03T10:47:56.173 に答える
38
基本的な切断されたリビジョン管理を探している Windows 開発者は、Hg を使用してください。Hg はシンプルで Windows シェルとうまく統合されているのに対し、Git は理解できないことがわかりました。Hg をダウンロードし、このチュートリアル (hginit.com)に従いました。10分後、ローカル リポジトリが作成され、プロジェクトの作業に戻りました。
于 2010-11-26T11:49:35.043 に答える
22
「Mercurial vs. Git」についての最良の説明は次のとおりだと思います。
于 2009-05-06T05:19:00.443 に答える
20
それらはほとんど同じです。私の観点から見た最も重要な違い (つまり、私が DVCS を選択するに至った理由) は、2 つのプログラムがブランチを管理する方法です。
Mercurial で新しいブランチを開始するには、リポジトリを別のディレクトリにクローンして開発を開始するだけです。次に、プルしてマージします。git では、使用する新しいトピック ブランチに明示的に名前を付ける必要があり、その後、同じディレクトリを使用してコーディングを開始します。
つまり、Mercurial の各ブランチには独自のディレクトリが必要です。git では通常、単一のディレクトリで作業します。Mercurial でブランチを切り替えるとは、ディレクトリを変更することを意味します。git では、git checkout でディレクトリの内容を変更するように git に依頼することを意味します。
正直に言うと、Mercurial で同じことができるかどうかはわかりませんが、私は通常 Web プロジェクトに取り組んでいるので、git で常に同じディレクトリを使用することは私にとって非常に快適に思えます。 - Apache を設定して再起動すれば、分岐するたびにファイルシステムを台無しにすることはありません。
編集: Deestan が指摘したように、Hg はbranch という名前を付けました。これは単一のリポジトリに格納でき、開発者は同じ作業コピー内でブランチを切り替えることができます。いずれにしても、git ブランチは Mercurial の名前付きブランチとまったく同じではありません。それらは永続的であり、git のようにブランチを破棄しません。つまり、実験的なタスクに名前付きブランチを使用すると、マージしないことにした場合でも、リポジトリに保存されます。これが、Hg が実験的で短時間実行されるタスクにはクローンを使用し、リリース ブランチなどの長時間実行されるタスクには名前付きブランチを使用することを推奨する理由です。
多くの Hg ユーザーが名前付きブランチよりもクローンを好む理由は、技術的というよりもはるかに社会的または文化的なものです。たとえば、Hg の最新バージョンでは、名前付きブランチを閉じて、変更セットからメタデータを再帰的に削除することさえ可能です。
一方、git は、永続的ではなく、各変更セットのメタデータとして保存されない「名前付きブランチ」の使用を勧めます。
私の個人的な観点から言えば、git のモデルは、名前付きブランチの概念と深く関連しており、同じディレクトリ内のブランチと別のブランチを切り替えます。hg は名前付きブランチで同じことを行うことができますが、個人的にはあまり好きではないクローンの使用を奨励します。
于 2010-08-13T08:06:41.250 に答える
18
gitとmercurialには大きな違いが1 つあります。各コミットを表す方法。gitはコミットをスナップショットとして表し、mercurialはコミットを差分として表します。
これは実際にはどういう意味ですか？別のコミットへの切り替え、コミットの比較など、多くの操作は git の方が高速です。特に、これらのコミットが遠く離れている場合はそうです。
私の知る限り、マーキュリアルのアプローチの利点はありません。
于 2009-06-29T08:18:51.533 に答える
11
私がそれらを正しく理解している場合（そして私はそれぞれの専門家からはほど遠いです）、それらは基本的にそれぞれ異なる哲学を持っています。私は最初に水銀を9ヶ月間使用しました。今、私は6にgitを使用しました。
hgはバージョン管理ソフトウェアです。主な目標は、ソフトウェアのバージョンを追跡することです。
gitは時間ベースのファイルシステムです。目標は、ファイルシステムに別の次元を追加することです。ほとんどにファイルとフォルダーがあり、gitは時間を追加します。VCSはその設計の副産物であるため、たまたまうまく機能します。
hgには、常に維持しようとしているプロジェクト全体の履歴があります。デフォルトでは、hgは、プッシュおよびプルするときに、すべてのユーザーによるすべてのオブジェクトへのすべての変更を望んでいると思います。
gitには、オブジェクトのプールと、これらのオブジェクトのどのセットが特定の状態のファイルのツリーを表すかを決定するこれらの追跡ファイル（ブランチ/ヘッド）があります。gitをプッシュまたはプルすると、プッシュまたはプルしている特定のブランチに必要なオブジェクトのみが送信されます。これは、すべてのオブジェクトの小さなサブセットです。
gitに関する限り、「1つのプロジェクト」はありません。50個のプロジェクトをすべて同じリポジトリに含めることができ、gitは気にしません。それぞれを同じレポで別々に管理し、問題なく生きることができます。
Hgのブランチの概念は、メインプロジェクトからのブランチ、またはブランチからのブランチなどです。Gitにはそのような概念はありません。gitのブランチは単なるツリーの状態であり、すべてがgitのブランチです。どのブランチが公式、現在、または最新であるかは、gitでは意味がありません。
それが理にかなっているかどうかはわかりません。私が絵を描くことができれば、hgは次のようになります。各コミットはo
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
単一のルートとそれから出ている枝を持つ木。gitはそれを行うことができ、多くの場合、強制されていない方法でそれを使用します。git画像は、そのようなものがあれば、簡単にこのように見える可能性があります
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
実際、いくつかの点で、gitでブランチを表示することは意味がありません。
議論を非常に混乱させるものの1つは、gitとmercurialの両方に「ブランチ」と呼ばれるものがありますが、それらはリモートでは同じものではありません。Mercurialのブランチは、異なるリポジトリ間で競合が発生したときに発生します。gitのブランチは、hgのクローンに明らかに似ています。しかし、クローンは似たような振る舞いをするかもしれませんが、間違いなく同じではありません。かなり大きいクロムリポジトリを使用して、gitvshgでこれらを試してみることを検討してください。
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
そして今、クローンを使用して水銀柱インチで
$ 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
どちらもホットランです。つまり、2回実行しましたが、これは2回目の実行です。hg cloneは、実際にはgit-new-workdirと同じです。これらは両方とも、入力したかのようにまったく新しい作業ディレクトリを作成しますcp -r project project-clone。これは、gitで新しいブランチを作成することと同じではありません。それははるかに重いです。hgにgitの分岐に相当するものがある場合、それが何であるかはわかりません。
あるレベルでは、hgとgitが同様のことを実行できる可能性があることを理解しています。もしそうなら、彼らがあなたを導くワークフローにはまだ大きな違いがあります。gitでは、一般的なワークフローはすべての機能のブランチを作成することです。
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
これで3つのブランチが作成され、それぞれがマスターと呼ばれるブランチに基づいています。（gitには、2行ではなく1行ずつ作成する方法があると確信しています）
今、私はただ1つに取り組むために
git checkout fix-game-save-bug
作業を開始します。コミットなど。クロムと同じくらい大きなプロジェクトでも、ブランチ間の切り替えはほぼ瞬時に行われます。私は実際にhgでそれを行う方法を知りません。これは私が読んだチュートリアルの一部ではありません。
もう1つの大きな違い。Gitのステージ。
Gitにはこのステージのアイデアがあります。あなたはそれを隠しフォルダと考えることができます。コミットするときは、作業ツリーの変更ではなく、ステージ上にあるものだけをコミットします。それは奇妙に聞こえるかもしれません。作業ツリーのすべての変更をコミットする場合は、変更されたgit commit -aすべてのファイルをステージに追加してからコミットします。
それでは、ステージのポイントは何ですか？コミットは簡単に分離できます。joypad.cppとgamesave.cppを編集し、それらを別々にコミットしたいとします。
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には、同じファイル内のどの特定の行をステージにコピーするかを決定するコマンドもあるので、それらのコミットを個別に分割することもできます。なぜあなたはそれをしたいのですか？個別のコミットとして、他の人は必要なものだけをプルできるため、または問題が発生した場合は、問題が発生したコミットのみを元に戻すことができます。
于 2011-11-25T11:57:26.080 に答える
11
何もない。どちらも同じことを行い、ほぼ同等のパフォーマンスを発揮します。どちらかを選択する必要がある唯一の理由は、既に 1 つを使用しているプロジェクトを支援する場合です..
1つを選択するもう1つの考えられる理由は、システムの1つだけをサポートするアプリケーションまたはサービスです..たとえば、私はgithubのためにgitを学ぶことをほとんど選択しました..
于 2008-08-30T11:48:33.240 に答える
11
また、Googleの比較（少し古いですが、2008年に行われました）
于 2010-07-07T13:07:06.883 に答える
8
versioncontrolblog には動的な比較表があり、いくつかの異なるバージョン管理システムを比較できます。
于 2008-12-05T08:27:51.087 に答える
7
bitbucket.orgのmercurialとgithubのgitの間で注意すべきことの1つは、mercurialは必要な数のプライベートリポジトリを持つことができますが、githubは有料アカウントにアップグレードする必要があります。だから、私は水銀を使用するビットバケットを選びます。
于 2011-02-27T22:20:49.927 に答える
7
プロジェクトに Windows ベースの共同作業者はいますか?
あるとすれば、Git-for-Windows GUI はぎこちなく、難しく、友好的ではないように見えるからです。
対照的に、Mercurial-on-Windows は簡単です。
于 2011-01-04T23:37:37.970 に答える
5
去年のいつか、私は自分の使用のためにgitとhgの両方を評価し、hgを使うことにしました。私はそれがよりクリーンなソリューションのように見え、当時より多くのプラットフォームでよりうまく機能したと感じました。しかし、それはほとんどトスアップでした。
最近では、git-svnとSubversionクライアントとして機能する機能のためにgitを使い始めました。これは私に勝ちました、そして私は今完全にgitに切り替えました。少し高い学習曲線があると思いますが（特に内部を調べる必要がある場合）、それは本当に素晴らしいシステムです。ジョンが今投稿した2つの比較記事を読みに行きます。
于 2008-08-30T10:08:37.473 に答える
4
私は現在、SVNからDVCSへの移行の過程にあり（私の発見についてブログを書いている間、私の最初の実際のブログの取り組み...）、少し調査を行いました（=グーグル）。私が見る限り、両方のパッケージでほとんどのことができます。gitにはいくつかの高度な機能が実装されているようですが、TortoiseHgを使用すると、Windowsとの統合がMercurialにとって少し優れていると思います。Git Cheetahもあることは知っていますが（両方試してみました）、Mercurialソリューションの方が堅牢だと感じています。
どちらもオープンソースであることがわかります（右？）どちらも重要な機能が不足しているとは思いません。何かが重要な場合、人々はそれを求め、人々はそれをコーディングします。
一般的な慣習としては、GitとMercurialで十分だと思います。どちらもそれらを使用する大きなプロジェクト（Git-> linuxカーネル、Mercurial-> Mozilla Foundationプロジェクトなど）を持っているので、どちらも本当に何かが欠けているとは思いません。
そうは言っても、私は他の人がこれについて何を言っているかに興味があります。それは私のブログの取り組みの素晴らしい情報源になるからです;-)
于 2008-08-30T09:55:25.990 に答える
4
DVCS に関する InfoQ のガイドには、git、Mercurial、および Bazaar に関する優れた網羅的な比較表とチャートがあります。
于 2008-11-03T10:43:58.893 に答える
3
これは答えの一部ではないことは理解していますが、その点で、NetBeansやEclipseなどのプラットフォームで安定したプラグインを利用できることが、どのツールがタスクに適しているか、つまりどのツールに適しているかということにも影響していると思います。 「あなた」に最適です。つまり、本当にCLIで実行したい場合を除いて、CLIを使用します。
Eclipse（およびそれに基づくすべて）とNetBeansの両方で、リモートファイルシステム（SSHなど）およびファイルの外部更新で問題が発生することがあります。これが、「シームレスに」機能することを選択したもう1つの理由です。
私も今、この質問に自分で答えようとしています..そして候補者をGitまたはMercurialにまとめました..宗教的にならずにこのトピックに関する有用な情報を提供してくれてありがとう。
于 2010-10-26T22:26:32.950 に答える
2
Mercurialと git のさらに別の興味深い比較: Mercurial vs Git . 主な焦点は、内部構造と分岐プロセスへの影響です。
于 2009-05-05T15:09:53.870 に答える
2
Mercurial と Git のパフォーマンス比較に興味がある場合は、この記事をご覧ください。結論は次のとおりです。
Git と Mercurial はどちらも優れた数値を示しますが、速度とリポジトリ サイズの間には興味深いトレードオフがあります。Mercurial は、追加と変更の両方で高速であり、同時にリポジトリの成長を制御します。Git も高速ですが、そのリポジトリは、再パックするまで変更されたファイルで非常に急速に大きくなり、それらの再パックは非常に遅くなる可能性があります。しかし、パックされたリポジトリは Mercurial のものよりもはるかに小さいです。
于 2010-07-21T17:16:16.193 に答える
2
SVN から移行する場合は、SVN ユーザーにとって構文がはるかに理解しやすい Mercurial を使用してください。それ以外は、どちらでも間違いはありません。ただし、いずれかを選択する前に、 GIT チュートリアルとHGinitを確認してください。
于 2011-08-08T21:24:26.480 に答える
2
Mercurial の Web サイトには、2 つのシステムの類似点と相違点が詳しく説明されており、語彙と基本的な概念の違いが説明されています。長年の git ユーザーとして、Mercurial の考え方を理解するのに本当に役立ちました。
于 2011-08-03T09:07:08.593 に答える
1
このリンクは、違いを理解するのに役立ちます http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
于 2012-03-12T19:26:18.140 に答える
1
一部の人々は、VCS システムは複雑でなければならないと考えています。彼らは、フィールドで用語や概念を発明することを奨励しています。彼らはおそらく、このテーマに関する多数の博士号が興味深いものになると考えるでしょう。その中には、おそらく Git を設計した人もいます。
Mercurial は異なる考え方で設計されています。開発者は VCS についてあまり気にするべきではなく、代わりに自分の主な機能であるソフトウェア エンジニアリングに時間を費やすべきです。Mercurial を使用すると、ユーザーは回復不可能な間違いを犯すことなく、システムを使用して喜んで悪用することができます。
専門的なツールには、明確に設計された直感的な CLI が付属している必要があります。Mercurial ユーザーは、変なオプションなしで単純なコマンドを発行するだけで、ほとんどの作業を実行できます。Git ダブル ダッシュでは、クレイジーなオプションが標準です。もしあなたが CLI の人なら、Mercurial は大きなアドバンテージを持っています (そして、正直なところ、自尊心のあるソフトウェア エンジニアなら誰でもそうすべきです)。
例を挙げると、誤ってコミットしたとします。一部のファイルを編集するのを忘れました。Mercurial での操作を元に戻すには、次のように入力します。
$ hg rollback
その後、システムが最後のトランザクションを取り消すというメッセージが表示されます。
Git では、次のように入力する必要があります。
$ git reset --soft HEAD^
では、リセットとは何かを理解しているとしましょう。しかし、さらに、「--soft」および「--hard」リセットが何であるかを知る必要があります (直感的な推測はありますか?)。もちろん、末尾の '^' 文字を忘れないでください。（今、リッチーの名前でそれは...）
kdiff3 や meld などのサードパーティ ツールとの Mercurial の統合も、はるかに優れています。パッチを生成し、大騒ぎせずにブランチをマージします。Mercurial には、入力してアクティブ化する単純な http サーバーも含まれています。
hg serve
そして、他の人があなたのリポジトリを閲覧できるようにします。
要するに、Git は Mercurial が行うことをはるかに複雑な方法で、はるかに劣った CLI で行うということです。プロジェクトの VCS を科学研究分野に変えたい場合は、Git を使用してください。VCS の仕事をあまり気にせずに済ませたい場合は、Mercurial を使用し、実際のタスクに集中してください。
于 2012-06-25T09:03:52.710 に答える