2011-10-18 3 views
10

ご注意ください:私はMercurialまたはGitの方が良いかどうかの議論を再開しようとしていません。私はMercurialユーザーとして理解できないという技術的な質問があります。私は、SOがそのような質問をする正しい場所であるかどうかも分かりませんが、はプログラミング関連のです。Gitはコミットの一環としてブランチ名を保存しないのはなぜですか?

2つのバージョンコントロールシステムGitとMercurialがユーザーの観点からどのように異なっているかについて多くの議論がありました(例えば、とhttp://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/)、主な違いはブランチの処理です。私はこれらの議論の多くを読んだことがありますが、私はこの質問を続けます。

コミットの一部としてブランチ名を保存しないのはなぜですか?

私はそれをしていない正当な理由は本当にありません。つまり、参照(タグ、ブランチなど)がないため、データが単に消えるだけではありません。

私はコミットのブランチをMercurialの大きなプラスとして格納しています。これはデータを失うことをより困難にするためです。

Gitの分岐モデルに賛成で、単にブランチを削除できるという主な点は、Gitが各コミットの一部としてブランチの名前を格納することを妨げません:ブランチのコミットが削除された場合そのブランチへの参照もそうです。また、「安価な分岐」の議論に干渉することもありません。支店の管理にはコストがかかりません。そして、私は、必要な追加ストレージが懸念されるべきではないと思います。コミットあたりわずか数バイトです。

+0

私は混乱しています。今はいつデータを失うのですか? – Useless

+1

私はしませんが、それは可能です:私が理解する限り、分離した頭部はタグまたは枝を指さないとガベージコレクションされます。 –

+1

@danielkullmann:ガベージコレクトされていますが、少なくとも2週間前ではありません:http://stackoverflow.com/questions/5772192/git-how-can-i-reconcile-detached-head-with-master-origin – VonC

答えて

14

のGitとMercurialのための分岐約決定的な源の一つはSOの質問である:Gitの参照(ブランチ、リモート追跡ブランチとタグ)で

Git and Mercurial - Compare and Contrast

はDAG外部に存在コミットします。

(それはローカルおよびリモートブランチのために、枝に関して異なる名前空間を管理することができます)

あなたは(/引っ張るプッシュすることができます)ブックマーク枝とMercurialのと似た概念を持っています。

Gitでは参照がないためデータは消えません。参照されていないコミットを取得するにはまだreflogがあります。

コミットの一部としてブランチ名を保存しないのはなぜですか?
私は本当に

アイデアは、変更のコンテキスト(名前からなぜメートル、すなわちから(コミット)を変更したものを分離することであることを行っていないために十分な理由が表示されません枝の)。
fast-forward mergeブランチができるので、あるブランチからのコミットはいつでも別のブランチの一部になることができます。Jakub Narębskiは特にグローバル名前空間で、(チェンジセットのメタデータに埋め込まれた支店名を持つ)のMercurial「という名前の枝」のデザインを疑問視する理由分散バージョン管理システムのために非常に適していない、ある

開発作業(「When should you branch?」を参照)を隔離するためにブランチを作成しますが、DVCSを使用して、その開発作業(コミットのセット)を任意のブランチ名で公開する必要があります。あなたが定義したローカルコンテキスト(ブランチ名)は、いったん別のGitリポジトリに公開されると有効ではないかもしれません。

+0

+1ありがとう、それは非常に啓発されました! –

+0

私は、人々が「恐れてはいない、消えないだろう、それがreflogにある」と言うときに心配する。 reflogは一時的です。それは消える。それが消えた後、コミットグラフの参照されていない部分にどうやって行きますか? –

+0

@DonHatchは消えますか?デフォルトでは90日後に限ります。あなたが本当に90日後にその情報が必要な場合、私はあなたのレポのバックアップから取得することができると思います。 – VonC

8

Mercurialの基本的な操作モデルは、非常にシンプルな匿名の分岐であり、分岐型の非循環グラフ(DAG)を形成します。そのような分岐名はほとんど重要ではなく、それらをあまり扱っていません。名前付きブランチは、組織的な目的(リリースブランチなど)のためにあります。グローバルな名前空間がより理にかなっているとか、少なくとも不快な点は少ないと主張します。

Gitは、Mercurialよりも複雑で管理された分岐モデルを持っています。ローカルの変更でも、別個の名前付きブランチのように扱われ、そのような過度の名前付きブランチに直面しています。同様の理由から、Gitは早送りマージという概念を持っていますが、最初は別のブランチを作成していないためMercurialには当てはまりません。

これらの両方のコンセプトは複雑さを増すとともに、ブランチ名とコミットの保存などの便利な機能をブロックします。これは、グローバルスペースを持たない名前空間の分岐を格納することができないためで、gitには何もありません。

上記のVonCが参照している名前空間の引数の欠陥は、あなたと私が両方とも 'x'というブランチを作成すると問題があると仮定していることです。名前付きブランチを作成してマージし、後で同じ名前の別のブランチを作成するときに問題がないようにはありません。適切な名前は、著者が誰であろうと、ブランチが何をするのかを記述します。さらに分かりやすいようにする必要がある場合は、ブランチ名とともに著者が格納されます。

コミットと一緒にブランチ名を格納するのは、Mercurialプロジェクトの非常に良い決定だったと思います。コミットメッセージと作者のように、作業のコンテキスト(ブランチ)は重要で有用なメタ情報です。 Gitでは、この情報がなければ、歴史はすぐに辛い行為の混乱を招くことに気付きました。これは、歴史を調べるときにチェンジセットの流れを見るのがはるかに簡単です。の頭か尾。名前空間を持たないというトレードオフの価値があると思います。

私は、Mercurialが名前付きブランチを永続的なメタデータとして扱い、コミットの行についていくつかの追加情報を与えるのに対し、Gitブランチの場合は、バージョン管理されていない開発システムの管理システムDAG。 Mercurialはまた、バージョン1.8のコア機能として「ブックマーク」という名前でこれらを持っていますが、本当にトラッキングツールのほうが多く、ブランチの代わりにラベルのように扱われています。

+0

ありがとう、非常に興味深い! –

関連する問題