一个大签到几个小签到？

Question

昨天当我查看最新版本的内部工具时，我看到了大约30多个新版本。这让我很好奇，因为我认为有人最终修复了那些烦人的错误，并添加了我等待了这么长时间的功能......猜猜怎么着？这一切都没有发生，有人只是认为更新一些标题并对两个或三个函数进行微调是很好的。一切都在单独的提交中。大。

这引起了我们团队的讨论 - 如果这被认为是好的，还是我们应该禁止这种“滥用”？可以说这真的可以适合一两个提交，但30似乎很多。应如何处理 - 最佳做法是什么？

Answer 1

你应该在任何时候做出改变，并且即将进入下一个。

您不应提交阻止项目建设的任何内容。

您应该填写提交消息，以便人们知道已经做了哪些更改。

这对我有用..除非我在提交消息中看到它，否则我不会假设已经完成了某些事情......

Answer 2

通常我认为提交应该涉及一个逻辑任务，例如修复bug＃103或添加新的打印功能。这可以是一个或多个文件，这样您就可以看到为特定任务所做的所有更改。如有必要，还可以更轻松地回滚更改。

如果逐个检查每个文件，则很难看到对特定更新/任务所做的更改。

此外，如果在一次提交中完成了多个任务，则很难看到哪些更改属于哪个任务。

Answer 3

我不关心提交的数量，因为每次提交都会保持项目的一致性（构建仍然会成功）。这是一些不应该打扰你的内部计数。如果你想在这里改变一些东西，最好告诉人们使用一些结构化的提交消息（如“[bugfix] ......”，“[feature] ...”，“[minorfix]”）。

顺便说一下，如果你想知道错误是否已经修复或者是否添加了功能，使用错误跟踪系统比检查类似SVN的工具中的提交要好得多。

Answer 4

与代码熵的斗争是一项持续的团队努力。应该鼓励那些只是“修复破窗”的小型签到，而不是不赞成。源存储库是用于跟踪错误修正的错误工具 - 这就是错误跟踪器的用途 - 因此在扫描代码存储库而不是错误存储库时找到修复的不便对我来说似乎完全可以忽略不计。

我在大型代码库（~1M LOC）上使用巨大的历史记录（~20Y）在一个中等规模的团队中工作。很多代码都是一堆乱七八糟的烂分支逻辑，不推荐使用的API，命名约定，甚至随机缩进都经常使它成为一个阅读的痛苦。我开始养成一种轻微的“偷车式”可读性改进的习惯，试图对抗完整的代码腐烂，并努力让队友采用相同的习惯。

除非你的情况完全不同，否则我会尝试对任何此类举措表示赞赏。替代方案（我对所有人都很熟悉）是可怕的停滞，它会使任何代码腐烂。