因此，我工作的一些人正在尝试在我们签入文件时强制执行新规则。 作为参考，我使用VS 2012，C＃和TFS。
目前我们对项目中的x文件进行了更改，然后一旦在本地工作，我们就会检查不间断的更改，为部署做好准备。当我们立刻签入x文件时，我们会对这一变化留下一个全面的评论。
从开发人员部署代码的人员推动每个文件一次一个地使用特定注释进行检查，并且在我们的更改控制中（我们使用jira）我们必须说明所有文件。我们改变的所有内容的cs文件（和行号）。
目前我们在jira中说这些更改会产生什么影响，以及要推送的.dll文件。
我认为命名每个行/ cs文件是过度的。此外，如果您希望使用TFS回滚更改集，则一次检入一个文件可能是要撤消的噩梦。 因为你最终得到了一些针对其他文件的不同版本编码的文件。
但是说，我不必从dev =＆gt;部署staging =＆gt;生产，只有我自己的代码从local =＆gt;更改开发。所以也许我不知道什么是困难的/我在说什么。
所以问题是：源控制的最佳实践有哪些要求？ 我错了，还是错了？或者介于两者之间的最佳实践？
答案 0 :(得分：1)
是。他们在杂草丛生中。首先是拳头......开始寻找新工作。 接下来，尝试成为变革的推动者。你是对的，变更集通常包含一个文件 - 它实际上使得将提交分解为多个变更集更加困惑。特别是当想要还原某个功能或更改时。
你可能想要查看坩埚，它是制作JIRA的人的代码审查工具。如果他们想看一些关于改变内容和原因的对话，那可能会有所帮助。我用它并喜欢它。
只是一个想法 - 你的问题可能会被搁置甚至关闭。这是非常主观的。您可以采取任何措施来提出具体的技术问题。
答案 1 :(得分：1)
我想我理解发布工程团队正在做他们正在做的事情的原因，但不同意他们的解决方案。问题是您的流程不是自动化的，因为您和发布团队都发现了这一点。解决方案不可以堆积在更无价值的流程上，但事实上，自动化现有的交付流程。
好的，那怎么办呢？首先，您应该开始将提交与Jira问题相关联。这可以像添加PROJ-1343的提交消息一样简单（即提交正在解决的Jira问题）。希望您当前的持续集成过程在您办理登机手续时或至少在一定时间间隔内自动构建和部署到您的集成环境。这将解决构建本身的问题。现在让我们假设您已经修复了计划发布的所有未解决问题。您发布团队遇到的问题是，他们实际上是通过查看行号而不是不可变的，经过测试的代码构建来部署代码。您应该从不将单个文件，DLL等移动/复制到环境中，因为这可能导致您遇到的确切问题。让您的自动化软件为您处理。
当然，作为这个领域的软件开发人员，我建议BuildMaster。通过在自动化交付流程方面进行一点投资，它可以完全消除导致无数，难以发现错误的所有无聊，重复性任务。然后，您可以专注于构建更好的软件，而不是向下滚动页面以记录SVN或TFS提交消息中的行号。您的发布团队也会很高兴，因为他们知道将构建部署到更多环境将始终保持一致，并且BuildMaster中还有其他功能（例如将BuildMaster版本链接到Jira版本），这些功能可能会阻止部署到某些环境，除非所有问题都发生在例如，该版本已关闭。
答案 2 :(得分：0)
是否有助于妥协？继续为一堆文件做一次提交。但是，您可以记录提交中每个文件中更改的内容，而不是“一般的全面评论”。 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）甚至允许设置服务器端钩子，您可以强制执行每个提交包含提交消息中每个修改文件的名称，以防“他们”担心您会忘了这样做。