it-swarm.cn

什么时候版本控制提交太大?

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

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

自定义传出队列
 
 Bot 
-新字段msgQueue,它只是SingleThreadExecutor 
-sendMsg阻塞,直到发送消息为止,并且在消息被发送
发送
-adminExist调用已更新(请参阅控制器)
-已移除对sendMessage 
 
 Controller 
-新字段msgWait表示消息之间等待的时间
-服务插件的启动移至reloadPlugins 
-admin由于全局管理员而从服务器移出。在通道,
服务器和全局级别
 
 Admin 
中进行检查-获得适当对象Admin 
的新方法getServer和getChannel属于
 
 BotEvent 
-toString()也显示了Extra和extra1 
 
 Channel 
-channel字段重命名为名称
-修复了通道(int)中的错字
 
服务器
-已将管理员移至控制器
 
 PluginExecutor 
-次要测试添加,将在以后删除。
 
 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/p rivate/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
修改/ t runk/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

是的.

所以有问题:

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

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

那是个问题。听起来您需要learn将您的工作分解为更小,更易于管理的块。

大型提交的问题是:

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

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

(另一种情况是您进行初始导入,但是从上面列出的问题的角度来看,这并不是问题。)

68
Stephen C

单一责任原则。

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

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

40
jammycakes

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

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

26
Kate Gregory

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

预防是根据您要完成的工作进行提交。在上面的示例中,我将在控制器逻辑之后,数据库工作之后以及脚本之后提交。不要仅仅因为yo知道发生了什么改变而推迟提交。其他人会回头看您的“已更改的东西”提交日志消息,并想知道您在吸烟。

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

10
Josh K

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

7
ysolik

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

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

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

7
azheglov

在我的领域(物理建模)中,我发现今天的输出中有一个错误,到6个月前,该错误就不在存储库中。发生这种情况时,我将对修订进行二进制搜索:

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

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

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

6
Pete

真正重要的不是提交的大小,而是更改的scope应该确定您的承诺的组织方式。

例如,您可以在大型代码库中将__macro1的每个实例更改为__macro2,这将更改200个文件。在那种情况下,200个承诺不会是理智的。

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

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

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

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

5
Tim Post

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

它不是“不做大的提交”的问题,因为do做小的提交-理想的情况是提交小的自包含更改。

从变更日志中可以很明显地看出,您有一系列可以分开(安全地)执行的操作,因此,它相当明显地表明它太大了。

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

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

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

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

4
Murph

至少要训练自己在思考时做出承诺:“到目前为止,我喜欢我的进步,如果我要进行的更改是一场灾难,我也不想失去它。”然后,您可以选择利用VCS消除尝试的任何死胡同或添加的用于跟踪问题的特殊调试代码。 (例如,使用git reset --hard 要么 rm -rf *; svn update

4
Ken Bloom

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

is,但是有一个指导原则,即在合理的范围内,较小的提交是更好的(即,提交每一行都是过多的)。

我谨记以下准则:

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

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

2
Bevan

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

从对代码库的最小连贯更改(与错误,功能等相关)的意义上讲,理想的提交应为atomic

至于使提交大小保持不变的特定技巧,这在很大程度上取决于您的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
1
Xavier T.

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

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

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

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

0
CGeorges

要回答您的问题:

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

2)通过养成习惯和规律来防止每次犯错,只要您完成某件事即可。

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

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

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

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

0
indyK1ng

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

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

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

0
Peter Eisentraut

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

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

0
user1249

有时您整天都在处理几个逻辑上不同的调试器,却忘记了在这两者之间提交代码。使用git citool有助于在一天结束时将您的工作分解成一口大小的小块,即使您白天工作时不太谨慎。

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

(似乎您使用的是Subversion。我不知道针对Subversion执行此操作的工具,但是您可以考虑使用git-svn,用于git的Subversion适配器,它将改变您的生活。)

0
Ken Bloom

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

0
Nickz