与分布式源代码控制的持续集成 [英] Continuous integration with distributed source code control
问题描述
我想我误解了一些东西，但找不到确切的。我googled，但没有得到的想法。有两种流行的技术 - 连续集成和分布式源代码控制。人们以某种方式结合它们，但我不明白如何。
AFAIK，持续集成意味着在测试代码后立即提交到中央存储库本地。同时，分布式系统非常喜欢这样的东西，除了别的以外，因为你可以提交和提交和提交本地和播放代码，并推送到其他人只有当你有信心和满意。所以，虽然它不强迫，但是，它鼓励不要急于推。在我看来，经典的CI推送每隔几个小时不会发生。
那么，你怎么和什么时候把这两个东西联系在一起？
我读了前三个答案。谢谢你的回应。我仍然困惑，但现在我可以提出更准确的问题。
在分布式系统中，没有那么多的频繁提交的愿望，然后在集中。那么有什么指导方针在分布式系统中发布频率以符合CI？是否每天还有几次，还是有其他版本的此规则？
分布式源代码控制和连续集成互斥概念。事实上，他们在一起玩得很好。
即使DVCS的性质是分布式的，您仍然会有一个中央存储库，代表集中式版本系统中的传统中继。您不应该根据何时和什么更改发布到中央存储库来更改开发模型。因为DVCS不强迫你推送你的更改，你需要在这方面非常严格。
另一方面，DVCS使开发人员能够做更小的增量提交在他们的私人分支。不仅变化更容易遵循这种方式，他们也更容易在最后合并。在添加特征或进行实验性更改时，具有本地提交特别有用。或者当您需要中断您的功能A的工作以修复非常重要的错误B.
个人开发人员决定推送/发布什么。与往常一样，额外的权力带来额外的责任。
您应该在准备好时推送/发布更改。例如我想重命名一个类。这将触摸50多个文件，即使只有几行。我使用重构工具重命名。
在集中式系统中，我现在必须决定它是否真的值得一个提交自己，或者如果它是一个我目前正在开展的更大的工作。根据经验，人们通常会选择第二个选项，因为您不确定是否要将其作为永久历史记录的一部分。
在分布式系统中，在本地提交更改，我有一个明确的历史分离机械（重构）和功能代码更改之间。在这一点上，我不影响任何人。我可能很容易修改该决定以后，我最终推出我的更改。
此示例中的问题是出现以下情况：想象一下，我重命名了本地分支上的类或我的deferred承诺。同时有人提交新的代码到trunk，使用我刚重命名的类。这将是一个麻烦，合并我的重命名。
当然，你可以刚刚发布改变你做它的那一刻。在两个系统。责任是一样的。但由于DVCS鼓励你有更小的增量提交，合并将更容易。如果您早点发布了更改，两个系统都可以为您提供相同的退出策略。
I think I misunderstand something but can’t find what exactly. I googled, but didn't get the idea. There are two popular techniques – continuous integration and distributed source code control. People somehow combine them, but I don’t understand how.
AFAIK, continuous integration means commit to the central repository (push) as soon as you’ve tested your code locally. At the same time, distributed systems are loved so much, among other things, because you can commit and commit and commit locally and play with the code and push it to the others only when you are confident and satisfied enough with it. So, though it doesn’t force, it, however, encourages not to hurry with push. It seems to me that classic for CI push every several hours won’t take place.
So how and when do you link these two things together? Or am I wrong in what I said?
EDIT
I read the first three answers. Thank you for the response. I'm still confused, but now I can formulate the question more accurate.
In distributed systems there is not so much of desire of frequent commits, then in centralized. So are there any guidelines on how often to publish in distributed systems to comply with CI? Is it still several times a day or is there another version of this rule?
Distributed Source Control and Continous Integration aren't mutually exclusive concepts. In fact they play very well together.
Even though DVCS are by their nature distributed, you will still have a central repository that represents the traditional "trunk" found in centralized version systems. You should not change your development model in terms of when and what changes you "publish" to your central repository. Because DVCS don't force you to push your changes you need to be very disciplined in that regard.
On the other hand, DVCS enables developers to do smaller, incremental commits on their private branches. Not only are changes easier to follow this way, they are also easier to merge at the end. Having local commits is especially useful when spiking a feature or doing experimental changes. Or when you need to interrupt your work on feature A to fix the very important bug B.
The individual developer decides what get's pushed/published when. As always, with additional power comes additional responsibility.
You should push/publish changes whenever they are ready. For example I want to rename a class. This will touch 50+ files, even though just a few lines. I do the rename using a refactoring tool.
In a centralized system I would now have to decide if that is actually worth a commit on its own or if it's part of a larger piece of work I'm currently working on. Out of experience, people usually choose the second option, because you're not sure if you want that to be part of permanent history yet.
In a distributed system I can commit the change locally, I have a clear history seperating between mechanical (refactoring) and functional code changes. At this point, I don't affect anyone else. I might easily revise that decission later before I finally push out my changes. This will be a clean commit on its own then.
The problem in this example is with the following situation: Imagine I rename that class on my local branch or my "deferred commit". In the meantime someone commits new code to trunk that uses the class I just renamed. It will be a hassle to merge my rename.
Sure you could've just published that change the moment you did it. In both Systems. The responsibility is just the same. But since the DVCS encourages you to have smaller, incremental commits, merging will be easier. Both Systems could've provided you with the same "exit strategy" out of that situation if you published your changes early.
这篇关于与分布式源代码控制的持续集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
