什么时候版本控制提交太大？[关闭]

我曾在多个地方听到过“不要做大的提交”，但我从未真正理解过什么是“大的”提交。如果您处理一堆文件（即使有关联），它会很大吗？您应该一次处理多少个项目？

对我来说，我很难做出“小的承诺”，因为我忘记或创建了会创建其他东西的东西。然后，您将得到如下内容：

制作自定义传出队列

机器人
-新字段msgQueue，无非就是SingleThreadExecutor
-sendMsg阻止直到发送消息为止，并在消息获取之间添加等待时间
已发送
-adminExist调用已更新（请参阅控制器）
-删除被调用方的sendMessage

控制者
-新字段msgWait表示消息之间等待的时间
-开始将服务插件移至reloadPlugins
-adminExists由于全局管理员而从服务器移出。检查频道
服务器和全局级别

管理员
-获取适当对象Admin的新方法getServer和getChannel
属于

BotEvent
-toString（）还显示了extra和extra1

渠道
-channel字段重命名为name
-修正频道（int）中的错字

服务器
-将adminExists存在到控制器中

插件执行器
-增加了次要测试，稍后将删除

JS插件
-更新为框架变更
-用Controller.instance替换InstanceTracker.getController（）
-VLC现在在自己的文件中交谈

各种NB项目更新和更改

---

受影响的文件
修改/trunk/Quackbot-Core/dist/Quackbot-Core.jar
修改/trunk/Quackbot-Core/dist/README.TXT
修改/trunk/Quackbot-Core/nbproject/private/private.properties
修改/trunk/Quackbot-Core/nbproject/private/private.xml
修改/trunk/Quackbot-Core/src/Quackbot/Bot.java
修改/trunk/Quackbot-Core/src/Quackbot/Controller.java
修改/trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
修改/trunk/Quackbot-Core/src/Quackbot/info/Admin.java
修改/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
修改/trunk/Quackbot-Core/src/Quackbot/info/Channel.java
修改/trunk/Quackbot-Core/src/Quackbot/info/Server.java
修改/trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
修改/trunk/Quackbot-GUI/dist/README.TXT
修改/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
修改/trunk/Quackbot-GUI/nbproject/private/private.properties
修改/trunk/Quackbot-GUI/nbproject/private/private.xml
修改/trunk/Quackbot-GUI/src/Quackbot/GUI.java
修改/trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
删除/trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
修改/trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
修改/trunk/Quackbot-Impl/dist/README.TXT
修改/trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
修改/trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
修改/trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
修改/trunk/Quackbot-Impl/lib/javarebel.stats
添加/trunk/Quackbot-Impl/lib/jrebel.info
修改/trunk/Quackbot-Impl/nbproject/private/private.properties
修改/trunk/Quackbot-Impl/nbproject/private/private.xml
修改/trunk/Quackbot-Impl/nbproject/project.properties
修改/trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
添加/ trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
修改/trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
修改/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
修改/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
修改/trunk/Quackbot-Impl/plugins/listeners/onJoin.js
修改/trunk/Quackbot-Impl/plugins/listeners/onQuit.js
修改/trunk/Quackbot-Impl/plugins/testCase.js
添加/trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
修改/trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
添加/ trunk / Quackbot-Impl / vlc_http
添加/trunk/Quackbot-Impl/vlc_http/current.html
修改/trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
修改/trunk/Quackbot-Plugins/dist/README.TXT
修改/trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
修改/trunk/Quackbot-Plugins/nbproject/private/private.properties
修改/trunk/Quackbot-Plugins/nbproject/private/private.xml
修改/trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
添加/ trunk / Quackbot-Plugins / vlc_http
添加/trunk/global-lib/jrebel.jar

是的

所以有问题：

• 当提交变得太大（非显而易见的东西）时，有哪些因素呢？
• 您如何防止此类提交？请具体说明
• 当您处于发展的半早期阶段且事情发展很快时，情况又如何呢？巨大的提交还可以吗？

对我来说，我很难做出“小的承诺”，因为我忘记或创建了会创建其他东西的东西。

那是个问题。听起来您需要学习将工作分解为更小，更易于管理的部分。

大型提交的问题是：

• 在多人项目中，您提交的机会会给其他开发人员解决冲突带来更大的机会。
• 很难准确描述日志消息中已执行的操作。
• 跟踪更改的顺序并因此了解问题的原因更加困难。
• 它增加了丢失大量未完成工作的可能性。

有时，不可避免的是大型提交；例如，如果您必须更改主要的API。但这不是通常的情况。而且，如果您确实处于这种情况下，那么创建一个分支并在其中进行工作可能是个好主意……使用许多小的提交……并在完成后重新集成。

（另一种情况是您进行初始导入，但是从上面列出的问题来看，这没有问题。）

单一责任原则。

每次源代码控制提交都只能用于一个目的。如果必须在摘要中加上“和”或“也”一词，则需要将其拆分。

