问题描述
我们正在开发一个系统，该系统将在明年左右进行大量更改。我们将Azure DevOps与TFVC结合使用。我们的计划是开发，内部测试，发布到暂存环境中以供客户端内部测试，然后在消除错误后将其发布到实时环境中，但是我们希望以相当小的迭代来实现，因此不会一次发布大量变更，我们可以及早获得有关变更的反馈，以确保我们走在正确的轨道上，并且在进行大的更新后不会被大量需要修复的问题淹没。
让我担心的问题是，一旦我们发布到测试环境中，客户端将需要花费一些时间对其进行测试，在此期间，我们将一直在进行其他改进/错误修复。如果客户只是说一切都很好，那么当我们发布暂存版本并构建并发布该版本以供使用时，我可以使用VS来获取特定版本，但是如果出现任何问题，我们需要修复这些问题，我们最终将不得不让客户来测试我们一直在研究的所有新内容，并且我们可能正处于无法发布到阶段的大变化之中。
我看过TFS分支，但是它们似乎弄乱了路径，很难建立和使用它，我觉得它们并不是真的适合这种情况。
人们通常如何解决这个问题？
（我很高兴有很多人会争论说Git是更好的源代码控制系统，但是我特别在问如何使用TFVC做到这一点）
解决方法
TFVC中的分支远非轻量级，并且可以使本地分支之间的转换尴尬。
很难避免在切换时更改本地路径，这可以通过更改工作区定义，重新映射文件夹并强制获取最新版本来完成。
此处使用的另一个选项是git tfs，它将允许您在服务器上使用TFVC，但可以在本地使用Git并获得本地利益（包括多个本地分支以及在它们之间进行切换的能力）。
一种在开发进行中同时处理环境和批准的技术是创建促销级别分支。一个分支用于积极的开发，从该分支分支到下一个环境（测试），然后到下一个分支（接受？），一直到生产为止。
Development
\— Test
\— Acceptance
\— Production
每次开发都已经足够稳定，请将代码合并为Test。任何问题都可以直接在Test上解决，也可以在Development中进行修复，然后进行挑选。
开发与生产之间的距离越大，保持分支同步的难度就越大。
一种替代方法是使用发布分支，基本上使上述结构崩溃：
Main
\— Release 1
\— Release 2
主动开发发生在Main中，代码被合并并热固定在发行分支上。在发行分支上所做的任何更改也必须重新合并。
有更好的解决方案
您可以通过帮助客户更快地测试潜在版本来代替尝试通过开发新功能来提高工作效率吗？在这种情况下，您无需等待太长时间即可完成测试，可以提供超快速修复程序，然后将重点放在更多的新开发上。它将防止各种合并，重新出现未正确合并回主要代码的错误等问题。