バージョン管理で開発の複数の「ストリーム」を同時に処理する最良の方法は何ですか？
私の部門は、次のいくつかのリリース（1年に及ぶ）を同時に処理することを計画しています。影響を受けるすべてのコードをAbstractGizmo、R1Gizmo、R2Gizmoなどのクラスにリファクタリングすることでこれをサポートし、特定のリリースで使用されるクラスを制御するために（SpringやANTを介して）構成を使用することを支持している権限。表面上、これは、特に変更が共通コードにある場合に、変更を複数のブランチにマージする作業を節約するためです。ただし、バージョン管理（この場合はTFS）での分岐とマージの明確なケースとしてこれを確認します。
ただし、このような開発の流れが活発なプロジェクトについては、ほとんど経験がありません。他の人もいると思います（Microsoft、Windows XP、Vista、7など）。バージョン管理で開発の複数の「ストリーム」を同時に処理する最良の方法は何ですか？バージョン管理の変更を分岐してマージし、1つの分岐ですべてを開発し、構成またはビルドスクリプトを使用して別のバージョンなどをアセンブルしますか？
追伸現在、TFSを使用していますが、バージョン管理戦略はそれによって制約されない場合があります。私の同僚はGitまたはMercurialへの切り替えを強く求めており、少し引き付けられているようです。
ご想像のとおり、これはVCSの明確なユースケースです。しかし...すべてのVCSがマージをうまく処理できるわけではありません。私はTFSと話すことはできませんが、Subversionのマージ追跡には多くのことが望まれます。 HgやGitなどのDVCSは、マージをより適切に処理します。マージは常に単純であるとは限らず、多くの開発者が比較的単純なマージでも問題を抱えていることがわかりました。マージをうまく処理できる人が1人か2人いる場合は、それが役立ちます。
ファイルの名前を変更して別のブランチの同じファイルを変更したり、あるブランチから別のブランチに複数回マージしたりする、いくつかの小さなサンプルアプリでTFSのマージをテストすることをお勧めします。
あなたが説明する複数バージョンの1つのツリーによるアプローチは、最初のリリースに近づき、2番目のリリースでいくつかのリファクタリングまたは大幅なインターフェイスの変更を行う必要があることに気づくと、本当の悪夢を生むようです。リリースの近くでコードベースにこのような大幅な変更を加えたくはありませんが、2番目のリリースで必要な作業のために変更を遅らせたくはありません。分岐していないと、同じツリーのファイルにそれを生かすことが難しくなります。
私はretracleに同意し、いくつかのTFSエクスペリエンスを追加します。マージは痛みを伴う可能性があるため、同時の競合の数を減らすために、できるだけ頻繁に行う必要があります。ストリームの1つがほぼ完成するまで、または悪夢のような状態になるまで、保存しないでください。
ALMレンジャーのガイダンス を読んで、設定する必要があります。うまくいけば、マージは以前のバージョンよりも大幅に優れているため、TFS 2010を使用しています。
このブログ も興味深いかもしれません。 Brian Harryがgit、TFS 2010、およびTFS 11のマージ体験を比較します
他の回答で指摘されているように、これは分岐とマージのtheの古典的な使用例なので、これを試すこともお勧めします。
ただし、これが唯一の解決策ではありません。代わりに、「機能フラグ」を使用することもできます。
基本的に、（まだ）アクティブではないと思われる変更はifブロックにラップされるため、構成によってオン/オフを切り替えることができます。のようなもの：
($cfg.enable_Unicorn_polo) {
// do something new and amazing here.
}
else {
// do the current boring stuff.
}
これには、branching＆merginソリューションと比較して長所と短所がありますが、それについて知っておくと便利です。
これはどうやらFlickrが開発を行う方法です。ソース：
分岐が機能しない場合は、Cruise Controlなどのビルドサーバーでの継続的な統合を検討してください。ビルドサーバー上の各ビルドは、すべての単体テストと統合テスト（およびデータベースの一貫性、コードカバレッジなどの他のチェック）を実行する必要があります。ビルドが失敗した場合、チェックインした人がすぐにこれを修正する必要があります-ビルドまたはフィックス以外のタスクがビルドの修正を上回ってはなりません（ビルドが壊れている場合、両方を遅らせることを検討してください）。他のユーザーによるチェックインは、修正がチェックインおよび検証される前に許可されるべきではありません。
注：分岐と継続的な統合は、並行して機能する可能性があります。