Mercurialでの分岐の利点を理解するのに役立ちます

Question

私は分岐がどのように有益であるか理解するのに苦労しました。私は2つの頭、または2つの支店とレポにプッシュすることはできません...なぜ、私はそれらを必要とする/それらを使用するだろうか？

Answer 1

まず、2つのヘッドでもプッシュすることができますが、おそらくそれをしたくないので、デフォルトの動作ではできません。しかし、プッシュを強制的に通過させることができます。

ここで、分岐については、Subversionのような非分散バージョン管理システムで簡単なシナリオを考えてみましょう。

あなたと同じプロジェクトで働いている同僚がいるとします。 Subversionリポジトリの最新のチェンジセットはリビジョン100です。両方ともローカルに更新するので、両方のユーザが同じファイルを持つようになります。

今、あなたの同僚はすでに変更の作業を数時間続けています。これにより、中央のリポジトリはリビジョン101まで持ち上がります。あなたはまだリビジョン100のままですが、変更はまだ取り組んでいます。

いくつかの点では、あなたは完了してコミットしたいと思いますが、Subversionはあなたに任せません。最初に更新する必要があるため、更新プロセスを開始する必要があります。

更新プロセスは変更を取り込み、100ではなくリビジョン101で開始したとします。変更があなたの同僚であったものと矛盾していない場合、すべては大変ですが、変更した場合は矛盾しているのはです。問題があります。

変更内容を変更内容と併合する必要があり、状況が変わることがあります。たとえば、1つのファイルOK、2番目のファイルOK、または3番目のファイルをマージすると、詳細のいくつかが間違っていることが突然発見された場合は、 2番目のファイルを別の方法でマージします。

更新する前に変更をバックアップしていない限り、遅かれ早かれあなたが問題を抱えていることを忘れてしまいます。

ここで、上記のシナリオは実際には非常に一般的です。まあ、おそらく合併の部分ではなく、同じエリアやファイルで同時に何人が作業しているかによって異なりますが、「コミットする前に更新する必要があります」という部分はSubversionではかなり共通しています。

それでは、Mercurialはどうしますか？

さて、Mercurialはローカルでコミットしますが、リモートリポジトリとは全く話しませんので、コミットを止めることはありません。

だから、今度はMercurialだけで上記のシナリオをもう一度試してみましょう。

リモートリポジトリ内tipmostチェンジはリビジョン100です。あなたの両方が、このダウンクローン化されている、とあなたは両方の変更に作業を開始している、改正から100

あなたの同僚は、彼の変更を完了し、コミットローカルに。彼はチェンジセットを中央のリポジトリにプッシュし、そこにヒント101をリビジョン101まで持ってきます。

これで変更を完了し、ローカルでコミットしてからプッシュしますが、エラーメッセージが表示されますすでに発見されており、尋ねています。

これはどう違うのですか？

が本当に苦労してを誤って紛失したり破壊したりしない限り、変更は現在コミットされていません。ここで

は3つの劇中のリポジトリとそれらの現在の状態です：

Colleague  ---98---99---100---A 

Central   ---98---99---100---A 

You    ---98---99---100---B 

あなたがプッシュしたし、これを行う（またはプッシュを通じ強制）させた場合は、中央リポジトリは、次のようになります。

Central   ---98---99---100---A 
           \ 
           +--B 

2頭。あなたの同僚が今引っ張ってきた場合、どちらから作業を続けるべきですか？この質問は、Mercurialがデフォルトでこれを引き起こさないようにする理由です。

その代わりに、あなたは上記の状態を自分のリポジトリに取得します。

つまり、独自のリポジトリに影響を与え、そこに複数のヘッドを作成することができますが、は他の誰にもその問題を課していません。

あなたは、あなたのチェンジセットが安全で、コミットされていることを除いてSubversionで実行したのと同じタイプの操作をマージし、あなたが誤って破損したり破棄したりすることはありません。中途半端なマージが始まろうとすれば、何も失われず、害もありません。

You    ---98---99---100---A----M 
           \  /
           +--B--+ 

このプッシュしても安全である、と同僚は、今引っ張るならば、彼は彼がMのチェンジセットから継続していることを知っている、1：マージした後

は、ローカルリポジトリは、このようになります彼とあなたの変更を統合しました。

上記の説明は、Mercurials分散型の性質のために起こります。

ブランチに名前を付けて、より永続的にすることもできます。たとえば、ブランチの名前を "stable"とし、そのブランチ上のチェンジセットが完全にテストされ、顧客へのリリースや本番環境へのリリースが安全であることを伝えることができます。その後、テストが完了したときにのみ、そのブランチに変更をマージします。

しかし、性質は上記と同じです。複数の人がMercurialのプロジェクトで作業する場合は、はになります。これは良いことです。

Answer 2

repoの複数のクローンが作成され、それらのクローンでコミットが行われるたびに、hg branchコマンドを使用して名前を付けたかどうかにかかわらず、ブランチが作成されます。私の哲学は、彼らにも名前を与えるかもしれないということです。物事の混乱を少なくします。

水銀枝の良い説明：http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/