これが私のgit履歴であるとします
Z / A-C-D \/ B
私のHEADは現在Z
にあります。B
とC
をチェリーピックします。私の理解が正しければ、すべきです。この:
git cherry-pick B
git cherry-pick C -m 1
git commit --allow-empty
私の場合、C
は何もしません(後で空のコミットが必要になるので、他の理由でコミットが必要になりました)が、うまくいきましたが、-m
の後のパラメーターはどうなるのでしょうか。ここに私が読んだものがあります ドキュメント :
-m親番号
-メインラインの親番号
通常、マージのどちら側をメインラインと見なすべきかわからないため、マージをチェリーピックすることはできません。このオプションは、メインラインの親番号(1から始まる)を指定し、チェリーピックが指定された親に関連する変更を再生できるようにします。
私の場合、C
には2つの親がありますが、どちらが1と2であるかを知るにはどうすればよいですか。
この答え に基づく私の理解は、親1がマージされるブランチであり、親2がマージされるブランチであるということです。したがって、あなたの場合、親1はA
であり、親2はB
です。チェリーピックは実際に2つのコミット間の差分を適用しているので、-m 1
を使用してB
からの変更のみを適用します(A
とC
の差分にはB
)から変更されます。あなたの場合、A
とC
の間にコミットがないため、おそらく問題ではありません。
はい、-m 1
が望みです。A
とC
の間に余分なコミットがあったとしても、それは事実です。
新しい履歴を元の履歴のように見せたい場合、別の方法があります:
git cherry-pick B
git checkout Z
git merge --no-ff --no-commit B
git commit --author="Some Dev <[email protected]>" --date="<commit C author date>"
(必要に応じて、チェリーピッキングの前にB
の新しいブランチを作成できます。)
これにより著者情報が保持され、次のような履歴が表示されます。
B'
/ \
Z -- C'
/
A -- C -- D
\ /
B
Scott Weldon's answer を支持しましたが、これは正しいですが、ただASCII親の番号付けを含むアート。この:
B
/ \
...--A D--...
\ /
C
ノードD
がマージコミットであることはわかりますが、B
またはC
がD
の最初の親であるかどうかはわかりません。 2つのうちの1つは必然的に最初の親であり、もう1つは2番目の親です。そのため、知る必要がある場合は、図面にラベルを付ける必要があります。そのような試みの1つを次に示します。
B
/ \²
...--A D--...
\ /¹
C
なんらかの理由で、1 グラフを「逆さまに」描画しました。コミットC
は実際にはD
の最初の親であり、コミットB
は2番目の親です。
低レベル(「配管」)コマンドを使用して、任意のマージを作成することができます。特に、git commit-tree
は、与えたい順番で、与えたい数の-p
引数を取り、与えられたコミットを親として新しいコミットを行います。 -p
を1つ与えると、1つの親と通常のコミットを行います。 -p
引数を指定せずに、ルートコミットを行います。 155個の-p
引数を指定し(もちろん、すべて有効なコミットIDに解決する必要があります)、1つの巨大なタコマージコミットを作成します。
ただし、git merge
コマンドは常に、最初の親が現在のHEAD
である新しいブランチを作成します(ブランチの場合は現在のブランチです)。標準の2つの親のマージの場合、2番目の親は.git/MERGE_HEAD
から取得され、git merge
は別のコミットIDを書き込みます。マージが競合する場合、または最終的なマージコミットが--no-commit
で遅延する場合、このMERGE_HEAD
ファイルは実際にはonlyコミットIDが利用できる場所。
(git merge
が-s octopus
ストラテジーを使用してタコマージを行う場合(このストラテジーはそのようなマージに対して強制されます)および複数の追加の親は、マージの競合がある場合は中止され、まったくトレースを残しません。 --no-commit
をタコマージと組み合わせようとしませんでしたが、論理的には、Gitで許可されている場合、2番目からN番目の親をMERGE_HEAD
に残します。
1頑固。