【发布时间】：2012-07-02 22:36:34
【问题描述】：
我正在评估 TFS 作为公司的替代源代码控制选项，并记录如果我们开始使用它，我们当前的流程将如何改变或保持不变。
我们在当前产品中大量使用标签，不仅用于创建给定构建的快照，还用于针对未来构建的特定修改。我们的标准是始终签入每个文件，并带有其预期发布版本的标签。
我们当前的软件在签到屏幕上有一个“标签”选项，因此签到/标签是一个一步的过程。有没有办法用 TFS 做到这一点？我看到您可以在事后打开源代码控制资源管理器并标记事物，但是如果用户必须四处点击以找到正确的变更集以在事后进行标记，我想确保记录下来......
【问题讨论】：
-
这些“目标发布”标签如何在您的流程后期使用？我可以看到一些可能的替代方案，但首先需要知道这一点。
-
可能最容易举个例子：1.22 正在生产中。我们开始1.23的开发。此时，项目中的所有文件都标记为 1.23。在签入更改时，该标签会向上凸起，以便任何人随时都可以在 1.23 上执行“获取”并进行编译。随着 1.23 的交付日期越来越近，一些任务被撞到了 1.24。因此，所有 1.23 项也都标记为 1.24。最终目标是抓住一个给定的版本并编译而不用大惊小怪。看起来分支/合并是我需要完成的类似操作，但如果您有其他建议，欢迎提出。 :) 谢谢。
-
我明白你在使用标签而不必“弄乱”分支的观点。如果目的更多的是文档/报告类型，我会建议与强制性工作项相关联，然后将发布字段添加到您将使用的那些 WI。但这现在不能解决您的问题，因此我建议您按照下面的 ShellShock 回答，并使用适合您需要的指南中的分支场景。您将必须调整您的流程，并在合适的时间点创建发布分支。