だから私は以前に数え切れないほどのチェリーピックをしました、そして私は今これで人生で失敗しなければならないようです、私はあるブランチから別のブランチにチェリーピックしようとしています。 -mが与えられていませんか？
$ git cherry-pick a8c5ad438f6173dc34f6ec45bddcef2ab23285e0
error: Commit a8c5ad438f6173dc34f6ec45bddcef2ab23285e0 is a merge but no -m option was given.
fatal: cherry-pick failed
それは間違っているように見えます.......それは次のようになります：
$ git cherry-pick a8c5ad438f6173dc34f6ec45bddcef2ab23285e0
いつから-m関数を提供する必要がありますか？
コミットがマージコミット、つまり複数の親を持つコミット-mである場合は、指定する必要があります。
通常、何を次のgit cherry-pick REVように説明できますか。
revとその親の間で変更を加えます。
これらの変更を現在のHEADに適用し、revのコミットメッセージで結果をコミットします。
マージコミットは、2つの開発ラインに参加します。たとえば、1つの行はウィジェットを実装し、もう1つの行は混乱を取り除きます。マージにより、ウィジェットを含むコードが提供され、混乱がなくなります。
ここで、チェリーピックプロセスのステップ1について考えてみましょう。gitは、クラッターを削除するのか、ウィジェットを実装するのかを推測できません。また、両方を実行する方法に関する情報は単一のマージコミット内に含まれておらず、結果のマージされたツリーのコンテンツのみが含まれているため、両方を実行することもできません。
この-mオプションを使用すると、gitに続行方法を指示できます。たとえば、クラッターの削除が行われmaster、マージコミットがを使用して作成された場合、マージされgit merge WIDGETたgit cherry-pick -m 1 merged-commitツリーと親1（クラッターを削除するコミットの最後）の差分がウィジェットの追加とまったく同じになるため、新しいウィジェットを選択します。一方、親2（ウィジェットを追加するコミットの最後）とmerge-commitgit cherry-pick -m 2 merge-commitの違いは、ウィジェットブランチにないクラッター除去であるため、クラッターを削除します。
マージコミットには2つの親があり、gitはマージのどちら側をメインラインと見なすべきかわからないため、 gitは親番号（-m）を指定するように要求しています。したがって、このオプションを使用すると、メインラインの親番号（1から開始）とチェリーピックを指定して、指定した親に関連する変更を再生できます。
コミットの親を見つけるには、次のいずれかを試してください。
git show --pretty=raw <merge_commit>
また：
git cat-file -p <merge_commit>
または、GUIの可視性を高めるために、次のことを試してください。
gitk <merge_commit>
結果として、次のようなものが得られるはずです。
commit fc70b1e9f940a6b511cbf86fe20293b181fb7821
tree 8d2ed6b21f074725db4f90e6aca1ebda6bc5d050
parent 54d59bedb9228fbbb9d645b977173009647a08a9 = <parent1_commit>
parent 80f1016b327cd8482a3855ade89a41ffab64a792 = <parent2_commit>
次に、次の方法で各親の詳細を確認します。
git show <parent1_or_2_commit>
追加--statして、変更されたファイルのリストを表示します。
または、次のコマンドを使用して、変更を比較します（上記の親に基づく）。
git diff <parent1_or_2_commit>..<commit>
追加--statして、変更されたファイルのリストを表示します。
または、結合された差分を使用して、次の方法で2つの親を比較します。
git diff --cc <parent1_commit>
git diff --cc <parent2_commit>
次に、チェリーピックの1から始まる親番号を指定します。例：
git cherry-pick -m 1 <merge_commit>
次に、実行git statusして何が起こっているかを確認します。まだ変更をコミットしたくない場合は、-n何が起こるかを確認するオプションを追加してください。次に、満足できない場合は、HEAD（git reset HEAD --hard）にリセットします。gitの競合が発生する場合は、おそらく手動で解決するか、マージ戦略（-X）を指定する必要があります。Gitでマージの競合を解決する方法を参照してください。
個人的に私が通常行うことは、マージが2つのコミットを結合するため、たとえば、2つの親で構成されるマージコミットCがある場合、たとえばマスターのコミットAとマージされる他のブランチのコミットBがある場合、チェリーピックが必要な場合マージマージコミット自体をチェリーピックするという紛らわしいコマンドを気にする必要はありませんが、代わりに親AとBのそれぞれを個別にチェリーピックします。これは、コミットBのみをチェリーピックする場合にも役立ちます。マージが行われる前に、マスターからのケースコミットAは、ブランチに対してすでにチェリーピックされていました。
マニュアルページの構文は次のとおりです。
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
親番号は次のことを示します。
-m parent-number、-mainline parent-number、通常、マージのどちら側をメインラインと見なすべきかわからないため、マージをチェリーピックすることはできません。このオプションは、メインラインの親番号（1から始まる）を指定し、cherry-pickが指定された親に関連する変更を再生できるようにします。
だから私はあなたが正しいコミットハッシュを持っていることを確認するために再確認します。マージからではなく、その前のコミットからのものが必要な場合があります。それ以外の場合は、このフラグを使用し、マージの正しい側をポイントして、要求を明確にする必要があります。
parent1コミット変更ウィジェット
parent2コミット変更クラッター
マージコミット（両方の変更を含む）ウィジェットの乱雑さ
git Cherry-pick -m 1 merge-commit diff of merge and parent1（master）merge --master = widget
git Cherry-pick -m 2 merge-commit diff of merge and parent2（WIDGET）merge-WIDGET = clutter