您使用分布式版本控制吗？
https://stackoverflow.com/questions/26845
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我想听听使用分布式版本控制（又名分布式修订控制、分散版本控制）的人们的意见以及他们如何找到它。你在使用什么，Mercurial、Darcs、Git、Bazaar？你还在用它吗？如果您过去使用过客户端/服务器 rcs，您是否发现它更好、更差或只是不同？你能告诉我什么才能让我跟上潮流吗？或者就此事而言，我也有兴趣听取有负面经历的人的意见。
我目前正在考虑更换我们当前的源代码控制系统（Subversion），这是这个问题的推动力。
我对与其他国家/地区的同事一起使用它的任何人特别感兴趣，在这些国家/地区，您的计算机可能不会同时打开，并且您的连接速度非常慢。
如果您不确定什么是分布式版本控制，请阅读以下几篇文章：
解决方案
我一直在工作和个人项目中使用 Mercurial，我对此非常满意。我看到的优点是：
- 本地版本控制。 有时我正在做一些事情，我想保留它的版本历史记录，但我还没有准备好将其推送到中央存储库。借助分布式 VCS，我只需提交本地存储库直至其准备就绪，无需分支。这样，如果其他人进行了我需要的更改，我仍然可以获得它们并将它们集成到我的代码中。当我准备好后，我将其推送到服务器。
- 更少的合并冲突。 它们仍然会发生，但它们似乎不太频繁，而且风险也较小，因为所有代码都签入到我的本地存储库中，所以即使我搞砸了合并，我也可以随时备份并再次执行。
- 将存储库单独作为分支。 如果我同时运行几个开发向量，我可以对我的存储库进行几个克隆并独立开发每个功能。这样，如果有东西报废或滑落，我就不必把碎片拉出来。当它们准备好时，我就把它们合并在一起。
- 速度。 Mercurial 的使用速度要快得多，主要是因为大多数常见操作都是本地的。
当然，就像任何新系统一样，过渡期间也有一些痛苦。你必须以不同于使用 SVN 时的方式来思考版本控制，但总的来说，我认为这是非常值得的。
其他提示
在我工作的地方，我们决定从 SVN 迁移到 Bazaar（在评估了 git 和 Mercurial 之后）。Bazaar 很容易上手，命令也很简单（不像 git 有 140 个命令）
我们看到的优点是能够创建本地分支并在不干扰主版本的情况下对其进行工作。由于无需网络访问也能工作，因此比较速度更快。
我喜欢 bzr 中的一项命令是搁置扩展。如果您开始在单个文件中处理两段逻辑上不同的代码，并且只想提交其中一段，则可以使用搁置扩展来稍后搁置其他更改。在 Git 中，您可以在索引（暂存区域）中执行相同的操作，但 bzr 有更好的 UI。
大多数人不愿意移动，因为他们必须输入两个命令来提交和推送（bzr ci + bzr Push）。他们也很难理解分支和合并的概念（没有人在 svn 中使用分支或合并它们）。
一旦理解了这一点，就会提高开发人员的生产力。在每个人都明白这一点之前，每个人之间都会出现不一致的行为。
在我的工作场所，我们大约两个月前从 CVS 切换到了 Git（我的大部分经验都是使用 Subversion）。虽然熟悉分布式系统有一个学习曲线，但我发现 Git 在两个关键领域表现出色：工作环境的灵活性和融合。
我不必使用我们的 VPN，甚至根本不需要网络连接，就可以访问完整的版本控制功能。这意味着当冲动袭来时，我可以随时随地尝试想法或执行大型重构，而不必记得检查我已经建立的巨大提交，也不必担心当我搞砸时无法恢复。
由于合并是在客户端执行的，因此它们比启动服务器端合并要快得多且不易出错。
我的公司目前使用 Subversion、CVS、Mercurial 和 git。
当我们五年前开始时，我们选择了 CVS，并且在我的部门中我们仍然使用它作为我们的主要开发和发布维护分支。然而，我们的许多开发人员单独使用 Mercurial 作为一种拥有私有检查点的方式，而无需承受 CVS 分支（特别是合并它们）的痛苦，并且我们开始将 Mercurial 用于一些最多约 5 人的分支。我们很有可能在一年内最终放弃 CVS。我们对 Mercurial 的使用不断增长；有些人甚至从来没有碰过它，因为他们对 CVS 很满意。每个尝试过 Mercurial 的人最终都对它感到满意，并且没有太多的学习曲线。
Mercurial 对我们来说真正有效的是，我们的（自制的）持续集成服务器可以监控开发人员 Mercurial 存储库以及主线。因此，人们提交到他们的存储库，让我们的持续集成服务器检查它，然后发布变更集。我们支持很多平台，因此进行适当水平的手动检查是不可行的。另一个胜利是合并通常很容易，当合并困难时，您可以获得做好合并工作所需的信息。一旦有人让合并版本开始工作，他们就可以推送他们的合并变更集，然后其他人就不必重复这项工作。
最大的障碍是您需要重新连接开发人员和经理的大脑，以便他们摆脱单一线性分支模型。对此最好的药物是一剂 Linus Torvalds 告诉你你正在 又蠢又丑 如果您使用集中式 SCM。好的历史可视化工具会有所帮助，但我对可用的工具还不满意。
对于我们混合使用 Windows、Linux 和 Solaris 的开发人员来说，Mercurial 和 CVS 都工作得很好，而且我注意到时区没有问题。（实际上，这并不太难；你只需在内部使用纪元秒，我希望所有主要的 SCM 系统都能做到这一点）。
经过相当多的努力，就有可能将我们的主线 CVS 历史导入到 Mercurial 中。如果人们没有故意将极端情况引入我们的主线 CVS 历史记录中作为测试历史迁移工具的一种方式，事情会更容易。这包括将一些 Mercurial 分支合并到 CVS 历史记录中，因此该项目看起来就像从第一天就开始使用一样。
我们的芯片设计团队选择了 Subversion。它们距离我的办公室主要有 8 个时区，即使在我们办公室之间有一条相当好的专线，SUbversion 结帐也很痛苦，但可行。集中式系统的一大优点是您可以将大型二进制文件签入其中（例如供应商版本），而不会使所有分布式存储库变得巨大。
我们使用 git 来处理 Linux 内核。一旦原生 Windows 版本成熟，Git 会更适合我们，但我认为 Mercurial 的设计是如此简单和优雅，所以我们会坚持使用它。
我自己没有使用分布式源代码控制，但也许这些相关的问题和答案可以给您一些见解：
我个人使用 Mercurial 源代码控制系统。我现在已经使用它一年多了。这实际上是我第一次体验 VSC。
我尝试过 Git，但从未真正投入使用，因为我发现它对于我的需要来说太多了。如果您是 Subversion 用户，Mercurial 确实很容易上手，因为它与 Subversion 共享许多命令。另外，我发现存储库的管理非常容易。
我有两种方式与人们分享我的代码：
- 我与同事共享一台服务器，并且我们为我们的项目保留了一个主要存储库。
- 对于我从事的一些 OSS 项目，我们使用 Mercurial 创建工作补丁（hg 导出），项目的维护者只需将它们应用到存储库上（hg 导入）
确实很容易使用，但功能非常强大。但一般来说，选择 VSC 实际上取决于我们项目的需求......
在我们关闭 Sun 工作站进行嵌入式系统开发之前，我们使用的是 Sun 的工作站 团队软件 解决方案。TeamWare 是一个完全分发的解决方案，使用 SCCS 作为本地存储库文件修订系统，然后使用一组工具将其包装起来，以处理合并操作（通过分支重命名完成）回集中存储库（其中可以有很多）。事实上，因为它是分布式的，所以本身实际上没有主存储库（除非按照惯例，如果您需要的话），并且所有用户都有自己的整个源代码树和修订版本的副本。在“放回”操作期间，使用 3 路差异的合并工具通过算法对内容进行排序，并允许您组合不同开发人员随时间积累的更改。
在切换到 Windows 作为我们的开发平台后，我们最终切换到 准确度. 。虽然 AccuRev 由于依赖于集中式服务器，所以并不是真正的分布式解决方案，但从逻辑上讲，它与工作流模型非常接近。TeamWare 在每个客户端上拥有完全独立的所有内容副本，包括所有文件的所有修订版，而在 AccuRev 下，副本保存在中央数据库中，本地客户端计算机仅具有用于本地编辑的平面文件当前版本。然而，这些本地副本可以通过客户端连接到服务器进行版本控制，并完全独立于任何其他更改进行跟踪（即：分支）由其他开发人员隐式创建
就我个人而言，我认为 TeamWare 实现的分布式模型或 AccuRev 实现的混合模型优于完全集中式解决方案。其主要原因是不存在必须检出文件或让其他用户锁定文件的概念。此外，用户不必创建或定义分支；这些工具会隐式地为您执行此操作。当有较大的团队或不同的团队贡献或维护一组源文件时，这可以解决“工具生成的”锁定相关冲突，并允许在开发人员级别更多地协调代码更改，而开发人员最终必须协调更改。从某种意义上说，分布式模型允许更细粒度的“锁”，而不是集中式模型建立的粗粒度锁定。
在一个大项目（GHC）和许多小项目中使用过 darcs。我对达尔克斯有着又爱又恨的关系。
优点：设置存储库非常容易。在存储库之间移动更改非常容易。非常容易克隆并在单独的存储库中尝试“分支”。在小的、连贯的团体中很容易做出有意义的“承诺”。很容易重命名文件和标识符。
缺点：没有历史概念——你无法恢复“8 月 5 日的情况”。我从来没有真正弄清楚如何使用darcs回到早期版本。
破坏交易：Darcs 无法缩放。我（和许多其他人）在使用 Darcs 的 GHC 中遇到了大麻烦。我将其悬挂在9天的100％使用情况下，试图进行3个月的变化。去年夏天，我经历了很糟糕的经历，我损失了两个星期的时间，试图使DARCS运作，并最终求助于将我所有的更改重新播放到原始的存储库中。
结论：如果您想要一种简单、轻量级的方法来避免自己为自己的爱好项目搬起石头砸自己的脚，darcs 是很棒的选择。但即使 darcs 2 中解决了一些性能问题，它仍然不适合工业强度的东西。我不会真正相信达尔克，除非被吹嘘的“补丁理论”不仅仅是几个方程和一些漂亮的图片；我希望看到一个真实的理论在经过评审的场所发表。已经过去了。
我真的很喜欢 Git，尤其是 GitHub。能够在本地提交和回滚真是太好了。挑选合并虽然不简单，但也不是特别困难，而且比 Svn 或 CVS 能做的任何事情都要先进得多。
我的团队正在使用 Git，这带来了天壤之别。我们使用 SCCS 和大量 csh 脚本来管理相当大且复杂的项目，这些项目在它们之间共享代码（无论如何尝试）。
使用 Git，子模块支持使很多事情变得简单，并且只需要最少的脚本编写。我们的发布工程工作已经大大减少，因为分支很容易维护和跟踪。能够以低成本进行分支和合并确实使得在多个项目（合同）中维护单个源集合变得相当容易，而在此之前，对典型事物流程的任何破坏都非常非常昂贵。我们还发现 Git 的脚本能力是 巨大的 另外，因为我们可以通过钩子或脚本来定制它的行为 . git-sh-setup, ，也不像以前那样是一堆杂七杂八的东西了。
有时我们也会遇到这样的情况：我们必须跨分布式、非联网站点（在本例中为断开连接的安全实验室）维护版本控制，而 Git 具有可以相当顺利地处理该问题的机制（捆绑包、基本克隆机制、格式化的补丁等）。
其中一些只是我们走出了 80 年代初并采用了一些现代版本控制机制，但 Git 在大多数领域“都做得对”。
我不确定您正在寻找的答案的范围，但我们使用 Git 的经验非常非常积极。
将 Subversion 与 SourceForge 和其他服务器一起使用，通过许多不同的连接与中型团队合作，效果非常好。
出于很多原因，我是集中式源代码控制的大力支持者，但我确实在一个项目上短暂尝试过 BitKeeper。也许在使用一种或另一种格式的集中式模型（Perforce、Subversion、CVS）多年之后，我发现分布式源代码控制很难使用。
我认为我们的工具永远不应该妨碍实际工作；他们应该让工作变得更容易。所以，在经历了几次令人头疼的经历之后，我放弃了。我建议在破坏之前与您的团队一起进行一些非常严格的测试，因为该模型与 SCM 世界中大多数开发人员可能习惯的模型非常不同。
我用过 市场 现在已经有一段时间了并且喜欢它。简单的分支和合并让我们对使用分支有很大的信心。（我知道中央 vcs 工具应该允许这样做，但是包括 subversion 在内的常见工具不允许这样做）。
bzr 支持相当多不同的 工作流程 从单独工作，到作为集中存储库工作，再到完全分布式。由于每个分支（对于开发人员或功能）都可以独立合并，因此可以在每个分支的基础上进行代码审查。
bzr 还有一个很棒的插件（bzr-svn）允许您使用 Subversion 存储库。您可以复制 svn 存储库（最初需要一段时间，因为它会获取本地存储库的整个历史记录）。然后您可以为不同的功能创建分支。如果您想在功能进行到一半时对主干进行快速修复，您可以创建一个额外的分支，在其中工作，然后合并回主干，使完成一半的功能保持不变并保留在主干之外。精彩的。到目前为止，反对颠覆一直是我的主要用途。
注意我只在 Linux 上使用过它，而且大部分是通过命令行使用的，尽管它应该在其他平台上运行良好，但它具有 GUI，例如 乌龟BZR 并且正在做很多与集成相关的工作 IDE 等等。
我正在为我的家庭项目使用 Mercurial。到目前为止，我喜欢它的是我可以拥有多个存储库。如果我把笔记本电脑带到机舱，我仍然可以进行版本控制，这与我在家里运行 CVS 时不同。分支就像这样简单 hg clone 并致力于克隆。
使用 Subversion
Subversion 不是分布式的，所以这让我觉得我需要一个维基百科链接，以防人们不确定我在说什么:)
一直在使用darcs 2.1.0，它非常适合我的项目。便于使用。喜欢樱桃采摘的变化。
我在工作中和我的一位同事一起使用 Git。不过，主要存储库是 SVN。我们经常需要切换工作站，而 Git 可以非常轻松地从另一台计算机上的本地存储库中提取更改。当我们作为一个团队致力于同一功能时，合并我们的工作是毫不费力的。
git-svn 桥有点不稳定，因为在签入 SVN 时，它会重写所有提交以添加其 git-svn-id 注释。这破坏了我同事的仓库和我的仓库之间合并的美好历史。我预测，如果每个团队成员都使用 Git，我们根本就不会使用中央存储库。
你没有说你在什么操作系统上开发，但 Git 的缺点是你必须使用命令行来获取所有功能。Gitk 是一个很好的图形用户界面，用于可视化合并历史记录，但合并本身必须手动完成。Git-Gui 和 Visual Studio 插件还没有那么完善。
我们使用分布式版本控制（塑料单片机）适用于多站点和断开连接的场景。
1- 多站点：如果您有遥远的团体，有时您不能依赖互联网连接，或者它不够快并且会减慢开发人员的速度。然后拥有可以同步回来的独立服务器（塑料来回复制分支）是非常有用的并且可以加快速度。这可能是公司最常见的场景之一，因为大多数公司仍然关注“完全分布式”实践，其中每个开发人员都有自己的复制存储库。
2- 断开连接（或者如果您愿意，可以真正分布式）：每个开发人员都有自己的存储库，该存储库与他的同行或中央位置来回复制。非常方便地前往客户所在地或只需携带笔记本电脑回家，并继续能够切换分支机构、结帐和签入代码、查看历史记录、运行注释等，而无需访问远程“中心”服务器。然后，每当您返回办公室时，只需单击几下即可将更改（通常是分支）复制回来。
