使用 dvc 是否会增加在企业环境中使用持续集成的难度？
毫无疑问，使用 dvcs 有很多优点，它可以像集中式 vcs 一样使用，但是本地提交以及能够非常轻松地为一些较小的团队分叉项目是否会导致支持持续集成变得更加困难？ 每个人都可以访问最新的更改，这有助于开发，这些更改是由 CI 服务器测试的，因此可以最大限度地减少不兼容更改的可能性。
There are unarguably lots of advantages in using dvcs and it can be used like centralized vcs, but is having local commits and being able to very easily fork the project for some smaller group making it harder to support continuous integration? It helps in development that everybody has access to the most recent changes, which are tested by the CI server so possibility of incompatible changes can be minimized.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以集中 DVCS。 DVCS 和集中式 DVCS 之间的区别在于，使用 DVCS，您不必将其集中化。
您可以拥有一个中央存储库，每个人都可以在其中推送更改，并且每个人都可以从中提取最新代码。 您可以在服务器上编写一个提交挂钩，以便每次有人推送代码时，它都会运行测试以确保它通过测试。 这就像集中式版本控制，甚至更好，因为我可以创建一个本地分支并在准备推送到中央服务器之前进行多次本地提交。
您是否曾经做过一个重大更改，破坏了很多东西，并且想要进行多次提交，但在完成并且所有内容都再次修复之前不要共享它们？ 这就是 DVCS 使之变得简单的原因。
You can centralize a DVCS. The difference between DVCS and centralized ones is that with a DVCS, you don't have to centralize it.
You could have a central repository where everyone can push changes, and everyone can pull the latest code from. You can write a commit hook on the server so that every time someone pushes code, it runs a test to make sure it passes the tests. It's just like centralized version control, only better, because I can create a local branch and make several local commits before I'm ready to push to the central server.
Have you ever been making a big change that breaks a lot of things, and wanted to make several commits, but not share them until you're done and everything is fixed again? That's what DVCS makes easy.
它确实使执行 CI 变得更加困难，因为源代码控制系统鼓励您不要持续集成。 但是，绝对没有什么可以阻止您定期集成到中央存储库中。 团队只需要对此保持纪律即可。
如果较小的团队分叉项目并暂时做自己的事情，您也应该针对该分叉进行持续集成构建，并可能在两个分叉之间建立定期集成。
这类似于 Accurev 推出的基于流的多阶段持续集成策略：
http://www.accurev.com/multistage-continuous-integration.html
It does make it harder to perform CI as the source control system is encouraging you NOT to integrate continuously. However, there is absolutely nothing that prevents you from doing that regular integration into the central repository. The team just needs to remain disciplined about that.
Where smaller teams fork the project and do their own thing for a while, you should do continuous integration builds against that fork as well and potentially set up a regular integration between the two forks.
This would be similar to the stream based multi-stage continuous integration strategies that Accurev pushes:
http://www.accurev.com/multistage-continuous-integration.html