0

私たちの開発努力のために出てきた状況のためのいくつかの分岐戦略を探しています。私たちは TFS 2010 を使用しており、次の 3 つのブランチを持つ基本的な 2 ブランチ ブランチ シナリオを使用しています。Dev、Main (これは安定したプライマリ ブランチであり、他の 2 つのブランチはそこからブランチされました)。現在、Main と Release は同じで、Dev ブランチで多くの変更が行われています。

最新の開発プロジェクトを開始したとき、通常の慣行に従い、Dev ブランチで行われたすべてのことをある時点まで行ってから、リリース プロセスを開始することが想定されていました。さて、いつものように状況が変わり、今は Dev ブランチで行われた作業の一部 (変更の ~20%) だけを取り、それからリリースしたいと考えています。

私たちが促進しようとしている変更のほとんどはスタンドアロンですが、必要なリリース機能のみを保持する必要のあるファイルがいくつかあります。

では、現在の 2 分岐戦略を考えると、最初は複数の機能に基づく分岐戦略に沿って構造化されるべきだったものをどのように調整すればよいでしょうか?

これは TFS を使用した最初の大きなプロジェクトであり、残念ながら、変更セットに複数の機能を含めたり、ラベルを使用したりしないなど、適切なソース管理を実践していませんでした。

私が考える最悪のシナリオは、Main から新しいブランチを作成し、それを Feature1 と呼び、Dev ブランチから Feature1 ブランチへの変更を手動でコピーする必要があることです。これが唯一の方法ですか、それとももっと効率的な方法がありますか?

4

1 に答える 1

0

はい、新しいブランチを作成する必要があると思います。しかし、私はこれを Feature1 とは呼びません。リリース ブランチの使用を開始します。

メインからリリース ブランチを作成します。次に、Dev からのリリースに含める予定のすべてをマージします (手動でコピーする必要はありません)。Main ブランチに変更がない場合、マージによって競合が発生することはありません。これで、リリース ブランチで安定化作業を開始できます。

Dev で作業を続けることができ、リリースの準備ができたら、Release から Dev へのすべての修正と Main へのすべての変更をマージします。

今日はラベルを使用していないため、リリース ブランチをロックする必要があると思います。次のリリースでは、新しいリリース ブランチを作成します。(開始する前に、すべてのリリース ブランチの適切な命名規則を考えておいてください) そうすれば、いつでもすべてのリリースに戻ることができます。

于 2012-08-03T13:15:52.953 に答える