新しいプロジェクトの新しい開発チームから始め、ソースリポジトリ（Microsoft Team Foundation Server 2010など）の分岐戦略を定義する必要があります。私たちは...するべきかどうかという難しい議論にぶつかりました...
A。実稼働ビルドを行うリリースブランチが1つあり、実際に何かがリリースされたときにラベルを付ける
または
B。本番環境への新しいリリースごとに新しいリリースブランチを作成します（例：バージョン1、2、3など...）
オプションAは非常に簡単に思えますが、これが長期的に問題を引き起こすかどうかはわかりません。オプションBは、時間の経過とともに積み重なる1回限りの長寿命ブランチを作成するだけのようです。
私たちが決めるのを助けることができる経験はありますか？具体的には、いずれか1つの選択肢のどこに問題があるのかを聞きたいと思っています。TFSおよび/またはリリース管理の意味に関連する特定の経験を提供してください。
回答:
オプションA.メインラインを使用してリリース用にタグ付けするだけ
長所：
短所：
個人的に私はこのアプローチを好みます。コードカバレッジと単体テストでは、出て行く準備ができていないコードを特定し、現在の反復中にリリースされないコードで作業するべきではありません。抽象化または他のメカニズムによる分岐は、長期的な変更や進行中の作業に対処するために使用できます。
これを行わないと、マージの問題、古いコード、リリースされない機能などに対処することに気づき始めます。
オプションB.リリースごとの分岐
長所：
短所：
私はこのソリューションの大ファンではありません^ _ ^。
一般に、メインラインに固執することをお勧めします。開発者がWIPを作成できない問題を抱えている場合、カットに失敗した場合に簡単にヤンクできるか、次のリリースで早期にチェックインできる場合は、コードが完成して分岐する必要がある時点でコードのタグ付けについて話し始めることができますそこから必要に応じて、開発者の単体テストがキャッチできなかった見落とされた欠陥やバグに対処します。
理想的には、ルールではなく例外プロセスにしたいのですが。
オプションC.クレイジーボーナスオプション
おしゃれにしたい場合は、ユーザーストーリーごと/機能ごとの分岐モデルを検討することもできます。（gitやmercurialなどのDVCSを使用している場合、TFSまたはDVCS以外のひどいアイデアを実装するのは非常に簡単ですが、同時に実装するのは非常に簡単です）。
過去に、以前の雇用者メンテナンスチームに以下を実装しました。このチームは、svnからmercurialに簡単に移植できないレガシーコードベースで作業していました。リリースをよりよく調整するのではなく、常にリリース可能なメインラインのビジネス要件を満たすために多くの不要な作業が関係しましたが。。。
発表したリリースごとに別々のブランチがあります（年間約4回）。特定のリリースをプルする必要がある場合に非常に便利です。
いくつかの古いリリースを維持する必要がある場合、ラベル付けで十分だとは思いません。特定のリリースブランチでは、他のリリースを気にすることなく、各ブランチに個別に（または選択したものに）ホットフィックスを適用できます。
また、バグや機能が導入された時期を探しているときに、リリースの比較がはるかに簡単になります。
ブランチの数やブランチが変更なしで進む時間について心配する必要はありません。バージョン管理システムは、プロジェクトの開発の制御と履歴の提供を目的としています。歴史は変わらない傾向があります...そしてあなたのcvsが対処できないことを心配しないでください。開発ブランチではPerforce、9000以上のファイル、作業中のリリースでは最大50の開発ブランチを使用し、既に述べたように、リリースごとに1つのブランチを公開しています。パーフォースは一生懸命呼吸していません。
要するに、開発者/メンテナー/バグ修正者/問題ハンターとしての生活を楽にし、ブランチの数やファイルの数を心配しないでください。自尊心のあるcvsは対処します。
編集：
ブランチの数に関して混乱はまったくありません。リリースブランチの命名スキームと開発（または作業）ブランチの1 issue 1ブランチポリシーは、それと関係がある可能性があります。
リリースブランチは、保持するリリースに基づいて名前が付けられます。つまり、リリース2011 Service Pack 1のR2011SP1です。作業ブランチの名前はインテリジェントではありません。sub01、sub02、sub03などです。受け入れブランチの。承認ブランチは、リリースする準備ができているすべての問題が収集されるブランチです。
課題追跡システムが「ブランチ」フィールドでカスタマイズされているという事実と相まって、1課題1作業ブランチポリシーは、どの課題がどのブランチで開発されているかを常に確認できるようにします。問題が受け入れブランチに統合されると、このフィールドが更新されます。これは、リリースの準備ができている問題を常に把握していることを意味します（受け入れテストが完了したら）。同様に、リリースブランチが作成されたときにこのフィールドを更新します。これにより、どのリリースで問題がリリースされたかを常に追跡できます。
コンテキストがすべてです：リリースの頻度とリリースの内容。
Bメソッドを使用して、以前の作業で行った少しのケーススタディを以下に示します（目的によってブランチと呼びます）。
ストーリーを文脈に合わせるために、
特定のリリースで機能が完全な状態になるまで、主な開発はトランクに組み込まれました。その時点で、たとえばprojectname-january2012というブランチを作成し、そのブランチで品質テストとバグ修正を行います。パブリックリリースの準備ができたら、そのブランチのコードにタグを付けてリリースします。
ただし、リリースでの開発はそのタグで終わりませんでした。必然的に、リリースにバグや小さな問題を発見したクライアントがいました。その場合、そのブランチに戻り、コードにパッチを適用し、リリースされるjanuary2012ブランチの新しいタグ付きバージョンを作成し、修正をトランクにマージするだけです。
私たちの場合、一部のユーザーは機能の限定された古いリリースにとどまることを好むため、または単にホットフィックスではなくインフラストラクチャにまったく新しいバージョンを展開するコストが問題を引き起こすため、このアプローチは好ましいものでした。
したがって、あなたが自問しなければならない質問は次のとおりです。
頻繁にリリースする場合は、それぞれにブランチを用意する価値はありません。ただし、私の古いユースケースのようにリリースサイクルがかなり長く、そのリリース、下位互換性、古いリリースに固執するクライアントがリスクになる可能性がある場合、オプションBは確かに多くの苦痛を軽減し、物事をサポートしやすくしますブランチクラッターに対処する最小限のコストでクライアントをサポートします。
私はオプションAを好みます。安定しているときにトランクおよびブランチリリースで開発します。これにより、実稼働リリースに適用されるホットフィックスを統合する作業が大幅に制限されます。
私は、オプションBを試みたチームが軌道に乗るのを助けるために契約しました。
考慮すべきことがいくつかあります。
私は、あなたが説明している2つのスキームの間に何かを使用するシステムに何年も取り組んできました。重要なのは、マルチレベルの番号付けスキームが使用されていることです。外側のレベルは基本的にAPIバージョンであり、それはブランチで管理され（複数のブランチで何かを修正する必要がある場合に適切なクロスマージを使用）、内側のレベルはタグで管理される正確なリリースです。
特に、顧客の正確なバージョンがわかっている場合、コードの作成元を正確に把握し、正確な複製を作成して、何が起こっているのかを正確に確認できます。これはサポートのために非常に重要です！しかし、現在リリースされているAPIバージョンであるブランチの外部レベルは、時間とともに進化します（開発のメイントランクが新しい機能の大部分を取得します）。また、APIの新しいメジャーリリースを行うとき、それをサポートするための新しいブランチを作成します（したがって、トランクは常にハードコア開発指向にすることができます）。ブランチ。
したがって、実際にはAとBの両方が混在するものをお勧めします。両方とも良い面を持っていますが、どちらもそれ自体では完全ではありません。両方の長所を活用してください。
過去にオプション（B）を効果的に実装するためにTFSを使用しました。
分岐/マージは、小さな部分で行うと優れたツールです。困難なのは、ブランチを作成すること（愚かな簡単なこと）や、1週間分の作業をツリーに戻すこと（通常は簡単なこと）です...ソース管理の背後にあるCIシステムを自動的に機能させることです。君は。
システムがブランチのテストを自動的に構築および実行していない場合、ブランチは意味がありません。
TFSのデフォルトのビルドワークフローをカスタマイズして、変更セットの相対パスを認識し、（一部の開発ルートの下の新しいサブフォルダーとは対照的に）カスタマイズが新しいブランチを認識できる規則を確立しました。スムーズで、ブランチが簡単で、ブランチを簡単に削除でき、コンパイルとテストのためにシステムから継続的なフィードバックを得ました。
これらの戦略がTFSのもとでどれほど不可能であるかを宣言する人がたくさんいますが、それはXAMLベースのビルドエンジンの可能性に精通していないためだと思います。TFSは単なるソース管理ではなく、ソリューション全体であるため、そのまま使用する必要があります。