我想我误会了一些东西，但找不到确切的东西。我用谷歌搜索，但不知道这个主意。有两种流行的技术-持续集成和分布式源代码控制。人们以某种方式将它们结合起来，但是我不知道如何结合。
AFAIK，持续集成意味着您在本地测试代码后立即提交到中央存储库(推送)。同时，除其他事项外，分布式系统备受青睐，因为您可以在本地提交并提交并提交并使用代码，然后在对代码充满信心和满意的情况下将其推送给其他人。因此，尽管它没有强制性，但是它鼓励不要急于插入。在我看来，经典的CI推送不会每隔几个小时发生一次。
那么，如何以及何时将这两件事链接在一起？还是我说错了？
编辑
我读了前三个答案。感谢您的答复。我仍然很困惑，但是现在我可以更准确地提出问题了。
在分布式系统中，不需要频繁提交，而是集中式。那么，是否有任何关于在分布式系统中发布频率以符合CI的准则？还是每天几次还是有此规则的另一个版本？
最佳答案
分布式源代码控制和持续集成并不是相互排斥的概念。实际上，他们在一起玩的很好。
即使DVCS本质上是分布式的，您仍将拥有一个中央存储库，该存储库代表在集中式版本系统中发现的传统“trunk”。您不应该根据何时以及将什么内容“发布”到中央存储库来更改开发模型。因为DVCS不会强制您进行更改，所以您在这方面需要非常有纪律。
另一方面，DVCS使开发人员可以在其私有(private)分支上进行较小的增量提交。更改不仅更容易遵循这种方式，而且在最后也更易于合并。在添加功能或进行实验性更改时，具有本地提交特别有用。或者，当您需要中断功能A的工作以修复非常重要的错误B时。
各个开发人员决定什么时候推送/发布。与往常一样，额外的权力伴随着额外的责任。
准备就绪时，您应该推送/发布更改。例如，我想重命名一个类。即使只有几行，这也将涉及50多个文件。我使用重构工具进行重命名。
在集中式系统中，我现在必须确定该值是否值得单独承担，或者它是否属于我当前正在做的较大工作中的一部分。由于经验不足，人们通常会选择第二个选项，因为您不确定是否希望将其作为永久历史的一部分。
在分布式系统中，我可以在本地提交更改，我在机械(重构)和功能代码更改之间有清晰的区分历史。在这一点上，我不影响其他任何人。在我最终提出变更之前，我可能会轻易修改该决定。那么，这将是一个干净的提交。
此示例中的问题与以下情况有关:想象一下，我在本地分支或“延迟提交”上重命名了该类。同时，有人将新代码提交到使用我刚刚重命名的类的主干。合并我的重命名将很麻烦。
当然，您可以在完成更改后立即发布该更改。在两个系统中。责任是一样的。但是由于DVCS鼓励您进行较小的增量提交，因此合并将更加容易。如果您尽早发布更改，那么两种系统都可以为您提供相同的“退出策略”。
关于version-control - 与分布式源代码控制的持续集成，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3326483/