Microsoft は新たな Branching and Merging Guide のドラフト版をリリースした。表向きの対象は TFS ユーザだが，アドバイスの大部分はソース管理プロバイダに関係なく適用可能だ。まずその基本概念を紹介しよう。
ブランチとマージを扱うほとんどのガイドラインと同様に，すべてのブランチの親の役割を持つメインブランチが存在する。 "trunk" として知られることが多いが，Microsoft ではこれを MAIN と呼ぶ。MAIN には DEVELOPMENT と RELEASE という２つの主要ブランチがある。
最初のガイダンスでは開発ブランチ(DEVELOPMENT) について取り上げている。内容は比較的簡素で，基本的には企業のチームや機能の構成方法に帰着する，というものだ。ただし前のバージョンから継続している独自の意見がひとつある。Microsoft は，開発ブランチでバージョンナンバを更新しないように奨めているのである。バージョンナンバの更新をメインブランチに限定しておけば，親ブランチと最後に再同期を行ってからの経過時間が一目で分かる，というのがその根拠だ。
リリースブランチ (RELEASE) に関しては，いくつかの選択肢が用意されている。もっとも単純なのは，その名のとおり "RELEASE" というブランチを作成する方法で，"ベーシックプラン" と呼ばれる。一度に複数のバージョンを必要としない継続的開発ならば，これは理にかなった方法である。
サービスパックを通じて随時更新されるアプリケーションの複数バージョンをサポートする場合，推奨されるのは "スタンダードプラン" である。このプランでは，メジャーリリース時にサービスパックブランチを作成すると同時に，読み取り専用にマークした本当のリリースブランチを分岐させる。読み取り専用であるため，コンプライアンス要件を満足する正確なスナップショットを維持するためには有効な方法だ。
必要ならば緊急の修正プログラムをリリースブランチに直接適用して，その後でメインブランチに反映するという方法も可能である。ただし修正プログラムが定常的に発生するような環境ならば，そのための独立ブランチを作成した方がよいだろう。ブランチの別途作成によるワークフローの変更に関しては， "Advanced Branch Plan (高度なブランチプラン)" と題した章に説明がある。
リリース側のブランチ戦略として，ガイドの最後に説明されているのが "コードプロモーションプラン" である。このプランでは，個人単位の開発やリリースプランといった考え方から離れて，開発者すべてがメインブランチで作業し，コードが十分に安定したと思われた時にテストブランチに更新を登録する。そして準備が整った時点で，テストブランチを本番ブランチに昇格するのである。
この方法はベーシックプランとは思想的に異なるが，実装作業に限ってしまえば，実質的な違いはそれほど大きくない。
以降の章では，機能毎にブランチを扱うための選択肢が説明されている。そこで取り上げられているテクニックは，ここまでに紹介したリリース管理方法のいずれに対しても等しく当てはまるものだ。
ローカル対サーバワークスペース
TFS に対する不満の多くが，サーバに常時接続していなければならない，という点に端を発している。結論から言えば，これには理由がある。TFS はもともと，Microsoft 自身の開発問題に対処するために設計されたものなのだ。すなわち，
- コードベースが巨大である (ブランチあたり 500万以上のファイルが存在し，開発者はそれぞれ平均 100,000 ないし 200,000 のファイルを使用する)。
- 世界規模で分散した開発チームが，比較的低速なネットワーク (300 kbps 以下) 上で作業する。
500万のファイルを持つブランチを作る必要があるなら，分散型 CVS より TFS が適しているのは自明である。これほど多数のファイルに対して，全ブランチにわたる更新履歴をダウンロードしようというのが，そもそも無理な話だ。
しかし，このような状況の開発チームは極めてまれだ。Linux のカーネルコードでさえ 920 万行 (2007 年から 2008 年頃) であり，その他のプロジェクトの大部分はこの数字にも遠く及ばない。さらに TFS は常時接続を前提としているため，すべての操作がサーバを介して実行されるという問題もある。
TFS 11 はローカルワークスペースを導入することで，この状況を一変させた。 "Subversion スタイル" としても知られるこのモードでは，不満の数多くが解決される。
- ファイルは読み取り専用ではなく，自由に編集可能である。編集を行ったファイルは "チェックアウト" として自動的にマークされる。
- 新たにファイルを作成すると，Team Foundation Server はそれを検出して，プロジェクトに追加可能とする。
- ファイルが削除されると，Team Foundation Server がそれを検知して，サーバからファイルを削除するか，あるいはサーバからローカルコピーを復元するかを選択させる。
- もっとも素晴らしい成果のひとつは，操作を正しく行うためにツールを使用する必要がなくなったことだ。(ファイルシステムをマスタとするため，Notepad などのツールを使っても Team Foundation Server は期待どおりの動作をする。ローカルコピーがマスタであり，Team Foundation Server はその変更を適切に処理するのである。
注: DVCS 形式のワークフロー (例: git) が希望ならば，TFS 12 まで待たなければならない。
Team Foundation Server の共有リソース管理
ドラフトの最後の章では，共有リソースの管理オプションを取り上げている。Visual SourceSafe では共有リソースの扱いが非常に簡単で，例えば "$＼projects-a＼bin＼commons" と "$＼commons" が同じフォルダとなるように，単純なフォルダ間のリンクが作成できる。必要ならば，この関連性をコマンドひとつで破棄することも可能である。
TFS にはこのような機能がないので，以下の３つのオプションから方法を選択しなければならない。
- ブランチ間で共有ファイルを複製する方法。無駄なディスクスペースを使用する引き替えに，ファイルの分離が実現される。
- ブランチ外部に別の共有フォルダを保持する方法。プロジェクトからはヒントパスを使用して参照する。この技法はエラーを起こしやすく，またアセンブリでのみ使用可能である。
- ワークスペースマッピングを使用して共有フォルダを作成する方法。共有フォルダはローカルハードドライブ上の各ブランチに配置する。ヒントパスよりも汎用的だが，開発者はそれぞれ同じマッピングを作成する必要がある。
各方法のトレードオフとワークフローについては，ガイドに詳しい説明がある。
まとめ
これらの提案が共同方式で開発された点には注目すべきだろう。Microsoft は CodePlex の TFS Branching and Mergeing Guide サイト において，フィードバックを積極的に募っている。何万の開発チームがこのガイドを読んで，同意できない点があれば同社に報告してくれることを望みたい。