我想我误解了一些东西，但无法找到到底是什么。我用谷歌搜索，但没有明白这个想法。有两种流行的技术——持续集成和分布式源代码控制。人们以某种方式将它们结合起来，但我不明白如何结合。
AFAIK，持续集成意味着在本地测试代码后立即提交到中央存储库（推送）。与此同时，分布式系统受到如此多的喜爱，除其他外，因为你可以在本地提交、提交、提交并使用代码，只有当你对代码足够有信心和满意时，才能将其推送给其他人。因此，虽然它不强制，但它鼓励不要急于推动。在我看来，经典的 CI 每隔几个小时推送一次的情况不会发生。
那么如何以及何时将这两件事联系在一起呢？还是我说的有错？
EDIT
我读了前三个答案。感谢您的答复。我仍然很困惑，但现在我可以更准确地提出问题。
在分布式系统中，没有那么多频繁提交的愿望，而在集中式系统中。那么，是否有任何关于在分布式系统中发布的频率以符合 CI 的指南？仍然是一天几次还是这个规则有其他版本？
分布式源代码控制和持续集成并不是相互排斥的概念。事实上他们在一起玩得很好。
尽管 DVCS 本质上是分布式的，但您仍然拥有一个代表集中式版本系统中传统“主干”的中央存储库。您不应该根据“发布”到中央存储库的时间和内容来更改您的开发模型。因为 DVCS 不会强迫您推动更改，所以您需要在这方面非常自律。
另一方面，DVCS 使开发人员能够在其私有分支上进行更小规模的增量提交。这种方式不仅更容易遵循更改，而且最终也更容易合并。在增加功能或进行实验性更改时，本地提交特别有用。或者当您需要中断功能 A 的工作来修复非常重要的错误 B 时。
各个开发人员决定何时推送/发布什么。一如既往，额外的权力伴随着额外的责任。
您应该在准备就绪时推送/发布更改。例如我想重命名一个类。这将涉及 50 多个文件，即使只有几行。我使用重构工具进行重命名。
在集中式系统中，我现在必须决定这是否真的值得单独提交，或者它是否是我当前正在进行的更大工作的一部分。根据经验，人们通常会选择第二个选项，因为你不确定是否希望它成为永久历史的一部分。
在分布式系统中，我可以在本地提交更改，我在机械（重构）和功能代码更改之间有清晰的历史记录。此刻，我不会影响其他任何人。在我最终推出更改之前，我可能会很容易地修改该决定。那么这本身就是一个干净的提交。
此示例中的问题在于以下情况：假设我在本地分支或“延迟提交”上重命名该类。与此同时，有人向主干提交了使用我刚刚重命名的类的新代码。合并我的重命名会很麻烦。
当然，您可以在执行此操作后立即发布该更改。在两个系统中。责任是一样的。但由于 DVCS 鼓励您进行更小、增量的提交，因此合并会更容易。如果您尽早发布更改，两个系统都可以为您提供相同的“退出策略”以摆脱这种情况。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
