Mercurial と Git の違いは何ですか?

StackOverflow https://stackoverflow.com/questions/35837

質問

私は Windows 上でしばらく git (msysGit を使用) を使用してきましたが、分散ソース管理のアイデアが気に入っています。つい最近、マーキュリアル(hg)を眺めているんですが、面白そうです。しかし、hg と git の違いがよくわかりません。

git と hg を並べて比較した人はいますか?私は、ファンボーイの議論に飛び込むことなく、hg と git の違いを知りたいと思っています。

役に立ちましたか？

解決

これらの記事は次の場合に役立ちます。

編集:Git と Mercurial を有名人に喩えるのがトレンドのようです。もう 1 つ:

他のヒント

私は Mercurial に取り組んでいますが、基本的には両方のシステムが同等であると考えています。どちらも同じ抽象化で動作します。履歴を構成する一連のスナップショット (変更セット)。各変更セットは、それがどこから来たのか (親変更セット) を知っており、多くの子変更セットを持つことができます。最近の hg-git 拡張機能は Mercurial と Git 間の双方向のブリッジを提供し、この点を示しています。

Git はこの履歴グラフを (それに伴うすべての結果を伴う) 変更することに重点を置いていますが、Mercurial は履歴の書き換えを推奨しません。 でもとにかく簡単にできる そして、そうすることの結果は、まさにあなたが期待するものになります（つまり、私があなたがすでに持っている変更セットを変更した場合、あなたが私からプルした場合、あなたのクライアントはそれを新しいものとして認識します）。つまり、Mercurial には バイアス 非破壊的なコマンドに向けて。

軽量ブランチに関しては、Mercurial はリポジトリをサポートしています。 複数の支店 以来…、いつも思う。複数のブランチを持つ Git リポジトリは、まさに次のとおりです。複数の分岐した開発を 1 つのリポジトリにまとめます。その後、Git はこれらのストランドに名前を追加し、これらの名前をリモートでクエリできるようにします。の ブックマーク Mercurial の拡張機能によりローカル名が追加され、Mercurial 1.6 ではプッシュ/プル時にこれらのブックマークを移動できます。

私は Linux を使用していますが、どうやら TortoiseHg は Windows 上の同等の Git よりも高速で優れています (貧弱な Windows ファイルシステムをより適切に使用できるため)。両方 http://github.com そして http://bitbucket.org オンライン ホスティングを提供する Bitbucket のサービスは素晴らしく、応答性が優れています (github は試したことはありません)。

Mercurial を選んだのは、すっきりしていてエレガントだと感じたからです。Git で入手した Shell/Perl/Ruby スクリプトにはがっかりしました。覗いてみてください git-instaweb.sh ファイル 私の言っている意味を知りたければ：それは シェル を生成するスクリプト ルビー スクリプトはWebサーバーを実行すると思います。シェル スクリプトは、最初の Ruby スクリプトを起動するための別のシェル スクリプトを生成します。も少しあります パール, 、念のため。

私は好き ブログ投稿 これは Mercurial と Git をジェームズ ボンドとマクガイバーにたとえたものです -- 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 コマンドが単純で、まったく特殊ではないことに注目してください。唯一珍しいのは、 --force にフラグを立てる hg pull, これは、無関係なリポジトリからプルすると Mercurial が中止されるため必要です。私にとって Mercurial がよりエレガントに見えるのは、このような違いです。

Git はプラットフォームであり、Mercurial は「単なる」アプリケーションです。Git はバージョン管理されたファイルシステム プラットフォームで、たまたま DVCS アプリが同梱されていますが、プラットフォーム アプリの常として、特化したアプリよりも複雑で荒削りな部分があります。しかし、これは、git の VCS が非常に柔軟であり、git を使用して実行できるソース管理以外の機能が非常に豊富であることも意味します。

それが違いの本質です。

Git は、リポジトリの形式から徹底的に理解するのが最も効果的です。 Scott Chacon の Git トーク はこのための優れた入門書です。内部で何が起こっているかを知らずに git を使用しようとすると、ある時点で混乱することになります (非常に基本的な機能だけに固執しない限り)。日常のプログラミング ルーチンに必要なのは DVCS だけである場合、これは愚かに聞こえるかもしれませんが、git の優れた点は、リポジトリ形式が実際には非常にシンプルであり、 できる git の操作全体を非常に簡単に理解できます。

