TFS 提交最佳实践？答案

【问题标题】：TFS commit best practice?TFS 提交最佳实践？
【发布时间】：2014-03-11 00:02:12
【问题描述】：

在我以前的工作中，鼓励程序员经常使用 cmets 签入代码。在我现在的新工作中，规则是在对他或她的代码进行 QA 之前，任何人都不能签入任何东西。但由于质量检查落后太多，我们很少能签到。我们大概可以每两周左右检查一次。而且，当我们被要求办理登机手续时，要弄清楚需要办理登机手续的机票发生了哪些变化，真是令人头疼。你们了解这种痛苦吗？结果是，我们程序员经常忘记签入一些重要文件以获取某些票证。另一个后果是：我已经修改了工单 1 和工单 2 的 file1.html。现在我们被要求只检查工单 1 的更改，然后我必须在我的解决方案之外保存 file1.html 的副本，并且然后确定票 1 的更改是什么，并在我签入之前删除票 2 的这些更改。痛苦！

你有什么建议？我应该说什么来说服这里的团队停止此签入政策并允许我们在进行 QA 之前尽可能频繁地签入？谢谢！

【问题讨论】：

如果您不先签入相关代码，您的功能实际上如何获得 QA？
这里我们以适得其反的方式进行：我们直接从我们的开发箱部署到我们的开发环境 IIS 服务器。这就是 QA 团队进行测试的方式。
如果您的更改没有合并到相关的 TFS 分支中，它们不会被下一个部署到开发 IIS 服务器的人覆盖？？？
你的情况好像违反了大部分常识性的版本控制实践，所以不知道会不会有VCS环境下的常识性实践的权威文章。
我不想这么说，但如果我处于你的位置，我会在别处寻找工作。

标签： version-control tfs

【解决方案1】：

我想说你似乎对这个问题理解得很好，你只需要列出这两种方法的优缺点。

挑选文件以便日后签入容易出错
您签入的版本/文件可能与 QA 测试的不匹配。理想情况下，QA 应该测试将要发布的相同代码，并使用您的版本控制系统来强制执行。
如果 QA 测试代码包含可能在同一版本中也可能不在同一版本中的其他更改，可能会导致测试通过/失败，这取决于版本中不的代码。这会使 QA 流程失效。
您所做的与大多数其他团队所做的不同（老实说，这通常比其他方面更能引起经理们的共鸣 - 至少在我作为顾问的经验中）

听起来您的团队想要实现的是拥有一组经过 QA 并且可以随时“发布”的代码。这是一个很好的目标，但通常可以通过使用适当的分支策略来实现。

一种方法是按功能进行分支（这基本上就是您现在正在尝试做的事情，只是没有版本控制系统的支持）。这意味着您对所做的每个独立更改/功能都有一个分支。 QA 针对您的功能分支进行。一旦 QA 通过，该功能分支就会合并到 MAIN（又名主干）中。

这样开发人员就有了自己的功能分支，他们可以经常签入（最佳做法是每天至少签入一次）。而且您仍然拥有仅限于已通过 QA (MAIN) 的代码的代码副本，并且始终可以发布。

如果您无法说服他们，您还可以使用本地 Git 存储库来整理您的个人更改，然后在需要签入时使用 Git-tfs 工具将它们发送到 TFS。

【讨论】：

非常感谢您的意见。前段时间我实际上正在搜索 Git-TFS 解决方案，但不知道甚至存在这样的工具。我想知道如果我将更改推送到 git 然后再推送到 TFS，它会携带一些 Git-ty 到 TFS 吗？
我知道很多人使用 Git-tfs 来启用带有 TFS 后端的本地 git 存储库。它似乎工作得很好，TFS（和其他 TFS 用户）甚至不知道您的更改来自 Git。或者，如果您使用的是 TFS 2013，您可以让 TFS 使用 Git 作为版本控制后端，那么您不需要 Git-tfs 工具作为桥梁，并且在客户端和服务器上都有 Git。