在工作副本中最终会有很多单独的不相关或半相关的更改，这是很常见的。这被称为“纠结的工作副本问题”，实际上，即使对于有纪律的开发人员来说，也很难避免。但是，Git和Mercurial都为您提供了解决问题的工具-git add -p或块选择以及TortoiseHg中的Mercurial队列。

想象一下，客户要求进行特定的更改-例如，添加一条规则，规定在“无论如何”日期的两天内都不能进行某些操作。然后，在您进行更改后，他们会改变主意。您将需要回滚您的提交。如果所有这些都与改变无关报表的排序有关，那么您的生活就很痛苦。

一个工作项，一个变更集。来自客户端的一个请求，一个变更集。您可能会改变主意的一件事，就是变更集。有时，这意味着它只是一行代码。有时它是十个不同的文件，包括数据库架构。没关系。

大型提交是指您拥有大量更改，而这些更改实际上并不是全部都归于同一类。如果更改控制器逻辑，则更改数据库连接模型，然后进行其他操作。脚本，我不应该一次提交就捆绑所有内容。

预防是根据您要完成的工作进行提交。在上面的示例中，我将在控制器逻辑之后，数据库工作之后以及脚本之后提交。不要推迟仅仅保证，因为你知道是什么改变了。其他人将回顾您的“已更改内容”提交日志消息，并想知道您在吸烟。

初始导入可能是您应有的最大承诺。从头开始建立系统？当然有一些重大承诺。逐步整理之后，是时候让事情井井有条了。

如果您知道您将要事先处理大量代码，则建议您为特定功能创建一个分支，同时定期从主线中提取代码以确保代码保持同步。在分支上完成工作后，将所有更改合并回主线。这样，其他团队成员在看到巨大的承诺时就不会感到惊讶和/或烦恼。此外，发生问题的机会也更少。继续练习将事情分解成较小的提交。随着时间的流逝，它将成为第二天性。

此示例显示了一个太大的提交。

根据经验，描述一个句子或一行文本的变化。（基于此规则，应将提交分成10-15个较小的提交。）如果您不能在一行中充分注释一个提交，则该提交已经太大。

要练习较小的提交，请在记事本（或记事本）中记下已更改或添加的内容。在变长列表之前或在更改代码之前与记事本中已有的内容无关，请提交。

在我的领域（物理建模）中，我发现今天的输出中有一个错误，该错误到6个月前还没有出现在存储库中。发生这种情况时，我将对修订进行二进制搜索：

1. 从3个月前开始运行模型
2. 如果仍然存在错误，请从4.5个月前运行模型
3. ...重复直到找到导致输出错误的提交为止

当在一个巨大的提交中引入该错误时，我必须坐在细齿的梳子上才能找到问题的根源。如果提交只涉及少量文件，那么查找导致问题的代码行就不会那么麻烦。

我建议将您的问题分解为一系列较小的任务（最好将每个任务放在错误跟踪器中）。在完成每个任务时进行提交（并在错误跟踪器中关闭该错误/功能）。

真正重要的不是提交的大小，而是更改的范围决定了您的承诺的组织方式。

例如，您可能__macro1需要__macro2在大型代码库中将的每个实例更改为，从而更改了200个文件。在那种情况下，200个承诺不会是理智的。

您最终想要获得的是能够在任何单个修订版本中提取存储库并进行构建。您从更改libfoo为libbar吗？我希望更改包括更新您的构建脚本和Makefile（或任何适用的内容）。

有时，您可能需要进行一系列实验性更改以完成某件事，在这种情况下，如果以后需要还原，则必须确定哪个范围对您更重要。一个依赖另一个吗？一次提交一次即可全部提交。否则，在这种情况下，我建议每次更改提交一次。无论如何，您应该在另一个分支或另一个仓库中执行类似的操作。

是的，您确实可以将单个文件还原到以前的版本（因此可以从更大的承诺中备份一个文件），这样做确实会在以后的工作中弄糟诸如二等分等工具，并污染了历史记录。

如果您停下来并认为“好，测试通过了，我认为这是可行的..但是，如果它变坏了，我可以轻易地将其退出吗？” ..您最终会做出明智的承诺。

这里要理解的是，在这种情况下，“大”是关于数量的不同变化，而不是提交的物理大小（尽管通常两者是并行的）。

与其说“不做大的提交”，不如说做小小的提交，这不是一个问题-理想的情况是提交小的自包含更改。

从变更日志中可以很明显地看出，您有一系列可以分开（安全地）执行的操作，因此，它本身就可以证明它太大了。

之所以会出现问题，是因为您的上一次提交是您当前所做更改的参考点，例如，如果您弄错了第一位，然后又弄错了另一条，您将很难将您的工作退回到开始犯错误的地步（BTDTGTTS）。

当然，有时更改只是很大的-大规模重构-就像其他人所建议的那样，这是您需要分支的地方，尽管您的个人提交可能会从概念上破坏将它们与主要开发主干分开的东西，但这并不是问题，您就可以继续尽早并经常做出承诺。

