ここで懸念しているのは、別のローカル ブランチ [abc.cpp、def.cpp を含む] に古いコミットがあることです。
数か月後、これらの変更を使用したいのですが、現在のブランチでは abc.cpp がアップグレードされています。それで、私がチェリーピックすると、古いabc.cppの変更を新しいabc.cpp [最近の作業ディレクトリのコピー]に統合するようなものですか?
ここで懸念しているのは、別のローカル ブランチ [abc.cpp、def.cpp を含む] に古いコミットがあることです。
数か月後、これらの変更を使用したいのですが、現在のブランチでは abc.cpp がアップグレードされています。それで、私がチェリーピックすると、古いabc.cppの変更を新しいabc.cpp [最近の作業ディレクトリのコピー]に統合するようなものですか?
git-cherry-pick(1) の man ページには次のように書かれています。
1 つ以上の既存のコミットがある場合、それぞれが導入する変更を適用し、それぞれに新しいコミットを記録します。これには、作業ツリーがクリーンである必要があります (HEAD コミットからの変更はありません)。
git cherry-pick
簡単に言えば、これはあるブランチから別のブランチにコミットを適用することを意味しますが、適切なマージが行うように、元の履歴や他のブランチの祖先は保持しません。
履歴の 2 つのブランチを完全にマージするのではなく、選択した一連のパッチを適用すると考えてください。明らかに、非常に小さいアトミック コミットを作成する傾向がある場合、チェリー ピッキングは適切に作成されたパッチを適用するのとまったく同じように見えます。ただし、マージやリベースのように共通の祖先がないため、コミットが小さく分離されていない場合、解決すべき競合がさらに多くなる可能性があります。
チェリーピッキングが良いアイデアかどうかは、コミットの構造に大きく依存します。それがうまくいかない場合は、代わりにgit format-patch
and を使用して、いつでも手動で行うことができますgit apply
。
はい、それはそれがすることです。cherry-pick
ブランチへのパッチとしてコミット (またはそれらの範囲) を適用しています (まあ、ほぼ patch として)。
ブランチで独立した変更が行われたため、競合が発生する可能性があります (ブランチをマージする場合など)。