与分布式源代码控制持续集成

Question

我想我误解了一些东西却找不到确切的东西.我用Google搜索,但没有得到这个想法.有两种流行的技术 - 持续集成和分布式源代码控制.人们以某种​​方式将它们结合起来,但我不明白如何.

AFAIK,持续集成意味着一旦您在本地测试代码,就会提交到中央存储库(推送).与此同时,分布式系统非常受欢迎,因为您可以在本地提交和提交并提交代码并使用代码,只有在您对其充满信心和满意时才将其推送给其他代码.因此,虽然它没有强制,但它鼓励不要急于推动.在我看来,每隔几个小时就不会发生CI推送的经典之作.

那么你如何以及何时将这两件事联系起来呢？或者我说的错了吗？

编辑

我读了前三个答案.感谢您的答复.我仍然感到困惑,但现在我可以更准确地提出这个问题了.

在分布式系统中,没有那么多频繁提交的愿望,然后是集中式的.那么有关于在分布式系统中发布以符合CI的频率的指南吗？它仍然是一天几次还是这个规则的另一个版本？

Answer 1

分布式源代码控制和持续集成并不是相互排斥的概念。事实上他们在一起玩得很好。

尽管 DVCS 本质上是分布式的，但您仍然拥有一个代表集中式版本系统中传统“主干”的中央存储库。您不应该根据“发布”到中央存储库的时间和内容来更改您的开发模型。因为 DVCS 不会强迫您推动更改，所以您需要在这方面非常自律。

另一方面，DVCS 使开发人员能够在其私有分支上进行更小规模的增量提交。这种方式不仅更容易遵循更改，而且最终也更容易合并。在增加功能或进行实验性更改时，本地提交特别有用。或者当您需要中断功能 A 的工作来修复非常重要的错误 B 时。

各个开发人员决定何时推送/发布什么。一如既往，额外的权力伴随着额外的责任。

您应该在准备就绪时推送/发布更改。例如我想重命名一个类。这将涉及 50 多个文件，即使只有几行。我使用重构工具进行重命名。

在集中式系统中，我现在必须决定这是否真的值得单独提交，或者它是否是我当前正在进行的更大工作的一部分。根据经验，人们通常会选择第二个选项，因为你不确定是否希望它成为永久历史的一部分。

在分布式系统中，我可以在本地提交更改，我在机械（重构）和功能代码更改之间有清晰的历史记录。此刻，我不会影响其他任何人。在我最终推出更改之前，我可能会很容易地修改该决定。那么这本身就是一个干净的提交。

此示例中的问题在于以下情况：假设我在本地分支或“延迟提交”上重命名该类。与此同时，有人向主干提交了使用我刚刚重命名的类的新代码。合并我的重命名会很麻烦。

当然，您可以在执行此操作后立即发布该更改。在两个系统中。责任是一样的。但由于 DVCS 鼓励您进行更小、增量的提交，因此合并会更容易。如果您尽早发布更改，两个系统都可以为您提供相同的“退出策略”以摆脱这种情况。