2013-05-10 9 views
7

git diff other_branchに違いがあり、git merge other_branchが何もしていないと困ります。その "欠落した"コードをmy_branchに組み込む正しい方法は何ですか?`git diff`が変更を示すときにブランチをマージする正しい方法は何ですか?` git merge`は何もしません。

このSO answerは、私と同様の状況を示しています。もちろん

o---A---B---C-------G my_branch 
    \  \ /
     --*D*---E---F other_branch 

驚くべきことにDに変更し、私は

git checkout my_branch 
git merge other_branch 

を行うときに、自動的にFに持参するmy_branchにマージされていませんがG

私がすることができますmanually create a patchmy_branchに適用します。

git diff other_branch my_branch > patchfile 
git checkout my_branch 
git patch -p1 < patchfile 

しかし、私はgitログを掘り下げずに、このようにしたいと思います。パッチアプローチでは、Dの変更を記録し、最新のパッチはお互いに独立して起こります(コードの乱れ)。私はgit logを簡素化し、他人がgit merge my_branchを実行したときに意図せぬことが起こっていないことを確認したい(静かで狡猾に)。

+2

あなたは 'other_branch'に' my_branch'をマージしようとしましたか?おそらくその違いを解決する可能性があります。いくつかのコミットが 'my_branch'では復帰したが' other_branch'では復帰しなかった場合、あなたはこのような状況になります。 – iltempo

+0

@iltempo、私はあなたのコメントの後にマージを試みました、そして確かにそれは実際に違いを解決し、git diffは現在きれいです。私はそれが適切にマージされたことを信じなければならない。 – hobs

+0

@iltempo、私は意図的に 'my_branch'の変更を元に戻したわけではありませんが、チェックアウトと編集とチェックの間を振動した後に昇華(テキストエディタ)で保存を押すとコミットが散在します。私はすべてのことにもっと注意する必要があります。 – hobs

答えて

2

ここには2つの問題が同時にあるようです。

と仮定すると、あなたが説明したような歴史:

   my_branch 
        v 
----A---B---C-------G 
    \  \ /
     --*D*---E---F 
       ^
      other_branch 

diffが空でない理由:

このような状況は、あなたが言及したコマンドによって生成される、すなわちが上であることmy_branchを入力し、次にgit merge other_branchを入力します。このアクションにより、マージコミットGが生成され、現在のブランチ(my_branch)が前方に移動されましたが、other_branchの位置に残りました。これはマージが常に機能する方法です!もちろん、my_branchG)とother_branchF)の間には違いがあります。結局、異なるコミットを指しています。

あなたが同じになるように二つの枝をしたい場合は、以下の方法でother_branchを上に移動することができます

  1. git checkout other_branch; git merge my_branchを - GF
  2. の子孫であるので、これは 早送りマージです
  3. [オンではありませんother_branch!]git branch -D other_branch; git branch other_branch my_branchからmy_branch現在後

を指しているother_branchが正確に指すように、この意志動き - これはmy_branch現在

  • git checkout other_branch; git reset --hard my_branchで同じ場所に再作成しother_branchを削除しますこれらのステップのをやって、my_branchother_branch両方がGを指します。

    コミットDの変化がmy_branchG)に含まれていないのはなぜ

    Gitは歴史ではなく、変更をマージします。これは通常、Gitはマージの両側がかかります(と、利用可能な場合、その最年少共通の祖先がコミット、merge-base別名)とそれらを結合しようとしていることを意味します。 Gitのためのコミットは、スナップショットなく、チェンジ/デルタ/差分、この他のコミットまたは変更のない情報は、実際のマージで使用されています。マージ・ベースを使用して

    、Gitは試してみて、スマートに、両側の変更を解決するための共通の祖先を使用して、いわゆる3ウェイ・マージを行います。できない場合は、マージを中断し、ユーザーに競合を解決させる必要があります。おそらくあなたの歴史の中でがEをコミットまたはFのどちらかが、元に戻す(またはオーバーライド)ということで何が起こっ

    Dの変化 - これはFEまたは実際の(手動)変更を生じマージ中に起きている可能性があります。

    あなた自身がコメントで述べたように、あなたは多くの場合、コミット間の切り替えや編集を行います。これにより、変更がたくさん浮かびます(Gitはチェックアウト中にコミットされていない変更を持ちます)。これにより、変更がどこに行き、実際にどこに行かなければならないのかが分かりにくくなる可能性があります。ブランチを変更する前に変更をコミットするか、git stashを使用してブランチを変更してください。

  • 関連する問題