与分布式源代码控制的持续集成
我想我误解了一些东西，但无法找到到底是什么。我用谷歌搜索，但没有明白这个想法。有两种流行的技术——持续集成和分布式源代码控制。人们以某种方式将它们结合起来，但我不明白如何结合。
AFAIK，持续集成意味着在本地测试代码后立即提交到中央存储库（推送）。与此同时，分布式系统受到如此多的喜爱，除其他外，因为你可以在本地提交、提交、提交并使用代码，只有当你对代码足够自信和满意时，才能将其推送给其他人。因此，虽然它不强制，但它鼓励不要急于推动。在我看来，经典的 CI 每隔几个小时推送一次的情况不会发生。
那么如何以及何时将这两件事联系在一起呢？还是我说的有错？
编辑
我阅读了前三个答案。谢谢您的回复。我仍然很困惑，但现在我可以更准确地提出问题。
在分布式系统中，没有那么多频繁提交的愿望，而在集中式系统中。那么，是否有任何关于在分布式系统中发布的频率以符合 CI 的指南？仍然是一天几次还是这个规则有其他版本？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
分布式源代码控制和持续集成并不是相互排斥的概念。事实上他们在一起玩得很好。
尽管 DVCS 本质上是分布式的，但您仍然拥有一个代表集中式版本系统中传统“主干”的中央存储库。您不应该根据“发布”到中央存储库的时间和内容来更改您的开发模型。因为 DVCS 不会强迫您推动更改，所以您需要在这方面非常自律。
另一方面，DVCS 使开发人员能够在其私有分支上进行更小规模的增量提交。这种方式不仅更容易遵循更改，而且最终也更容易合并。在增加功能或进行实验性更改时，本地提交特别有用。或者当您需要中断功能 A 的工作以修复非常重要的错误 B 时。
各个开发人员决定何时推送/发布什么。一如既往，额外的权力伴随着额外的责任。
您应该在准备就绪时推送/发布更改。例如我想重命名一个类。这将涉及 50 多个文件，即使只有几行。我使用重构工具进行重命名。
在集中式系统中，我现在必须决定这是否真的值得单独提交，或者它是否是我当前正在进行的更大工作的一部分。根据经验，人们通常会选择第二个选项，因为你不确定是否希望它成为永久历史的一部分。
在分布式系统中，我可以在本地提交更改，我在机械（重构）和功能代码更改之间有清晰的历史记录。此刻，我不会影响其他任何人。在我最终推出更改之前，我可能会很容易地修改该决定。那么这本身就是一个干净的提交。
此示例中的问题在于以下情况：假设我在本地分支或“延迟提交”上重命名该类。与此同时，有人向主干提交了使用我刚刚重命名的类的新代码。合并我的重命名会很麻烦。
当然，您可以在执行此操作时立即发布该更改。在两个系统中。责任是一样的。但由于 DVCS 鼓励您进行更小、增量的提交，因此合并会更容易。如果您尽早发布更改，两个系统都可以为您提供相同的“退出策略”以摆脱这种情况。
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.
持续集成系统是一种每 N 分钟监视一次源代码存储库的工具（例如 Cruise Control）。
每当发生变化（有人提交代码）时，CI 就会介入，运行所有测试，然后将输出（失败与否）发送到某个地方，例如电子邮件或屏幕。
CI 不以任何方式依赖于您使用的 VCS 类型，无论是否分布式。
A Continuous Integration system is a tool (like for example Cruise Control) that monitors your source code repository once every N minutes.
Every time something changes (somebody commits code), the CI jumps in, runs all tests and then sends the output (failures or not) somewhere, like email or a screen.
CI does not depend in any way with the kind of VCS you use, whether is distributed or not.
这涉及很多要素，有些与软件有关，有些与流程有关。
版本控制系统就是版本控制。回滚、分支、合并等能力，无论是集中式还是分布式，都有优点和缺点。 VCS 本身并不能帮助您更好地编码或更好地运行项目，如果团队运行正常，它们会促进团队的开发过程。换句话说，使用 SVN 或 Mercurial 也可能会搞砸，就像不使用它们一样。
CI 的用武之地是先编写几天代码，然后提交，然后构建项目并测试，编码器更频繁地提交，1/2 天 1 天（最多），然后构建并测试项目（未发布上线）。这意味着任何错误都会被更早地发现，并且可以更容易地纠正，因为提交的代码更少并且程序员的记忆更新鲜。
CI 可以手动完成，也可以编写脚本，编写 CLI 脚本即可完成，或者可以将与 CVS 集成的众多 CI 软件工具之一设置为自动或半自动执行此过程，以减少管理和维护犯错误的能力。
使用现有工具（Mercurial + Hudson，或 SVN 和 Cruise Control）的优势在于，您可以利用那些可能在某个时候搞砸了但吸取了教训的人的智慧和经验。但您不能做的就是将其从盒子中取出并使用它，并期望它能够在不添加您自己项目的流程的情况下工作。
There are a number of elements to this, some to do with software, some to do with process.
Version control systems are just that, version control. The ability to roll back, branch and merge, etc. that whether they are centralised or distributed and they both have up and down sides. VCS per se do not help you to code better or run projects better they facilitate the process of development in teams if and when teams are run properly. In other words you can screw up just as royally using SVN or Mercurial as you can without it.
Where CI comes in is rather than code for several days and then commit, then build the project and test, coder commit more frequently, 1/2 day 1 day (max) and the project is built and tested (not released to live). This means that any errors are picked up earlier and can be more easily rectified as less code has been committed and the programmers memory is fresher.
CI can be done manually, or it can be scripted, writing CLI scripts will do it, or one of the number of CI software tools that will integrate with CVS can be setup to do this process automatically or semi-automatically to reduce the management and the ability to make mistakes.
The advantage of using existing tools, Mercurial + Hudson, or SVN and Cruise Control, is that you are piggy backing on the wisdom and experience of people who probably screwed up royally at some point but learnt the lesson. What you cannot do though is get it out of the box and use it and expect it to work with out adding your own process for your own project into the mix.