Answers:
在这种情况下，我喜欢将编码视为攀岩。你爬了一点，然后在岩石上放了一个锚。如果您曾经跌倒，那么您所下的最后一个锚点就是保护您安全的点，因此您跌落的高度永远不会超过几米。与源代码控制相同；您编写了一些代码，当您达到某个稳定的位置时，便提交了一个修订。如果您曾经惨败，您可以随时回到上一个修订版，并且知道它是稳定的。
就是说，如果您在团队中工作，通常要确保所做的任何事情都是完整的，有意义的，干净的构建且不会破坏任何其他人的东西。如果您需要进行较大的更改而可能会干扰其他人的工作，请创建一个分支，以便在不干扰其他任何人的情况下进行提交。
它还取决于您使用的SCM系统。分布式系统通常使合并和分叉变得轻而易举，并且您可以在本地进行提交。这意味着您应该付出很多，并在完成大量工作后进行推送/合并。使用svn或cvs等集中式系统，提交的成本更高，并且会影响到每个人。分支可以部分解决此问题，但是由于它发生在服务器上，因此可能会非常缓慢，并且合并可能很麻烦。因此，对于集中式SCM，通常会有一种更加谨慎的文化，您只有在完成大量工作后才进行提交。
至于附加组件：请不要这样做。代码行，提交次数，发现/解决的错误数等等，都是对质量甚至数量的非常糟糕的衡量。
git rebase -i）。
如果您使用的是诸如Mercurial或Git之类的DVCS，则在完成大量工作后就应该提交到本地存储库。但是，只有在它已经过测试，自包含的更改工作之后，才将其推送到共享存储库。
对于非分布式VCS（例如SVN），应用相同的逻辑，而不是使用本地存储库，而是使用私有分支，而不是推送-合并到主分支。
您应该尽早且经常这样做。
我知道有人每隔90秒就会做出一次承诺。说真的 它似乎为他们工作。我已经尝试过每次保存文件时提交一次，这可能会超过90秒。今天，我大概每15分钟提交一次。一个VCS允许您将多个提交压缩为一个，并允许本地提交（例如git）使此操作变得容易得多。
您应该多久提交一次？很难说，但可能比现在更多。保持越来越频繁的提交，找到一个感觉太荒谬的观点，然后退后一步。您可能会得到一些合理的东西。
您可以根据交付给用户的价值来衡量产品的发展。没有其他准确的测量方法。
提交是任何版本控制的数据/代码的构建块。每次提交应严格执行以下操作之一：
同样，在分支机构中工作时，提交必须转到更合适的分支机构。两个提交不应具有相同的提交消息（暗示相似的更改），但应位于不同的分支中，因为这会使协作者感到困惑。更好的方法是提交到主分支并合并到功能分支。
如果提交者遵循上述规则，则对以下情况将变得微不足道：
关于基于提交来衡量项目的进度，有可能不考虑重构提交和错误修复提交。
仅在成功对给定的功能/模块/功能进行单元测试并合理保证已准备好进行集成或系统测试时，才提交。
并回答您的附加问题-不！项目所在位置的度量永远不应由提交的数量决定...谁知道实际提交了什么？它是否已成功通过系统测试或什至是单元测试。仅因为已提交-并不意味着已准备好生产。
当代码准备好与代码的其他用户共享时（即相对稳定，安全且经过适当测试的情况下），请提交一次提交。
不，我认为提交不是衡量项目开发的重要指标，因为我知道有些开发人员会提交所有微小的更改，而另一些开发人员只会对功能进行重大更改。您如何定量地衡量一项承诺对另一项承诺的价值？
进行所有您认为不会破坏某些事情的重大更改。您唯一不应提交的是样式更改，因为它们没有体现逻辑更改。但是否则，所做的更改越小越好。
提交次数越少，您可以记录思考过程的详细信息越多，这是好的提交日志的一个方面。良好的代码审查不仅应涉及代码结果，还应涉及思考过程。
另外，进行许多小的提交操作很容易将对象一分为二，而版本控制的使用功能却很少使用，这使我节省了很多时间来寻找大海捞针代码库中的针头错误。
简而言之 在当前代码库中发现问题。然后，在更改日志中选择一个提交，以确保特定问题不存在。首先检查出介于“良好”和“不良”版本之间的提交权。测试以查看问题是否仍然存在。如果是这样，则需要往后看，在“良好”和先前测试的提交中间。如果问题不存在，则是在此特定更改之后引入的，因此您需要检查介于“不良”和先前测试的提交之间的中间部分。重复。最终，您将得到导致问题的提交。但是只有当您提交的内容很少时，否则您才知道问题发生在哪些重大更改中。
这是它与Git一起工作的方式，但是原理适用于任何版本控制。