有时，当我们检查软件的提交历史时，我们可能会发现确实有一些提交是非常大的-它们可能会更改10或20个文件，其中包含数百个更改的源代码行（增量）。我记得有一个用于BIG提交的常用术语，但是我不记得确切的含义。谁能帮我？程序员通常用来指代这种BIG和巨型提交的术语是什么？

顺便说一句，一起做出很多更改是一种好的做法吗？

更新：谢谢你们的启发性讨论！但是我认为“代码炸弹”是我想要的术语。

（1）Ben Collins-Sussman：“ ...”“ 代码炸弹 ”。也就是说，当有人出现一个具有巨大新功能，花了几个月时间编写的开源项目时，您该怎么办？谁有时间去审查数千行代码？...”

（2）Dan Fabulich：“代码炸弹，或者：有新主意的新手…… 代码炸弹是一个很大的补丁，没有人可以审查。”

（3）Google的“代码之夏”指南：“提早提交，请经常提交...请不要整日工作，然后将所有内容都放入一个代码弹中。相反，每次提交都应独立完成一项任务应该在日志消息中进行总结。”

（4）杰夫·阿特伍德（Jeff Atwood）：“代码炸弹……法则30：不要黑夜 ……”

我们可能称其为错误提交。:)

不良做法

是的，这通常被认为是不良做法，因为它具有以下负面影响：

• 使其难以审核，
• 使得难以轻松，快速地掌握提交的初衷，
• 使得它很难看到它是如何影响的代码来显式修复或解决的问题，
• 使得很难知道提交的大小是否是由于其他可能无关的更改（例如少量清理或其他任务）的噪音所引起的。

可接受的情况

但是，在某些情况下，大型提交是完全可以接受的。例如：

• 跨分支合并时，
• 当从另一个非版本化的代码库添加新源时，
• 当就地更换大量的功能（虽然你倒是应该这样做的一个分支，具有较小提交应对变化的不同部分，然后合并整个事情回来，这样你就可以的增量发展有更好的窗口功能以及在此过程中可能遇到的问题），
• 重构影响许多后代和使用者类的API时。

因此，在任何可能的情况下，都建议使用“外科手术”类型的提交（并将它们链接到问题跟踪器中的任务ID！）。如果您有正当的理由，请继续。

除此之外，我实际上不知道也不认为我听说过大型提交的特殊名称。怪物承诺？胖子吗？

更新： David Cary的答案使用术语“代码炸弹”（最重要的是Subversion的原始创建者Collins-Sussman ）链接到著名的IT参与者。这样（尽管到目前为止我还不能说我经常听到）。

顺便说一句，一起做出很多更改是一种好的做法吗？

好吧，长期坚持更改，实施各种功能和错误修复，然后提交它们，这不是一个好习惯，这是可能发生的大型提交的一种方式。

发生这种情况的另一种方式是，如果重构更改了广泛使用的功能的签名，那么所有这些功能都必须更改。这并不一定很糟糕，我也不希望开发人员避免担心超出一些阈值而清理代码。

因此，除了查看提交中涉及的文件数量以外，还有更多的功能。

我听说过的术语是“矮胖的签到”。我不是他们的粉丝。我喜欢较小的提交，这些提交可以确保在项目的合理步骤中不会破坏其他任何内容。通常，重大承诺充满了从发生之时回响一段时间的问题。

我称其为“典型的SVN提交”或“明天是发布日提交”

尽管我非常喜欢SVN，但是我无法执行本地提交，这让我感到非常惊讶。

编辑：在提交消息中，它们通常具有单词“ stuff”和“ beer”。

再次编辑：进行许多更改，虽然不一定是不好的作法，但应尽可能避免。我发现审查简明扼要的修订/提交更容易。（与编写良好的提交消息配对，有关错误示例，请参见我之前的编辑）

一个“热腾腾的代码块”。:-)

• 初始提交 -不受版本控制的项目被抛出到SVN中
• 重构 -架构师对于将类名从/更改为蓝精灵命名约定或更改包层次结构的根有一个绝妙的主意
• 代码格式 -架构师已决定将代码缩进从4个空格更改为3个空格，或将行尾从Unix更改为Windows（或还原）
• 星期五提交 -乔总是在星期五的16:30 投入整周的工作
• uuups commit -Ted错误地删除了根目录，将其提交，现在他再次将整个文件层次结构泵入SVN

通常，许多人倾向于使用集中式VCS进行大型提交，尤其是服务器强制执行良好的提交策略。那就是提交必须通过所有测试，并且测试花费更长的时间（超过几秒钟）。因此，开发人员不想等待这么长时间来提交多次并将更改分解为多个小的提交。

对VCS持绿色态度的开发人员可能会忘记将更改分解为多个小提交。他们只记得在将程序发布给质量检查团队时才提交。更糟糕的是，为了避免其他人看到错误的代码，他们在成功通过质量检查之前不会提交错误代码。最后，他们没有意识到他们已经提交了输出二进制文件，临时文件和链接器输出，它们确实产生了“大”提交。