GitHubでOSSプロジェクトをフォークし、それにいくつかのカスタム拡張機能を追加しています。行った変更の一部（バグ修正など）を元のプロジェクトに送り返したいと思いますが、他の変更は、元のプロジェクトのメンテナが現時点では関心を持っていない機能拡張です。私はこの状況を管理するための最良のワークフローを見つけようとしています。
マスターブランチに（元のプロジェクトからのコミット）+（貢献のためのバグ修正）+（カスタム拡張）の合計を含めたいと思います。バグ修正をカスタム拡張とは別に保つことができるように、機能ごとのブランチモデルが必要になると思います。マスターブランチからカスタム拡張ブランチを開始することもできますが、ローカルの「オリジン」ブランチまたは元のプロジェクトを追跡するものを維持して、そこから汚染されていないバグ修正ブランチを開始できるようにすることもできます。カスタムのもの。か何か。
さまざまなコミットがすべて予定されている場所に行き、誰も予定されていない場所に行くように、このワークフローを構築するための最良の方法を誰かが提案できますか？
あなたはすでにあなた自身の質問に答えているように私には聞こえます。「バニラ」またはアップストリームのマスターブランチを追跡するものと呼ばれるブランチを作成し、カスタム拡張機能を含む「マスター」ブランチを作成します。行うことごとにブランチを作成します。バグ修正については、「バニラ」から始めてください。あなた自身のもののために、マスターからそれらを始めてください。時々、バニラをマスターにマージします。バグ修正をカスタム拡張ブランチに取り込むには、ブランチをマスターに直接マージするか、アップストリームがバグ修正プルリクエストを受け入れるのを待ってから、バニラからマスターへの次のマージにバグ修正が含まれます。これはごく普通のワークフローのようです。
セットアップしたいのは長期フォークです。これを行うには、元の「バニラ」プロジェクトにリンクされた特別なブランチをセットアップし、カスタム作業コピーを維持するマスターブランチを作成することが解決策であることがすでにわかっているためです。
（私の観点から）覚えておく必要がある唯一のことは、変更を同期するときに2つのブランチをマージするべきではないということですが、この場合（ブランチが分岐するとき）、便利なGitCherryがあります-あるブランチから単一のコミットを取得して別のブランチに適用できるPickコマンド。これは、あるブランチから別のブランチに単一のコミットを簡単に交換できるため、フォークを維持する場合に特に便利です...