Svn 源代码管理签入内部规则走得太远？

所以，我工作的一些人试图在我们签入文件时强制执行新规则。 作为参考，我使用VS 2012、C#和TFS

目前，我们在一个项目中对x文件进行更改，然后在其全部在本地工作后，我们签入非破坏性更改，为部署做好准备。当我们一次签入x文件时，我们会对更改留下一条全面的评论

从dev部署代码的人员到staging的人员有一种推动力，即每个文件一次签入一个带有特定注释的文件，并且在我们的更改控制（我们使用jira）中，我们必须说出所有更改的.cs文件（和行号）

目前，我们在jira中说更改会影响什么，以及要推送什么.dll文件

我认为为每行/cs文件命名太过分了。此外，如果您想使用TFS回滚变更集，那么每次签入一个文件可能是一场要撤消的噩梦。 因为您最终会得到一些针对其他文件的不同版本编码的文件

但是，我不知道；不必从dev=>staging=>production进行部署，只需从local=>dev更改我自己的代码；不知道什么是困难/我在说什么

所以问题是：源代码控制的最佳实践规定了什么？

---

我错了，还是他们错了？或者最佳实践是否介于两者之间？

是。他们在杂草丛中。第一件事。。。开始找新工作吧。 下一步，努力成为变革的推动者。您是对的，变更集通常包含一个文件-实际上，将提交分解为多个变更集更容易混淆。尤其是当你想要恢复一个特性或改变时

你可能想看看crucible，它是制作JIRA的人提供的代码审查工具。如果他们想看到一些关于发生了什么以及为什么发生了变化的对话，这可能会有所帮助。我使用它并且热爱它

---

只是一个想法——你的问题可能会被搁置甚至关闭。这很主观。你可以做些什么来提出具体的技术问题都会有帮助。

妥协会有帮助吗？继续对一堆文件执行一次提交。但是，您可以在提交中记录每个文件中更改的内容，而不是“一条一般性注释”。TortoiseSVN和其他客户机甚至可以很好地自动完成提交过程中涉及的文件名。我认为行号太多了（这就是“diff”命令的作用！），但是逐文件注释是有意义的。您可以将提交消息如下所示：

Fixed bug 1234: floo was not flarbing correctly

floo.c: correct size passed into flarb function 
floo.h: add missing fleeble item in floo data struct
flarb.c: correct off-by-one error using size argument

许多工具将第一行作为更改的摘要显示，然后您可以查看完整的更改，了解以下几行的详细信息

---

一些版本控制系统（如Subversion）甚至允许设置服务器端钩子，您可以强制每个提交在提交消息中包含每个修改文件的名称，以防“他们”你担心你会忘记这样做。

我想我理解发布工程团队为什么要这么做，但不同意他们的解决方案。问题是您的流程并不是自动化的，正如您和发布团队都发现的那样。解决方案不是堆积在毫无价值的流程上，而是将现有的交付流程自动化

好的，那怎么做呢？首先，您应该开始将提交与Jira问题关联起来。这可以简单地添加PROJ-1343的提交消息（即提交正在解决的Jira问题）。希望您当前的持续集成过程能够在您每次签入时自动构建并部署到您的集成环境中，或者至少在一定的时间间隔内。这将解决构建本身的问题

现在让我们假设您已经修复了计划发布的所有未决问题。您的发布团队遇到的问题是，他们实际上是通过查看行号等来部署代码，而不是不可变的、经过测试的代码构建。您不应该将单个文件、DLL等移动/复制到环境中，因为这可能会导致您已经遇到的问题。让您的自动化软件为您处理此问题

---

当然，作为这个领域的软件开发人员，我会推荐。只需在自动化交付流程方面预先投入一点资金，就可以完全消除所有导致无数难以发现的错误的枯燥、重复的任务。然后，您可以专注于构建更好的软件，而不是向下滚动页面来记录SVN或TFS提交消息中的行号。您的发布团队也会很高兴，因为他们知道将构建部署到其他环境将始终保持一致，并且BuildMaster中还有其他功能（例如将BuildMaster版本链接到Jira版本），可以阻止部署到特定环境，除非该版本的所有问题都已解决，例如。

他们完全是疯子。每次提交都应该对应于“逻辑下一步”，这通常涉及多个文件。这是版本控制的基本最佳实践，也是Subversion设计中的一个重要部分。强制开发人员逐个提交文件意味着他们不了解版本控制。最后，风险投资只是一种工具，不应该成为阻碍。就像我说的，他们完全是疯子，你需要找一份新工作；我没有投票决定结束，而是编辑了最后一行，试图帮助它继续下去。