これが私のシナリオです：
githubのオープンソースプロジェクトを修正したいとしましょう。大まかに言えば、私は次のワークフローに従います。
- githubでソースプロジェクトをフォークします
- フォークをローカルに複製する
- マスターからトピックブランチを作成する
- 私の修正を行います（ここで無関係な詳細を振る手...）
- トピックブランチをgithubにプッシュ
- 元のソースプロジェクトにプルリクエストを送信する
さて、これを数回行ったとしましょう。そのため、issue＃123とissue＃456というトピックブランチがあります。元のソースプロジェクトには、マスターブランチに加えて、リリースブランチ（1.0、1.1など）があります。
このオープンソースプロジェクトのバージョン1.1を使用する独自のプロジェクトがあります。まだ安定していないので、オープンソースプロジェクトの「マスター」に対してビルドしたくありません。必要なのは、オープンソースプロジェクトの1.1ブランチのローカルビルドで、issue＃123とissue＃456の修正も含まれています。
セットアップに時間がかかって申し訳ありません...とにかく、私が現在行っているのは、my-1.1（1.1から分岐）というローカルブランチを作成し、トピックブランチから修正を選択してビルドし、結果を使用することです。私の別の依存プロジェクト。
チェリーピッキングがここに行く正しい方法であるかどうかは100％わかりませんが、マスターからの1.1以降のすべての変更（トピックブランチに存在する）が必要ないため、マージは正しくないようです。 「my-1.1」ブランチに流れ込みます。これが最善のアプローチですか？知っておくべき落とし穴はありますか？
私が考えることができる他の唯一のアプローチは、修正ごとに重複するトピックブランチを作成することです。1つはマスターからのブランチに、もう1つは1.1からのブランチに作成します。次に、マスターベースのトピックブランチからコミットを選択する代わりに、1.1ベースのトピックブランチをmy-1.1にマージできます。しかし、それは大きな問題のようです。