14

git checkout branch12 つのブランチをマージするために実行するgit merge branch2と、branch2 が単に branch1 を上書きするように見えます。これは起こっているべきですか？

編集：

合併前

  • branch1 = readme.txt (Hello World!)
  • branch2 = readme.txt (こんにちは 2!)

合流後

  • branch1 = readme.txt (こんにちは 2!)

tbh、マージが技術的に何をすべきかはわかりません。

4

2 に答える 2

23

あるブランチを別のブランチにマージする場合、 git mergeはマージ元のブランチのすべてのコミットをマージ先のブランチに適用します。これは、両方のブランチをまとめた最新の状態を含む新しいヘッドを形成していると考えることができます。ブランチ内のファイルを変更し、それをその親にマージして戻した場合、変更はそのブランチの現在の状態の上に適用されます。両方のファイルが同じ場所で変更された場合、マージはこれを解決できない可能性があり、介入する必要があります。通常は、両方のブランチから最新の作業が行われます。

あなたの例では、 で行った変更がbranch2にマージされていbranch1ます。これにより、テキストが に変更されているよう"Hello 2!"です。

git-mergeマンページには、これについて次のように書かれています。

次の履歴が存在し、現在のブランチが「マスター」であると仮定します。

          A---B---C topic
         /
    D---E---F---G master

次に、「git merge topic」は、マスター (つまり E) から分岐してから現在のコミット (C) がマスターの上にあるまで、トピック ブランチで行われた変更を再生し、その結果を新しいコミットに名前とともに記録します。 2 つの親コミットと、変更を説明するユーザーからのログ メッセージ。

          A---B---C topic
         /         \
    D---E---F---G---H master

つまり、これはmergeの正しい操作です。

于 2012-12-23T13:21:17.420 に答える
4

readme.txtと で分岐した場合、ブランチをマージするbranch1と、ファイルが競合branch2状態になります。競合は、競合マーカーで区切られたファイルに存在する分岐コンテンツの両方のバリアントによって表されます。

<<<<<<< HEAD:hello.txt
Hello world!
=======
Hello 2!
>>>>>>> 01234567890abcdef:hello.txt

競合のあるマージは自動的にコミットされません。代わりに、競合を手動で解決し、変更をコミットする方法を示すメッセージが表示されます。

CONFLICT (content): Merge conflict in <file>
Automatic merge failed; fix conflicts and then commit the result.

Nevik Rehnelが指摘したように、ファイルがブランチで分岐せず、共通の共有コンテンツ ( Hello world!) から新しいコンテンツ ( Hello 2!) に変更されただけの場合、競合は発生せず、マージ操作は単に変更を適用します。 . つまり、マージはファイルの内容のマージを保証するものではなく、共通ベースと比較した変更のマージを保証します。

于 2012-12-23T17:24:04.283 に答える