ここで同時に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
--の子孫であるため、これは早送りマージです。G
F
- [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_branch
my_branch
これらの手順のいずれかを実行すると、my_branch
との両方other_branch
が を指しG
ます。
commit の変更が( )D
内にない理由my_branch
G
Git は変更ではなく履歴をマージします。これは通常、Git がマージの 2 つの側面 (および、可能であれば、それらの最も若い共通の祖先コミット、別名merge-base ) を取り、それらを結合しようとすることを意味します。Git コミットは変更セット/デルタ/差分ではなくスナップショットであるため、実際のマージでは他のコミットや変更の情報は使用されません。
マージ ベースを使用して、Git はいわゆる 3 方向マージを実行し、共通の祖先を使用して両側の変更をスマートに解決しようとします。それができない場合、マージが中断され、ユーザーが競合を解決する必要があります。
あなたの履歴でおそらく起こっE
たことは、 の変更をコミットまたはF
元に戻した (または上書きした) ことです。D
これはE
、F
.
あなた自身がコメントで述べたように、コミットを切り替えて編集を行うことがよくあります。その結果、多くの変更をフローティングすることになり (Git はチェックアウト時にコミットされていない変更を持ち越します)、変更がどこにあるのか、実際にどこにあるのかを判断するのが非常に難しくなる可能性があります。ブランチを変更する前に変更をコミットするか、 を使用git stash
してそれらをバッファリングすることにより、これを回避してください。