还有一件事情-如果在工作中出现需要立即引起注意的事情，则需要单独更改（最好是在一组完全不同的文件夹中）并分别提交。

所有这一切的真正挑战不是机制和思维定式-提交不仅是您时不时制作的备份副本，而且每次提交都是一寸鹅卵石，而且很多都没有错小提交的问题，而在一次暴民的提交过程中一起纠缠不同的事物，就像在一大堆代码中一起纠缠一些模糊不清的功能一样糟糕。

至少，要训练自己在每当对自己进行思考时就做出承诺：“到目前为止，我喜欢我的进步，如果我要进行的更改是一场灾难，我也不想失去它。” 然后，您可以选择利用VCS消除尝试的任何死胡同或添加的专用调试代码来查找问题。（例如，用git reset --hard或rm -rf *; svn update）

没有硬性规定，没有分界线，超过该分界线您的承诺太大。

这里是不过一个准则较小提交更好的，合理的范围内（即犯每一道线条都是probaby过度）。

我谨记以下准则：

• 一次提交应仅包含一个错误修复的更改
• 一次提交不应包含超过半天的工作
• 一次提交不应破坏构建

当然-这些是我要记住的-YMMV。不同的开发人员支持不同级别的粒度。

提交越小，就越容易准确地找到潜在回归的来源。

从对代码库的最小一致更改（与错误，功能等相关）的意义上讲，理想的提交应该是原子的。

至于使提交大小保持不变的特定技巧，这在很大程度上取决于您的VCS及其设置方式：您必须能够在本地提交或在服务器上自己的分支中工作。

关键是每次进行原子更改时都要提交到“私有”分支，然后可以定期合并分支，例如每周合并一次。

使用dvcs，您的工作流程可能如下所示：

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

使用集中式vcs：

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

您可能已经听说过这样的说法，那就是完美无暇。那也应该描述您的提交大小标准。

这取决于“完美”大小的位置。如果要运送给外部客户，那么如果您没有按时完成下一个，那么合适的尺寸可能是最小的增量。如果您要构建内部的，频繁部署的应用程序，则最佳大小可能是不会破坏任何内容的最小增量（并使您更接近想要的位置）。

现代化的版本控制系统可通过轻松的分支，交互式变基，登台区域等帮助您创建良好的提交。

提交消息只能是一行（对于git max 60个字符）。提交的代码量必须足够小，以使描述性消息保持在该限制之内。

我倾向于每次都提交（甚至更多，所以现在我们切换到git），我已经完成了一大块，因为它可以捕获以这种方式完成的“为什么”事情。

有时您整天都在处理几个逻辑上不同的调试器，却忘记了在这两个调试器之间提交代码。使用git citool一天结束时，即使您在工作中不是很注意，使用它也可以将您的工作分解成一口大小的小块。

git citool 可以让您选择要在一个特定的提交中提交文件的哪些特定块（或哪些特定的行），因此您可以将对同一文件所做的更改分解（不重叠）为多个提交。

（似乎您在使用Subversion。我不知道针对Subversion执行此操作的工具，但您可以考虑使用git-svngit的Subversion适配器，这会改变您的生活。）

提交的金额越大，您越有可能破坏构建并获得团队其他成员的报酬。我每天尝试两次提交更改。就在午餐前和我回家之前。因此，在下午12点和下午4:30，我尝试使一切正常工作并准备提交。我发现这种做法对我有用。

要回答您的问题：

1）对我来说，如果标准承诺要做的不只是一件事情，那就算是大项目了。我所说的是修复错误或添加功能。

2）通过养成习惯和规律，在完成某件事时就提交来防止此类提交。

3）在开发的半早期阶段，我允许提交包含第一次创建的文件，这些文件将在以后使用。

我想指出的是，我的意思是，您可以识别的所有错误均已修复，并且您不会通过提交来破坏构建。

是的，这会产生大量的提交，但是它使您可以准确地回滚破坏的内容，而不必回滚仅在其中一个更改引起问题的同时提交的大量更改。

我还想指出，规则对于Mercurial和Git等分布式版本控制系统（DVCS）有所改变。如果您使用的是其中一种，则只要进行了更改即可提交，但尚未进行测试，然后在工作时将其推送到中央存储库。这是可取的，因为它使您可以修改代码的更多更改，而不必担心破坏构建。

就我而言，我试图将服务器的文件提交到存储库系统（SVN）。这是初始提交，因此不想下载它，因为这是一个非常大的项目（几GB），我想在客户端服务器上进行初始提交。

问题是客户端在共享服务器上，如果svn客户端运行超过一分钟，则该svn客户端将被杀死（或任何其他软件）。

一种选择是将项目下载到我的计算机上，然后从那里进行初始提交，但是我很想知道SVN中是否可以将大提交分成更多选项，类似于事务处理方法。

在我之前的开发人员从未使用过版本控制系统。

我工作的公司会为每次提交强制进行同行代码审查。因此，任何使同伴难以在合理的时间内弄清正在发生的事情并进行审查的提交都太大了。