より専門的な比較については、私が個人的に見た中で最も優れた記事は、Dustin Sallings の次の記事です。

彼は実際に両方の DVCS を広範囲に使用しており、両方をよく理解しているため、最終的には git を好むようになりました。

大きな違いは Windows にあります。Mercurial はネイティブにサポートされていますが、Git はサポートされていません。非常によく似たホスティングを実現できます github.com と bitbucket.org (実際には、無料のプライベート リポジトリを入手できるため、さらに優れています)。しばらく msysGit を使用していましたが、Mercurial に移行して非常に満足しています。

Windows 開発者で、基本的な切断されたリビジョン管理を探している場合は、Hg を使用してください。Git は理解できないのに対し、Hg はシンプルで Windows シェルとよく統合されていることがわかりました。Hgをダウンロードしてフォローしました このチュートリアル (hginit.com) - 10 分後、ローカル リポジトリが作成され、プロジェクトの作業に戻りました。

それらはほぼ同一です。私の観点から見ると、最も重要な違い (つまり、一方の DVCS を他方ではなく選択した理由) は、2 つのプログラムがブランチを管理する方法です。

Mercurial で新しいブランチを開始するには、リポジトリのクローンを作成するだけです。 別のディレクトリに そして開発を開始します。次に、プルしてマージします。git では、使用する新しいトピック ブランチに名前を明示的に指定してからコーディングを開始する必要があります。 同じディレクトリを使用する.

つまり、Mercurial の各ブランチには独自のディレクトリが必要です。git では通常、単一のディレクトリで作業します。Mercurial でブランチを切り替えることは、ディレクトリを変更することを意味します。git では、git checkout を使用してディレクトリの内容を変更するように git に要求することを意味します。

私は正直です：Mercurial で同じことが可能かどうかはわかりませんが、私は普段 Web プロジェクトで作業しているため、git で常に同じディレクトリを使用する方が、Apache を再構成して再起動する必要がないため、非常に快適に思えます。これにより、ブランチするたびにファイルシステムが台無しになることはありません。

編集：Deestan が指摘したように、Hg は 名前付きブランチ, 、単一のリポジトリに保存でき、開発者は同じ作業コピー内でブランチを切り替えることができます。とにかく、git ブランチは Mercurial の名前付きブランチとまったく同じではありません。これらは永続的であり、git のようにブランチを破棄しません。つまり、実験的タスクに名前付きブランチを使用する場合、それをマージしないことに決めた場合でも、そのブランチはリポジトリに保存されます。これが、Hg が実験的な短時間実行タスクにはクローンを使用し、リリース ブランチなどの長時間実行タスクには名前付きブランチを使用することを推奨している理由です。

多くの Hg ユーザーが名前付きブランチよりもクローンを好む理由は、技術的なものよりもはるかに社会的または文化的なものです。たとえば、Hg の最後のバージョンでは、名前付きブランチを閉じて、変更セットからメタデータを再帰的に削除することも可能です。

一方、git は、永続的ではなく、各変更セットにメタデータとして保存されない「名前付きブランチ」の使用を促します。

私の個人的な観点から言えば、git のモデルは名前付きブランチの概念と深く結びついており、同じディレクトリ内でブランチとブランチを切り替えることができます。hg は名前付きブランチでも同じことができますが、クローンの使用を奨励するため、個人的にはあまり好きではありません。

1つあります 巨大な との差 ギット そして 水銀の;各コミットを表す方法。 ギット はコミットをスナップショットとして表しますが、 水銀の それらを差分として表します。

これは実際には何を意味するのでしょうか?そうですね、別のコミットへの切り替えやコミットの比較など、多くの操作は git の方が高速です。特にこれらのコミットが遠くにある場合。

私の知る限り、mercurial のアプローチには利点がありません。

何もない。どちらも同じことを行い、どちらもほぼ同等のパフォーマンスを発揮します。どちらか一方を選択する必要がある唯一の理由は、既に使用しているプロジェクトを支援する場合です。

いずれかを選択するもう 1 つの理由としては、いずれかのシステムのみをサポートするアプリケーションまたはサービスが考えられます。たとえば、私が git を学ぶことを選んだ理由はほぼ次のとおりです。 ギットハブ..

グーグルの比較も（ちょっと古いですが、2008年に行われたものです）

http://code.google.com/p/support/wiki/DVCSAnalysis

