gitチェリーピック操作はGitで一般的ですが、通常は最善の解決策ではありません。これは2つの悪のうちの小さい方である場合もありますが、それが適切である状況はまだ見ていません。
これは、コピーが悪い理由を説明することから始まり、コピーがひどい理由を説明し、次にマージを使用して同じ結果を得る方法を説明するシリーズの最初の部分です。遡及マージを実行する必要がある場合、および何か問題が発生する前にコピーからマージを修正する場合に、この手法を適用する方法を説明します。
コピーには、ドナー（コミットの送信元）と受信（コピーのコピー）の2つのブランチが関係します。それらをそれぞれマスターと機能と呼びましょう。簡単にするために、コピーするコミットに1つのファイルの1行だけに変更が含まれていると仮定します。この図では、各コミットはその行の内容でマークされており、破線の矢印はコピー（操作git cherry-pick
）自体を示しています。
影付きの矢印はリポジトリに物理的に存在するのではなく、タイムラインを追跡するのは私たちの頭の中だけであることに注意してください。
「アップル」ラインコミットを持つAの共通の祖先がいくつかあります。次に、ブランチが分岐し、F1コミットが機能ブランチにあり、M1がマスターにあります。これらのコミットは問題の行に影響を与えないため、「apple」というラベルが付けられたままです。次に、F2を機能ブランチにコミットします。これにより、行の内容が「berry」に変更され、F2がM2というマスターブランチにコピーされます。
これまでのところ、異常なことは何も起こっていません。
時が経つにつれて、リポジトリツリーは新しいコミットで強化されます。
M3をマスターに、F3をフィーチャーにコミットしました。両方のコミットは私たちのラインをバイパスするので、それはまだ「ベリー」です。
feature master. , , "berry".
, , , .
. F2 3 master F3 feature, F3 "cherry". , feature, , "cherry". , :
feature master . (three-way merge) "apple", feature "cherry", — "berry".
<<<<<<<<<< HEAD (master) berry ||||||||| merged common ancestors apple ========= cherry >>>>>>>>>> feature
, , . , .
, , , feature.
( , .). ?
, "apple". victim A V1, . V1 feature : F1 , "apple". master 1, .
. feature "berry" F2, master M2. "cherry" feature F3. master 3, , master "berry".
victim "-" feature master. V2 V3, "apple".
- , feature victim, V4 , "cherry" feature.
"" victim, master. ! : "" F2 M2. , , , () , .
つまり、問題git cherry-pick
は、1つのコミットの2つのコピーがツリーに表示される場合です。コピーをマージする前に少なくとも1つの行が変更されると、強制されない衝突が発生します。さらに、これは1週間または1年で発生する可能性があります。これは、それを解決する人が正しい決定を下すためのリソースを持っていない可能性があることを意味します（彼がコピーしなかった、チームが完全に変わったなど）。
しかし、紛争が起こらなければ、このサンタバーバラのすべてが悪化する可能性があります！
どうして？次のパートで読んでください。