TFSでブランチをどのように構成しますか
私の職場のグループは、TFSで使用できる優れたプロセスを考え出そうとしています。複数のブランチを使用している複数のサイトでTFSを使用することで成功した戦略があるのかと思っているところです。
私たちが抱えている特定の問題の1つは、おそらくリリースエンジンです。簡単に言えば、開発者は自分の変更をDEVブランチにチェックインして、特定の日付（たとえば、凍結日）を確認できるようにする必要があります。DEVブランチはメイントランク（QA）に「リバース統合」されます。その後、変更は本番ブランチにプッシュされます。この問題は、ユーザーがDEVブランチにチェックインしたときに発生しましたが、それらの変更がQAに移動されることを望んでいません（おそらくコードの他の部分がまだ完了していないため）。
私はそれを約4年間、いくつかの異なるチームで使用しています。私たちのグループで最もうまく機能しているのは、リリース/イテレーションによるブランチの管理です。したがって、反復のすべての変更は開発ブランチで行われ、それらすべてがQAに進む準備ができたらマージします。
実際にマージする準備ができていないブランチに何かがある場合、これは少し問題になりますが、それらの変更セットをマージしないことを選択できます。あなたが含めていないコードがいくつかの重要な部分または何かを変更する場合、それは面倒になりますが、私の経験ではまれです。私たちが行ったことは、すべてが本当に最後まで完了するように反復を管理することです。リスクのある部分がある場合は、それだけのためにDEVブランチからブランチを作成して、個別に管理できるようにすることができます。
マージに多くの時間を費やさないように、ブランチはできるだけ少なくします。
この質問に対する私の古い答えは機能します。しかし、それ以来、プロセスは大幅に改善され、自動デプロイメントが組み込まれたので、今言っておきます。
現在、2週間の反復がありますが、反復のすべてを待つのではなく、変更が加えられ、レビューされ、テストされるのと同じ速さで新機能をデプロイします。これを容易にするために、メインブランチ（トランク）に再編成し、次にメインブランチから開発ブランチに再編成しました。レビューに合格した変更はメインにマージされ、デプロイメントはメインから半自動的に行われます。この戦略は本当にうまくいきました。変更を小さなチャンクでメインに移動するため、マージが困難な場合はほとんどありません。
MSは、1つのアプローチとその理由を詳しく説明したホワイトペーパーを発行しました。
http://tfsbranchingguideiii.codeplex.com/ （これは2008/2010バージョンです。2005バージョンもあります）。
そのリンクは現在古くなっており、アドバイスは更新されています。 https://blogs.msdn.Microsoft.com/visualstudioalmrangers/2016/07/18/the-new-branching-guidance-for-team-foundation-server-team-services-and-others/をご覧ください。