私がそれらを正しく理解していれば（そして私はそれぞれの専門家からはほど遠いですが）、基本的にそれぞれが異なる哲学を持っています。私は最初にマーキュリアルを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 のクローンに似ているようです。しかし、クローンは、同様の動作をするかもしれませんが、間違いなく同じではありません。かなり大きい chromium リポジトリを使用して、git と hg でこれらを試してみることを検討してください。

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

そして今、HGでクローンを使用しています

$ 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 で新しいブランチを作成するのと同じではありません。はるかに重い重量です。git のブランチに相当するものが hg にあるとしても、それが何なのかはわかりません。

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 つのブランチが作成され、それぞれが master と呼ばれるブランチに基づいています。(Git には、これらを 2 行ではなく 1 行にする何らかの方法があると確信しています)

今、私がやっていることに取り掛かります

git checkout fix-game-save-bug

そして仕事を始めます。物事をコミットするなど。クロムのような大規模なプロジェクトであっても、ブランチ間の切り替えはほぼ瞬時に行われます。実際、HGでそれを行う方法はわかりません。これは私が読んだチュートリアルの一部ではありません。

もう一つ大きな違いがあります。ギットのステージ。

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 には、同じファイル内のどの特定の行をステージにコピーするかを決定するコマンドもあるので、それらのコミットを個別に分割することもできます。なぜそれをしたいのですか？個別のコミットとして、他の人は必要なものだけをプルしたり、問題があった場合は問題のあるコミットだけを元に戻したりできるためです。

versioncontrolblog には、いくつかの異なるバージョン管理システムを比較できる動的な比較表があります。

以下は git、hg、bzr の比較表です。

ブランチ (特に短期ブランチ) の操作に関しては、かなり大きな違いがあります。

で説明されています この記事 (分岐の説明) これは Mercurial と Git を比較したものです。

プロジェクトに Windows ベースの共同作業者はいますか?

もし存在するとしても、Git-for-Windows GUI は扱いにくく、難しく、不親切に見えるからです。

対照的に、Windows 上の Mercurial は簡単​​です。

bitbucket.org の mercurial と github の git の間で注意すべき点の 1 つは、mercurial ではプライベート リポジトリを必要なだけ持つことができますが、github では有料アカウントにアップグレードする必要があるということです。したがって、私は Mercurial を使用する bitbucket を選択する理由です。

昨年のある時期、私は自分用に git と hg の両方を評価し、hg を選択することにしました。当時、私はこれがよりクリーンなソリューションのように見え、より多くのプラットフォームでより適切に機能すると感じました。ただし、それはほとんど投げ上げでした。

最近では、git-svn と Subversion クライアントとして機能する機能のおかげで、git を使い始めました。これに魅了され、今では完全に git に切り替えました。学習曲線は少し高いと思います (特に内部をいじる必要がある場合) が、本当に素晴らしいシステムです。これからジョンが投稿した 2 つの比較記事を読んでみます。

私は現在、SVN から DVCS への移行の過程にあり (調査結果についてブログを書きながら、初めての本格的なブログ活動です...)、少し調査 (= グーグル) をしました。私の知る限り、両方のパッケージでほとんどのことができます。GITにはいくつかの高度な高度な機能があるように思われますが、Windowsとの統合は、TortoisehgとのMercurialの統合が少し優れていると感じています。Git Cheetah もあることは知っていますが (両方試しました)、水銀ソリューションの方がより堅牢に感じられます。

どちらもオープンソース (そうですよね?) であることを考えると、どちらにも重要な機能が欠けているとは思えません。何かが重要であれば、人々はそれを要求し、人々はそれをコード化します。

一般的な実践には、Git と Mercurial で十分だと思います。どちらもそれらを使用する大きなプロジェクト (Git -> Linux カーネル、Mercurial -> Mozilla Foundation プロジェクト、もちろん両方) を持っているので、どちらにも何かが本当に欠けているとは思いません。

そうは言っても、これについて他の人が何と言っているかに興味があるのは、それが私のブログ活動の素晴らしい情報源になるからです ;-)

git、Mercurial、Bazaar には、優れた包括的な比較表とチャートがあります。 DVCS に関する InfoQ のガイド.

