dvcs-「ブランチからクローン」は一般的なワークフローですか?


9

私は最近、dvcsについて同僚と話し合っていました。これは、私たちのオフィスがTFSからの切り替えを検討し始めているためです(私たちはMSショップです)。その過程で、彼はMercurialを使用しているものの、「ブランチ」または「チェックアウト」コマンドを聞いたことがなく、これらの用語が彼にとってなじみのないものであると彼が言ったので、私は非常に混乱しました。彼がそれらについて知らなかった可能性があるのではないかと考え、dvcsブランチがローカルファイルで「適切に」機能する方法を説明した後、彼はかなり混乱しました。

彼は、TFSのしくみと同様に、「ブランチ」を作成したい場合はクローン作成によって行うので、リポジトリの完全なコピーを持っていると説明しました。これは本当に奇妙に思えましたが、私が認めなければならない利点は、ファイルが別々であるため、2つのブランチを同時に見たり作業したりできることです。

このサイトを検索して、多くのオンラインリソースがこの「クローンからブランチへ」の方法論を宣伝するコメントを見る前にこれが尋ねられたかどうかを確認する際に、ポスターを落胆させました。これは実際にdvcsコミュニティで一般的ですか?そして、この道を行くことの長所と短所は何ですか?一度に複数のブランチを表示する必要がなく、切り替えが高速で、すべてのクローンがディスクをいっぱいにする必要がないため、それを行うことは決してありません。


7
これは、CVSおよびSVNワークフローからの引き継ぎです。「ハンマーですべてが釘のように見える」ことを

1
@JarrodRoberson-機能するように制限する場合のみgit。でhg、これは通常、最初のワークフローは教えられ、それはまだ非常に便利なものです。
マークブース

回答:


3

両方のブランチを見ることができるという一般的な利点/欠点とは別に、それを行うことにはMercurial固有の利点があると思います。

クローンを作成してブランチを作成した場合、変更を保持したくない場合は後でクローンを削除できます。それらをマージすることを決定した場合、この方法で変更を分離することを決定したという事実は、他の誰にも見えません。

対照的に、を使用hg branchして新しい名前付きブランチを作成する場合、ブランチ名はコミット時に履歴に記録され、他のすべてのユーザーに表示され、後で混乱する可能性を避けるためにかなり一意である必要があります。ブランチが実験的な機能を開発するためのものである場合、または小さな変更であることが判明した場合、これは適切ではない可能性があります。

名前付きブランチを使用してソフトウェアのリリースバージョンを維持し、それらを短期的な機能やバグ修正の開発にも使用する場合、これらの2種類のブランチを別々に保つ方法がない(命名規則以外に)ため、混乱しやすくなります。

http://mercurial.selenic.com/wiki/StandardBranchingはこれをより詳細に説明しています。Mercurial 1.8以降、ブックマーク(hg bookmark)を作成することが可能であることにも言及する価値があります。これは、存続期間の短いブランチの使い捨ての名前です。ブックマークは、プッシュ、プル、移動、削除できます。


2
Mercurialはあまり使用していませんが、Gitにはこの問題はありません。私はローカルで一日中ブランチし、開発ブランチにマージしてプッシュすることができ、誰も私のブランチ名を見る必要はありません。
Andrew T Finnell、2012年

3
@AndrewFinnell:それは本当に問題に当てはまりませんでしたが、私はそれが必ずしも問題ではないことを言いたかったです-Mercurialの作業における名前付きブランチの方法にはいくつかの利点もあります。たとえば、コミットが最初に行われたブランチを確認できます。これは知っておくと役立ちます。
benj

1
@AndrewFinnell-名前付きブランチは、慣れ親しんでいたため、私が本当に見逃しているものです。また、の名前のないブランチの自動作成と比較すると、ブランチを作成するたびに明示的に覚えておかなければならないのは面倒です。githggit branchhg
マークブース

バンドルされたストリップ拡張機能を使用して、hgのブランチを削除できます。Mercurialは、「フェーズ」を使用することで、
今日の

2

DVCSでコミットを行うたびに、技術的には履歴にブランチを作成し、祝福されたリポジトリにプッシュして戻すたびに、統合します。興味深い部分がここにあります。

  • コミット中に誰も変更を加えなかった場合、DAG(有向非循環グラフ)のブランチのようには見えません
  • コミット中に他の誰かが変更を加えた場合、DAG内のブランチのように見え、名前が付けられていない

Bitbucket / githubの「fork」ボタンを覚えていますか?forkはブランチの同義語と見なすことができ、「fork」ボタンが行うことは、アカウントへのそのリポジトリのクローンにすぎません。

「ブランチへのクローン作成」の唯一の利点は、歴史の2つのポイントで同時に作業できることです。皮肉なことに同僚にとっては、異なるブランチで同時に作業するための一般的なワークフローです(前後に移動する必要はありません) )。

分岐する方法を学ぶように同僚に伝えてください、これは非常に簡単です、ここにチュートリアルがあります:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

「ブランチへのクローン作成」は、異なるブランチで同時に作業している場合、または履歴に永続的なブランチを作成せずに実験試し、それを既存のブランチに統合できるようにする場合に意味があります。 。

私は個人的にはこの習慣を嫌い、必要に応じてブランチを作成してそれらを閉じることを好みます。ここでは、次のようにします。

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

これでDVCSの分岐に関する疑問が解消されるといいのですが、ここでは分岐が怖くなくなりました。


0

私は個人的にディスクがいっぱいになるコードについて心配することはありません...まず、それは単なるコードであり、次に、すべてのクローンを永久に保持するつもりはありません。

この方法論は、特にHgの多くのオンラインリソースで宣伝されています。本番環境での使用は見たことがありません。CI環境では、追加のリポジトリクローンよりも機能の短いブランチを使用する方がはるかに一般的です。私がこれを行うことの利点はわかりません。もしそれがあなたの歴史をより混乱させる、あるいは少なくすることになるとしたら、それはあなたに何も得ません。新しいコードを古いコードと並べて確認したい場合は、diff / mergeツールを使用して、隣り合う2つのコミットを確認できます。さらに、変更が強調表示されるという利点もあります。


私はこれを、プロダクションで広範囲に使用していhgます。複数のhgリポジトリ間でプッシュおよびプルできることは、非常に強力なコラボレーションツールです。このようなワークフローでは、ベアリポジトリ以外からプルすることができるだけでgit、オプションを大幅に制限できます。
マークブース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.