首先有点背景......
我正在为我们的项目设置一个版本编号系统，该系统目前只有一个开发分支，但我们现在正朝着我们的第一次部署迈进。我们正在使用TFS，我们在dev分支上使用nightly build。
我们可能会采用的方式是，当我们为发布做好准备时，我们从dev开始分支，并将其称为1.x.这应该是一个测试分支：我们测试它，修复它（然后合并回dev），再测试一下，然后当它全部好的时候我们从1.x分支取另一个分支并称之为1.0。这个分支被部署到生产中。生产中的任何修复都将对1.x进行测试，然后将生成一个新的分支1.1。
我的问题在于测试1.x分支。在测试之前，分支将被锁定，原因很明显。我的问题是质量保证要求对“版本号”进行一轮测试，如果测试失败，下一轮测试将针对新的“版本号”。我们的开发人员希望将“版本号”与发布版本联系起来，测试可以迭代该版本......所以这里存在冲突。
我的第一个想法是使用内部版本号作为测试代码的时间点。当提交新版本进行测试时，1.x分支再次被锁定并且构建开始，生成的VSTS编号变为“v1.0的发布条件1”。将RC映射到构建，我们可以在电子表格中手动完成......
...然后有人提到标签，并且在测试之前应该将代码锁定并构建。我以前从未使用过标记，只是读过构建本身在TFS中创建标签。
我现在很困惑这里最好的方式是什么。是否足够使用发布候选版本号？手动标签在这里是否有用（我能看到的唯一好处是我们可以给出自己的名字和描述）？我是否可以告诉TFS在运行构建时不要创建标签，并且只在重要时间点执行我们自己的标记（例如，并非每个构建都将成为候选版本）？如果是这样，在每个构建一个坏主意之后不创建标签，标签给我什么？
我想我对changsets，构建数字/名称和标签彼此适合的地方感到困惑......
这是一个广泛的问题，但其中一个我不是100％肯定要问的问题。任何帮助表示赞赏。
答案 0 :(得分：2)
...然后有人提到标签，并且在测试之前应该将代码锁定并构建。我以前从未使用过标记，只是读过构建本身在TFS中创建标签。
你所读到的是正确的。使用TFS（与SourceSafe不同），每个服务器操作构成一个“已知时间点”，以后可以参考。您可以通过Get Specific Version...查看Version下拉列表来了解我的意思：在TFS 2005中我看到的相关内容是Changeset，Date，{{1} }。现在，正如您所说，每个构建都会自动创建一个标签。这意味着在将来任何时候都可以完全按照任何给定的变更集之后检索代码;在任何给定日期;当应用任何特定标签时，包括何时完成任何构建。
结果是您可以使用自己的标签，完全由您自己决定 - 无论如何，检索代码的给定快照的能力都会存在。我不建议试图阻止TFS为每个版本生成一个标签（我不知道这是否可能） - 标签不需要任何费用。
答案 1 :(得分：1)
您的分支机构1.x是合并branch，其中包含许多渐进的小规模演变 锁定分支不是答案。
设置标签（专门命名为“用于QA测试”，并且为了无法移动该标签而锁定）是向QA团队发出信号的通常方式，他们可以构建自己的工作区并检索该确切的标签。登记/> 然后他们可以开始对代码进行测试 每次构建后Creating a label并不总是实用的，因为不是每个构建都要由QA测试。