これが答えの一部ではないことは承知していますが、その点で、NetBeans や Eclipse などのプラットフォーム用の安定したプラグインの可用性が、どのツールがそのタスクにより適しているか、あるいはどのツールがより適しているかに影響を与えるとも思います。 「あなた」に最適です。つまり、あなたがいない限り、 本当に CLI 方式で実行したいと考えています。

Eclipse (およびそれに基づくすべてのもの) と NetBeans は両方とも、リモート ファイル システム (SSH など) やファイルの外部更新に関して問題が発生することがあります。これが、選択したものはすべて「シームレス」に動作する必要があるもう 1 つの理由です。

私も今、この質問に自分自身で答えようとしています。候補を Git か Mercurial に絞りました。このトピックに関して、宗教的な考えに陥ることなく有益な情報を提供してくださった皆さんに感謝します。

Mercurial と git のさらに別の興味深い比較: Mercurial と Git の比較。主な焦点は内部構造と分岐プロセスへの影響です。

Mercurial と Git のパフォーマンスの比較に興味がある場合は、以下をご覧ください。 この記事. 。結論は次のとおりです。

Git と Mercurial は両方とも良好な数値を示していますが、速度とリポジトリ サイズの間には興味深いトレードオフがあります。Mercurial は追加と変更の両方が高速であり、同時にリポジトリの増大を制御します。Git も高速ですが、そのリポジトリは、再パックするまで変更されたファイルによって非常に急速に大きくなり、再パックが非常に遅くなる場合があります。ただし、圧縮されたリポジトリは Mercurial よりもはるかに小さいです。

マーキュリアルのウェブサイトには、 類似点と相違点の素晴らしい説明 2 つのシステムの違いを説明し、語彙と基礎となる概念の違いを説明します。長年の git ユーザーとして、Mercurial の考え方を理解するのに非常に役立ちました。

SVN から移行する場合は、SVN ユーザーにとって構文がはるかに理解しやすい Mercurial を使用してください。それ以外は、どちらでも間違いはありません。でもチェックしてね GIT チュートリアル そして HGinit いずれかを選択する前に。

このリンクは違いを理解するのに役立ちますhttp://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

VCS システムは複雑でなければならないと考える人もいます。彼らは、現場で用語や概念を発明することを奨励します。彼らはおそらく、このテーマに関する多数の博士号が興味深いものになるだろうと考えるでしょう。その中にはおそらく Git を設計した人も含まれます。

Mercurial は異なる考え方で設計されています。開発者は VCS についてはあまり気にせず、代わりにメインの機能に時間を費やす必要があります。ソフトウェア工学。Mercurial を使用すると、ユーザーは回復不可能な間違いを犯すことなくシステムを使用し、喜んで悪用することができます。

プロフェッショナル ツールには、明確に設計された直感的な CLI が付属している必要があります。Mercurial ユーザーは、奇妙なオプションを使用せずに単純なコマンドを発行するだけで、ほとんどの作業を行うことができます。Git ダブルダッシュでは、クレイジーなオプションが標準です。CLI 担当者であれば、Mercurial には大きな利点があります (正直に言うと、自尊心のあるソフトウェア エンジニアなら誰でもそうあるべきです)。

例として、間違ってコミットを行ったとします。いくつかのファイルを編集するのを忘れています。Mercurial で操作を元に戻すには、次のように入力するだけです。

$ hg rollback

その後、システムが最後のトランザクションを取り消したことを示すメッセージが表示されます。

Git では次のように入力する必要があります。

$ git reset --soft HEAD^

さて、リセットが何であるかについては理解できたとします。ただし、それに加えて、「--soft」リセットと「--hard」リセットが何であるかを知る必要があります (直感的な推測はありますか?)。あ、もちろん最後に「^」文字を忘れないでください。（リッチーの名前ではそれは何ですか...）

Mercurial と kdiff3 や Meld などのサードパーティ ツールとの統合もはるかに優れています。あまり手間をかけずにパッチを生成し、ブランチをマージします。Mercurial には、次のように入力してアクティブ化する単純な http サーバーも含まれています。

hg serve

そして、他の人があなたのリポジトリを閲覧できるようにします。

肝心なのは、Git は Mercurial と同じことを、はるかに複雑な方法で、はるかに劣った CLI を使用して実行するということです。プロジェクトの VCS を科学研究分野に変えたい場合は、Git を使用してください。あまり気にせずに VCS ジョブを完了させ、実際のタスクに集中したい場合は、Mercurial を使用してください。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top