8

gitのマージ競合解決は、他の SCM (CVS、Subversion など) やスタンドアロンのマージ ツールよりも本質的に効率的ですか? もしそうなら、なぜですか？

明確化:ここで私はアルゴリズム自体にもっと興味があります - それは単純な diff3 メソッドと何か違うのですか?
一部のツールはその点でよりスマートであると主張しています (例: Guiffy)。git マージ ツールとしてプラグインする価値はありますか? ファイル内またはファイル間で移動されたテキストの断片を理解する上で、git はよりスマートですか? (うるさい衝突を報告するというより.. ライナスの話から漠然とした印象がありました)。

背景: を使用して大規模なマージを行ったgit-svnところ、プレーン (追跡なしの最初のマージ) よりも半分の競合が発生しましたsvn merge..その理由を理解したいと思います。

これらは似たような Q/A ですが、プロセスの全体像と、マージがより自然にどのように適合するかについてのものです。そのために、git（分岐のみではなく）「マージ用に最適化」されていることは、実際には次のことを意味しますか？

  1. 手動の競合が少ない -- より優れた自動解決アルゴリズム (例: 名前の変更が適切に処理される)
  2. より安全な操作 -- 自動解決により、より多くの/実際の競合のみが残り、誤ったアラートが少なくなります
  3. より高速な操作 -- たとえば、リーン & ミーン オブジェクト モデルによるもの
  4. より優れたツール -- DAG ベースのマージ トラッキング、マージツール、ヒストリー クエリ/ビジュアライゼーション、スタッシュ、リベースなど、エクスペリエンスの負担を軽減します。
  5. 他の何か
  6. 上記の組み合わせ

? 今、私は主に1と2に興味があります。

4

2 に答える 2

1

私はこの答えが間違っていることを証明したいと思っていますが... perforceから来ています... gitのこの領域は少し開発が進んでいません。

  1. git の自動マージは存在しません。最新バージョンには、変更またはその変更を使用してマージを実行するための基本的なサポートがありますが、それだけです。基本的に、ファイルの一部を編集し、他の誰かがファイルの同じ部分を編集した場合...マージの解決は自分で行います。diff3 形式が利用可能です (3 方向マージ) が、統一された diff 形式が標準であると思います。私は実際にマージ ツールとして araxis を使用し、"git mergetool" の実行時に 3 方向マージを使用するようにセットアップしています。パーフォースから来ていますが... gitはこの分野で遅れをとっているように感じます。

  2. なし

更新 RE: コメント

git が競合であると考えていることと、p4 が競合であると考えていることを正確に深く掘り下げていませんが、両方で経験したことを次に示します。

  • Git は、マージを行うときに空白を無視しません... ただし、これについては将来 git で話し合う予定です。p4 はこれを実行できるようになりました。チームの全員がスペースまたはタブの使用に同意しない限り、空白を無視しないことは大きな苦痛であり、ファイルのインデントを変更したい場合...（たとえば、他のノードの周りにxmlノードを追加する）、これはすぐに古くなります.
  • ファイル内でマージの競合に遭遇したときのように感じます... git が統一された差分形式を使用して競合していると言う部分は大きくなります。変更されたのが 1 行の一部のみである場合、より大きな部分が変更済みとしてマークされるため、統合された diff 出力の 2 つの領域間の変更を視覚的に追跡する必要があります。ただし、me​​rgetool を使用してこれを回避できます。p4 は、同じ行を編集している場合でも競合を自動解決できます。
  • 存続期間の長いトピック ブランチをマージする場合は、非常に便利です。rerere をオンにしないと (デフォルトではオフになっています)、git は 1 週間前に競合していたファイルを既にマージしたことを忘れ、もう一度マージするように求めます。p4はこれを簡単に行います

ここでの私の答えは少し主観的です...しかし、perforceで行ったマージが恋しいです。

于 2010-07-19T22:17:07.630 に答える
1

さらに、この最近のスレッド (2012)では、Git での「自動解決」の概念について詳しく説明しています。

「自動解決」の私の定義:
「マージ中に、作業ツリー ファイルはマージの結果を反映するように更新されます...両側が同じファイルの異なる領域に変更を加えた場合、git は両側を自動的に選択し、 git がマージ コミットを行った後、それらのマージ結果が正しいかどうかを確認するのはあなた次第です。」

IOW、「自動解決」とは、具体的には、両方の側 (私たちと彼らの側) がfile(a)の共通の祖先バージョン以降に変更を加えたことを意味しfile(a)、git はマージ競合を発生させずに両側を選択しました。
(私が「自動解決」という用語を思いついた理由は、git-merge出力で「自動マージ」という用語がfile(a)、共通の祖先から一方の側 (それらの側) のみが変更され、git が単に「高速」であることを示すこともできるためです。 file(a)common-ancestor の上に彼らのものを転送しfile(a)ます。)

Junio C Hamanoは、重要な点に答えて次のように述べています。

  • git は愚かであり、安全側で間違いを犯し、リモートで複雑なものをパントすることを知っています。
  • 同じファイルで発生するテキストの非競合は、異なるファイル間で意味上の競合が発生するリスクが同じであることを知っているため、「同じファイルに触れたが競合しなかった」という特別なものを選び出すことは無意味ですが、どちらの場合でも、このような競合は小さいので、最初にマージ (および他のマージ) を完了してから全体的な結果を確認する方が、時間をより効率的に使用できます。

5 年半後の更新、2018 年 5 月 (Git 2.18、2018 年第 2 四半期)

" git mergetools" は ギフィー と 話す こと を 学び ました .

Bill Ritcher (``)によるcommit 6ceb658 (2018 年 4 月 5 日)を参照してください。( 2018 年 4 月 25 日のcommit da36be5でJunio C Hamanoによってマージされました)
gitster

mergetools: のサポートを追加guiffy

とを追加guiffyします。difftoolmergetool

guiffyWindows、Linux、MacOS で利用可能

于 2012-10-02T07:21:47.930 に答える