7

Git や Hg を含む一般的な DVCS について 1 つ質問があります。

Git と Hg の両方で、マージ トラッキングは「ファイル/ディレクトリ」レベルではなく「コミット」レベルで行われます。

「副作用」の 1 つは、「部分マージ」を簡単に実行できないことです。

  • ブランチ「feature_branch_x」で 30 個のファイルを変更しました
  • (たとえば) /kernel/gui の下にあるファイルのみをマージしたい

「項目ベースのマージ トラッキング」(Perforce、ClearCase、Plastic SCM <= 3.0) を使用すると、マージするファイルをいくつか選択してチェックインし、後でマージを繰り返すと、保留中のファイルが表示されます。

Hg、Git: マージすると (マージせずにファイルを除外する方法があります)、「追跡」が設定され、マージを繰り返すと、マージする候補が残りません。

私の質問は、それについてどう思いますか??

「部分マージ」が必須と感じるケースはありますか？それなしで生きられますか？(コミット/cset レベルの追跡を使用したマージははるかに高速です)。

免責事項: 私はPlastic SCMで働いており、4.0 で「cset」レベルのトラッキングに移行しましたが、「アイテム レベルのマージ トラッキング」を維持するか、両方を許可することをお勧めします。

4

5 に答える 5

4

ブランチの部分的なマージを行いたいというのは、そもそも 1 つのブランチに多くのものを入れすぎたというサインだと私は感じています。このような状況に対処する正しい方法は、ブランチを 2 つのブランチに分割して元のエラーを修正することです。部分的なマージを追跡してエラーを悪化させるのではありません。ブランチの分割を容易にする SCM 機能を希望します。

于 2011-09-06T18:10:46.547 に答える
3

この Mercurial と Git のツリー全体のマージは、ツリー全体の状態のみを追跡するという両者の哲学から来ています。両方の SCM がマージの親と結果のツリーを追跡するため、Mercurial も Git も部分的なマージがあったことをメタデータに保存できません。この種のビューの利点は、中途半端なマージをコミットすることによってレポが不安定な状態になる可能性がはるかに低いことです。

ファイルがあるサブディレクトリから別のサブディレクトリに移動し、このパスがソース ファイルにコード化されている状況を考えてみてください。サブディレクトリ内のファイルのみをマージすると、ファイルはマージ中に正しく移動されますが、ソース ファイル内の参照は依然として古いディレクトリを指しています。この部分的なマージをコミットすると、VCS は無効な状態になります。他の人がそのような進行中の状態をチェックアウトするのを防ぐために、最終的なマージコミットを完了したものとしてマークする必要があります (Plastic SCM にそのようなセマンティックがあるかどうかはわかりません)。

もちろん、長い間流用されたブランチをマージするのは厄介です。DVCS の世界では、このモンスター マージを軽減して、早期に継続的に迂回するブランチをマージしようとします (1 つは機能ブランチで、安定ブランチは安定ブランチから機能ブランチに頻繁にマージすることをお勧めします)。また、git には、マージ競合の解決策 ( rerereと呼ばれる) を追跡する機能があり、同じマージを何度か行おうとするとき (最終的な終了前にマージを「練習」するときなど) のマージの苦痛を軽減するのに役立ちます。

于 2011-09-06T18:03:42.020 に答える
2

Mパブロ、アイテム レベルのマージをサポートする実際のケースを次に示します。メインブランチを顧客ブランチにしましょうC。ブランチCはしばらく前、おそらく数週間または数か月前にフォークされ、Mその間に大幅に進化しました。ここで、顧客のためにホット フィックスを実行する必要があるため、 のコードを変更しますC。また、 に変更を導入する必要がありますM。

私たちのワークフローは、 で完全かつ適切な修正を行い、製品の新しい汎用リリースをMテストして提供することです。次に、問題の影響を受ける顧客にカスタム ビルドを提供できるように、修正の関連部分Mをにマージする必要があります。したがって、いくつかの変更を からに転送する必要があります。このような操作には、次の側面があります。CMC

  • 一部のファイルは「そのまま」マージされます。
  • 一部のファイルは手動でマージされますが、マージが行われたことを知ることは非常に重要です。
  • からマージされたファイルMは、 の最新の変更セット レコーダからのものである必要はありませんM。複数の変更セットにまたがる場合があります。

そのため、リポジトリの履歴を検査するときにそのような操作を追跡できるように、ファイル間の「データ (コード) フロー」をファイルごとに記録する必要があります。結果の「マージ変更セット」は、1:1 の自動マージと手動で調整されたマージで構成されます。

更新:速度と使いやすさのトレードオフ: 私が理解しているように、あなたの製品は本当に優れたマージなどの機能に賭けています。そして、ほとんどのユーザーは超高速を気にしないに違いありませんが、本当に優れたマージは気にします。

約 10 年前は、1000 個のファイルを ClearCase に追加するのに 10 分かかりました。それらを Subversion に追加するのに 1 分かかりました。そのため、ClearCase ではなく Subversion を選択しました。ただし、ClearCase に 2 分かかった場合は、おそらく、当時よりも優れた機能を備えた ClearCase を選択します。

実世界の商用ソフトウェア開発シナリオをサポートする機能がうまく動作するようになれば、現在の VCS (Subversion) よりも 50% 速くなろうと遅くなろうと気にしません。しかし一方で、他の VCS ツールと比較して貧弱な機能やユーザビリティの阻害要因となるものを提供すると、ユーザーは切り替えません。

変更セット レベルとアイテム レベルのマージの結論としては、自由に固執することです。これは、少なくとも私の観点からは、アイテム レベルのマージです。

于 2011-09-07T16:03:10.880 に答える
1

今すぐいくつかのファイルをマージし、後でいくつかのファイルをマージします。

コミットは、それぞれ 1 つのファイルのみを変更するサブコミットで構成されていると見なし、ファイルベースの操作をサポートします。ブランチ/コミット時に、将来何をマージしたいかを人々が知らないことは明らかであり、これはそれを解決します。git は、コンテンツおよびファイル トラッカーである可能性があります。

于 2012-06-09T01:03:02.033 に答える