我们正在开发一个系统，在未来一年左右的时间里，我们将对该系统进行大量更改。我们将Azure DevOps与TFVC结合使用。我们的计划是开发、内部测试，发布到一个阶段环境中供客户端内部测试，然后在bug解决后发布到实时环境中，但我们希望在相当小的迭代中做到这一点，因此，我们不会一次发布大规模的更改，我们可以尽早获得更改的反馈，以确保我们走在正确的轨道上，不会在重大更新后被大量需要解决的问题淹没。
让我担心的问题是，一旦我们发布到测试环境中，客户端将需要一段时间来测试它，在此期间，我们将一直致力于其他改进/错误修复。如果客户只是说一切都很好，我可以在我们发布暂存版本时使用VS来获取特定版本，并构建和发布它，但如果出现任何问题，我们需要解决这些问题，我们最终将不得不让客户测试我们一直在做的所有新东西，我们可能正处于一个巨大的变化之中，而这些变化对于发布到阶段来说是不切实际的。
我看过TFS分支机构，但它们似乎把道路弄得一团糟，设置和使用起来很痛苦，我觉得它们并不适合这种情况。
人们通常是如何解决这个问题的？
(我很感激很多人会说Git是一个更好的源代码管理系统，但我特别问如何使用TFVC(
TFVC中的分支远非轻量级的，可能会使本地分支之间的切换变得尴尬。
切换时很难避免更改本地路径，可以通过更改工作区定义、重新映射文件夹和强制获取最新文件夹来完成。
这里使用的另一个选项是git tfs，它将允许您在服务器上使用TFVC，但Git是本地的，并获得本地的好处(包括多个本地分支以及在它们之间切换的能力(。
在开发过程中，一种处理环境和审批的技术是创建晋升级别的分支机构。一个分支用于主动开发，从中分支为下一个环境(测试(，然后是下一个(验收？(，一直到生产。
Development
— Test
— Acceptance
— Production
每次开发足够稳定时，将代码合并到测试中。任何问题都可以直接在测试中解决，也可以在开发中解决，然后进行挑选。
开发和生产之间的距离越大，就越难保持分支机构的同步。
另一种选择是使用释放分支，基本上可以稍微折叠上面的结构：
Main
— Release 1
— Release 2
Main中进行了积极的开发，代码被合并并在发布分支上进行热修复。对发布分支所做的任何更改也必须合并回来。
有更好的解决方案
你能帮助客户更快地测试潜在的发布版本吗？在这种情况下，您不需要等待太长时间来完成测试，可以提供超级快速修复，然后将重点转移到更多的新开发上。它将防止合并的各种问题，从没有正确合并回主代码中重新出现错误等。