tfsの移行（全く異なるブランチの概念）の後、複数のリリースブランチにフィックスをマージする必要がありますが、ブランチは同一ではなく、ほとんど同じですが、たとえば異なるブランド、conn文字列など）、私はここでnvie gitflowの1つの製品分岐戦略を使用することはできません。ここgitブランチを複数のリリースブランチにマージする方法
https://github.com/MrKekson/stackoverflow_question/network
あなたは大幅に簡素化分岐構造を見つけることができ、かつ基本的に私はB1からhotfix1ブランチをマージする、tesztb3するが、B1の前のコミットなし（C3、C4 ）。
チェリーピッキングやリベースが役立つかもしれませんが、私はそれを手に入れることができませんでした。高度なgitの使用法についてはまだ多くの経験がありませんでした。ですから、それをどうやって行うのか、何を変えてやるのかアドバイスしてください。
[OK]を解決しました。
基本的に、hotfix1をteszt3に別々にコミットすることはできますが、それは不器用です。
したがって、b1からマージブランチを作成し、それにhotfix1をマージし、マージによって作成されたコミットをtesztb3に選んで、testb3で新しいコミットを生成することができます。 -xをcherry-pickに追加することもできるので、親のguidで新しいコミットについてのメモを作成します。代わりにhotfix1ブランチを1コミットにしてからcherryを選ぶことができます。
それとも我々は、その後、
git rebase --onto <new-parent> <old-parent> <lastcommit>
--onto explained hereを最後のコミット（HF2）に基づいてリベースブランチを作成することができますが、<new-parent>は、私がターゲットで、このためのマージブランチを作成することを好む私たちの目標支店teszt3ですブランチ、古いparentはhotfix1の開始点であり、この場合のlastcommitはhotfix1のhf2です。 次に、teszt3を新しいマージブランチにマージし、teszt3にプルリクエストを作成し直します。
私はどちらのパスも最初の見た目では簡単だと思いますが、ちょっとした経験があればうまくいくと思います。これは、tfsvcのディレクトリの名前を変更してスムーズに行える方法です。
また、正確に何を試してみたかについても言及する必要があります。チェリーピッキングは、おそらくあなたが望むものですが、試したチェリーピッキングとリベースのコマンドと、期待した結果が得られなかった理由を明記する必要があります。 – Vampire