ここで同時に2つの問題を抱えているようです。
あなたが説明したような歴史を仮定します:
my_branch
v
----A---B---C-------G
\ \ /
--*D*---E---F
^
other_branch
差分が空でない理由:
この状況は、あなたが言及したコマンド、つまりオンになってmy_branchからgit merge other_branch実行することによって生成されます。このアクションはマージ コミットGを生成し、現在のブランチ ( my_branch) を前方に移動しましたが、元の場所に残しother_branchました。これが、マージが常に機能する方法です。当然、この時点でmy_branch( G) とother_branch( )の間にはまだ違いがあります。結局のところ、これらは異なるコミットを指しています。F
2 つの分岐を同一にしたい場合other_branchは、次の方法で上に移動できます。
git checkout other_branch; git merge my_branch--の子孫であるため、これは早送りマージです。GF
- [while not on
other_branch!] git branch -D other_branch; git branch other_branch my_branch -- これにより削除され、現在あるother_branch場所と同じ場所に再作成されますmy_branch
git checkout other_branch; git reset --hard my_branch-- これは、現在指している正確な場所に移動します other_branchmy_branch
これらの手順のいずれかを実行すると、my_branchとの両方other_branchが を指しGます。
commit の変更が( )D内にない理由my_branchG
Git は変更ではなく履歴をマージします。これは通常、Git がマージの 2 つの側面 (および、可能であれば、それらの最も若い共通の祖先コミット、別名merge-base ) を取り、それらを結合しようとすることを意味します。Git コミットは変更セット/デルタ/差分ではなくスナップショットであるため、実際のマージでは他のコミットや変更の情報は使用されません。
マージ ベースを使用して、Git はいわゆる 3 方向マージを実行し、共通の祖先を使用して両側の変更をスマートに解決しようとします。それができない場合、マージが中断され、ユーザーが競合を解決する必要があります。
あなたの履歴でおそらく起こっEたことは、 の変更をコミットまたはF元に戻した (または上書きした) ことです。DこれはE、F.
あなた自身がコメントで述べたように、コミットを切り替えて編集を行うことがよくあります。その結果、多くの変更をフローティングすることになり (Git はチェックアウト時にコミットされていない変更を持ち越します)、変更がどこにあるのか、実際にどこにあるのかを判断するのが非常に難しくなる可能性があります。ブランチを変更する前に変更をコミットするか、 を使用git stashしてそれらをバッファリングすることにより、これを回避してください。