Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？
这里的人们认为 Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？
在相互考虑并针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？
在计划从 SVN 迁移到这些分布式版本控制系统之一时，您会考虑哪些因素？
What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
我使用 Bazaar 有一段时间了，我很喜欢它，但它只是较小的项目，即使这样，速度也相当慢。 很容易学习，但不是超级快。 不过，它是非常x平台的。
我目前使用 Git，我非常喜欢它，因为 1.6 版本使它在使用命令方面与其他 VCS 更加相似。
我认为我使用 DVCS 的体验的主要区别在于：
总而言之，当我刚刚接触 DVCS 时，Bzr 非常棒，但我现在对 Git 和 Github 非常满意。
I was using Bazaar for a while which I liked a lot but it was only smaller projects and even then it was pretty slow. So easy to learn, but not super fast. It is very x-platform though.
I currently use Git which I like a lot since version 1.6 made it much more similar to other VCS in terms of the commands to use.
I think the main differences for my experience in using DVCS is this:
In summary Bzr was great when I was cutting my teeth on DVCS but I'm now very happy with Git and Github.
这是一个大问题，很大程度上取决于上下文，这将花费您大量时间在这些小文本框中键入内容。 此外，当用于大多数程序员所做的日常工作时，所有这三个看起来都非常相似，因此即使理解这些差异也需要一些相当深奥的知识。
如果您能将对这些工具的分析分解为提出更具体的问题，您可能会得到更好的答案。
This is a big question that depends a lot on context that would take you a lot of time to type into one of these little text boxes. Also, all three of these appear substantially similar when used for the usual stuff most programmers do, so even understanding the differences requires some fairly esoteric knowledge.
You will probably get much better answers if you can break your analysis of these tools down to the point at which you have more specific questions.
恕我直言，Bazaar 比 git 更容易学习。
Git 在 github.com 上有很好的支持。
我认为你应该尝试使用两者并决定哪一个最适合你。
Bazaar is IMHO easier to learn than git.
Git has a nice support in github.com.
I think you should try to use both and decide which suits you most.
这是一个非常开放的问题，近乎火焰诱饵。
Git 是最快的，但是三个都足够快了。 Bazaar 是最灵活的（它对 SVN 存储库具有透明的读写支持）并且非常关心用户体验。 Mercurial 处于中间位置。
这三个系统都有很多粉丝。 我个人是芭莎的粉丝。
前者是分布式系统。 后者是集中式系统。 此外，Perforce 是专有的，而所有其他软件都是免费的就像在演讲中。
集中式与分散式是比您在其类别中提到的任何系统都更重要的选择。
首先，缺乏TortoiseSVN的良好替代品。 尽管 Bazaar 正在开发自己的 Tortoise 变体，但截至 2008 年 9 月，它还没有出现。
然后，培训关键人员了解使用去中心化系统将如何影响他们的工作。
最后，与系统的其余部分集成，例如问题跟踪器、夜间构建系统、自动化测试系统等。
This is a very open question, bordering on flamebait.
Git is fastest, but all three are fast enough. Bazaar is the most flexible (it has transparent read-write support for SVN repositories) and cares a lot about the user experience. Mercurial is somewhere in the middle.
All three systems have lots of fanboys. I am personally a Bazaar fanboy.
The former are distributed systems. The latter are centralized systems. In addition, Perforce is proprietary while all the others are free as in speech.
Centralized versus decentralized is a much more momentous choice than any of the systems you mentioned within its category.
First, lack of a good substitute for TortoiseSVN. Although Bazaar is working on their own Tortoise variant, but it's not there yet, as of September 2008.
Then, training the key people about how using a decentralized system is going to affect their work.
Finally, integration with the rest of the system, such as issue trackers, the nightly build system, the automated test system, etc.
您的主要问题是这些是分布式 SCM，因此需要对用户的思维方式进行一些改变。 一旦人们习惯了这个想法，技术细节和使用模式就会就位，但不要低估最初的障碍，尤其是在企业环境中。 请记住，所有问题都是人的问题。
Your major issue is going to be that these are Distributed SCMs, and as such require a bit of a change to the user's mindset. Once people get used to the idea the technical details and usage patterns will fall into place, but don't underestimate that initial hurdle, especially in a corporate setting. Remember, all problems are people problems.
ddaa.myopenid.com 顺便提到了这一点，但我认为值得再次提及：Bazaar 可以读取和写入远程 SVN 存储库。 这意味着您可以在本地使用 Bazaar 作为概念验证，而团队的其他成员仍在使用 Subversion。
编辑：现在几乎所有工具都具有与 SVN 交互的某种方式，但我现在的个人经验是
git svn工作极其得很好。 我已经使用它几个月了，几乎没有出现任何问题。ddaa.myopenid.com mentioned it in passing, but I think it's worth mentioning again: Bazaar can read and write to remote SVN repositories. That means you could use Bazaar locally as a proof-of-concept while the rest of the team is still using Subversion.
EDIT: Pretty much all the tool now have some way of interacting with SVN, but I now have personal experience that
git svnworks extremely well. I've been using it for months, with minimal hiccups.git 上有 Linus Torvalds 的精彩视频。 他是 Git 的创建者，所以这就是他所提倡的，但在视频中他解释了分布式 SCM 是什么以及为什么它们比集中式 SCM 更好。 有很多关于 git（mercurial 被认为还可以）和 cvs/svn/perforce 的比较。 观众还提出了有关迁移到分布式 SCM 的问题。
我发现这些材料很有启发性，我被卖给了分布式 SCM。 但尽管莱纳斯做出了努力，我的选择还是反复无常的。 原因是 bitbucket.org，我发现它比 github 更好（更慷慨）。
在这里我需要说一句警告：Linus 的风格相当激进，我认为他想搞笑，但我没有笑。 除此之外，如果您是分布式 SCM 的新手并考虑从 SVN 迁移，那么该视频非常棒。
http://www.youtube.com/watch?v=4XpnKHJAok8
There is good video by Linus Torvalds on git. He is creator of Git so this is what he promotes but in the video he explain what distributed SCMs are and why they are better then centralized ones. There is a good deal of comparing git (mercurial is considered to be OK) and cvs/svn/perforce. There are also questions from the audience regarding migration to distributed SCM.
I found this material enlightening and I am sold to distributed SCM. But despite Linus' efforts my choice is mercurial. The reason is bitbucket.org, I found it better (more generous) then github.
I need to say here a word of warning: Linus has quite aggressive style, I think he wants to be funny but I didn't laugh. Apart from that the video is great if you are new to distributed SCMs and think about move from SVN.
http://www.youtube.com/watch?v=4XpnKHJAok8
分布式版本控制系统 (DVCS) 解决的问题与集中式版本控制系统不同。 比较它们就像比较锤子和螺丝刀一样。
集中式 VCS 系统的设计意图是存在一个受祝福的真实源头，因此好的。 所有开发人员都从该源开始工作（签出），然后添加（提交）他们的更改，然后这些更改就会变得类似 Blessed。 CVS、Subversion、ClearCase、Perforce、VisualSourceSafe 和所有其他 CVCS 之间的唯一真正区别在于每个产品提供的工作流程、性能和集成。
分布式 VCS 系统的设计初衷是让一个存储库与其他存储库一样好，并且从一个存储库合并到另一个存储库只是另一种形式的通信。 关于应该信任哪个存储库的任何语义值都是由过程从外部强加的，而不是由软件本身强加的。
使用一种类型或另一种类型之间的真正选择是组织性的——如果您的项目或组织想要集中控制，那么 DVCS 是不可能的。 如果您的开发人员需要在全国/世界各地工作，而没有与中央存储库的安全宽带连接，那么 DVCS 可能是您的救星。 如果你两者都需要，那你就完了。
Distributed version control systems (DVCSs) solve different problems than Centralized VCSs. Comparing them is like comparing hammers and screwdrivers.
Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore Good. All developers work (checkout) from that source, and then add (commit) their changes, which then become similarly Blessed. The only real difference between CVS, Subversion, ClearCase, Perforce, VisualSourceSafe and all the other CVCSes is in the workflow, performance, and integration that each product offers.
Distributed VCS systems are designed with the intent that one repository is as good as any other, and that merges from one repository to another are just another form of communication. Any semantic value as to which repository should be trusted is imposed from the outside by process, not by the software itself.
The real choice between using one type or the other is organizational -- if your project or organization wants centralized control, then a DVCS is a non-starter. If your developers are expected to work all over the country/world, without secure broadband connections to a central repository, then DVCS is probably your salvation. If you need both, you're fsck'd.
看一下 Python 开发人员最近所做的比较：http://wiki.python.org/moin/ Dvcs比较。 他们选择 Mercurial 基于三个重要原因：
Take a look at the comparison made recently by the Python developers: http://wiki.python.org/moin/DvcsComparison. They chose Mercurial based on three important reasons:
Sun 对 git 进行了评估，Mercurial 和 Bazaar 作为替代 Solaris 代码库的 Sun Teamware VCS 的候选者。 我发现这很有趣。
Sun did an evaluation of git, Mercurial, and Bazaar as candidates to replace the Sun Teamware VCS for the Solaris code base. I found it very interesting.
集市中缺失一个非常重要的东西就是cp。 您不能让多个文件共享相同的历史记录，就像在 SVN 中一样，请参阅例如 此处和此处。 如果您不打算使用 cp，bzr 是 svn 的一个很好的（并且非常容易使用）替代品。
A very important missing thing in bazaar is cp. You cannot have multiple files sharing the same history, as you have in SVN, see for example here and here. If you don't plan to use cp, bzr is a great (and very easy to use) replacement for svn.
从表面上看，Mercurial 和 Bazaar 非常相似。 它们都提供基本的分布式版本控制，例如离线提交和合并多个分支，都是用 python 编写的，并且都比 git 慢。 一旦你深入研究代码，就会发现很多差异，但是，对于你的日常任务，它们实际上是相同的，尽管 Mercurial 似乎有更多的动力。
Git 不适合新手。 它比 Mercurial 和 Bazaar 快得多，并且是为管理 Linux 内核而编写的。 它是三者中速度最快的，也是三者中最强大的，优势明显。 Git 的日志和提交操作工具是无与伦比的。 然而，它也是最复杂且使用起来最危险的。 丢失提交或毁坏存储库是很容易的，特别是如果您不了解 git 的内部工作原理。
Mercurial and Bazaar resemble themselves very much on the surface. They both provide basic distributed version control, as in offline commit and merging multiple branches, are both written in python and are both slower than git. There are many differences once you delve into the code, but, for your routine day-to-day tasks, they are effectively the same, although Mercurial seems to have a bit more momentum.
Git, well, is not for the uninitiated. It is much faster than both Mercurial and Bazaar, and was written to manage the Linux kernel. It is the fastest of the three and it is also the most powerful of the three, by quite a margin. Git's log and commit manipulation tools are unmatched. However, it is also the most complicated and the most dangerous to use. It is very easy to lose a commit or ruin a repository, especially if you do not understand the inner workings of git.
Git 速度非常快，扩展性非常好，并且其概念非常透明。 这样做的缺点是它的学习曲线相对陡峭。 Win32 端口可用，但还不是一等公民。 Git 将哈希值作为版本号公开给用户； 这提供了保证（因为单个散列始终引用完全相同的内容；攻击者无法在不被检测到的情况下修改历史记录），但对用户来说可能很麻烦。 Git 有一个独特的概念来跟踪文件内容，即使这些内容在文件之间移动，并将文件视为第一级对象，但不跟踪目录。 git 的另一个问题是它有许多操作（例如 rebase），可以轻松修改历史记录（从某种意义上说，哈希引用的内容永远不会改变，但对该哈希的引用可能会丢失）； 一些纯粹主义者（包括我自己）不太喜欢这一点。
Bazaar 相当快（对于历史较浅的树来说非常快，但目前随着历史长度的扩展很差），并且对于熟悉传统 SCM（CVS、SVN 等）命令行界面的人来说很容易学习。 Win32 被其开发团队认为是一流的目标。 它具有不同组件的可插拔架构，并且经常更换其存储格式； 这使他们能够引入新功能（例如更好地支持与基于不同概念的修订控制系统的集成）并提高性能。 Bazaar 团队认为目录跟踪和重命名支持是一流的功能。 虽然全局唯一的修订 ID 标识符可用于所有修订，但使用树本地 revno（标准修订号，更类似于 svn 或其他更传统的 SCM 使用的修订号）来代替内容哈希来识别修订。 Bazaar 支持“轻量级结帐”，其中历史记录保存在远程服务器上，而不是复制到本地系统，并在需要时通过网络自动引用； 目前，这在 DSCM 中是独一无二的。
两者都提供某种形式的 SVN 集成； 然而，bzr-svn 比 git-svn 的功能要强大得多，这主要是由于为此目的引入的后端格式修订。 [更新，截至 2014 年：第三方商业产品 SubGit 提供了 SVN 和 Git 之间的双向接口，其保真度与 bzr-svn 相当，而且更加精致； 我强烈建议在预算和许可限制允许的情况下使用它而不是 git-svn]。
我没有广泛使用 Mercurial，因此无法对其进行详细评论 - 除非需要注意它像 Git 一样，具有用于修订的内容哈希寻址； 也像 Git 一样，它不将目录视为一流对象（并且不能存储空目录）。 然而，它比除 Git 之外的任何其他 DSCM 都要快，并且比任何竞争对手具有更好的 IDE 集成（尤其是 Eclipse）。 鉴于其性能特征（仅略微落后于 Git）及其卓越的跨平台和 IDE 支持，Mercurial 对于拥有大量以 win32 为中心或受 IDE 约束的成员的团队来说可能很有吸引力。
从 SVN 迁移的一个问题是 SVN 的 GUI 前端和 IDE 集成比任何分布式 SCM 都更加成熟。 另外，如果您当前大量使用 SVN 的预提交脚本自动化（即要求在提交继续之前通过单元测试），您可能需要使用类似于 PQM 用于自动向共享分支发出合并请求。
SVK 是一个 DSCM，它使用 Subversion 作为其后备存储，并且与以 SVN 为中心的工具具有很好的集成。 然而，它的性能和可扩展性特征比任何其他主要 DSCM（甚至 Darcs）都要差得多，对于历史长度或文件数量容易增长的项目应该避免使用。
[关于作者：我在工作中使用 Git 和 Perforce，在我的个人项目中使用 Bazaar 并作为嵌入式库； 我雇主组织的其他部门大量使用 Mercurial。 前世我围绕 SVN 构建了大量自动化； 在此之前，我有过使用 GNU Arch、BitKeeper、CVS 等的经验。 一开始，Git 非常令人反感——感觉就像 GNU Arch，因为它是一个概念重的环境，而不是为了符合用户选择的工作流程而构建的工具包——但从那以后我就对它感到非常满意了。它]。
Git is very fast, scales very well, and is very transparent about its concepts. The down side of this is that it has a relatively steep learning curve. A Win32 port is available, but not quite a first-class citizen. Git exposes hashes as version numbers to users; this provides guarantees (in that a single hash always refers to the exact same content; an attacker cannot modify history without being detected), but can be cumbersome to the user. Git has a unique concept of tracking file contents, even as those contents move between files, and views files as first-level objects, but does not track directories. Another issue with git is that has many operations (such as rebase) which make it easy to modify history (in a sense -- the content referred to by a hash will never change, but references to that hash may be lost); some purists (myself included) don't like that very much.
Bazaar is reasonably fast (very fast for trees with shallow history, but presently scales poorly with history length), and is easy-to-learn to those familiar with the command-line interfaces of traditional SCMs (CVS, SVN, etc). Win32 is considered a first-class target by its development team. It has a pluggable architecture for different components, and replaces its storage format frequently; this allows them to introduce new features (such as better support for integration with revision control systems based on different concepts) and improve performance. The Bazaar team considers directory tracking and rename support first-class functionality. While globally unique revision-id identifiers are available for all revisions, tree-local revnos (standard revision numbers, more akin to those used by svn or other more conventional SCMs) are used in place of content hashes for identifying revisions. Bazaar has support for "lightweight checkouts", in which history is kept on a remote server instead of copied down to the local system and is automatically referred to over the network when needed; at present, this is unique among DSCMs.
Both have some form of SVN integration available; however, bzr-svn is considerably more capable than git-svn, largely due to backend format revisions introduced for that purpose. [Update, as of 2014: The third-party commercial product SubGit provides a bidirectional interface between SVN and Git which is comparable in fidelity to bzr-svn, and considerably more polished; I strongly recommend its use over that of git-svn when budget and licensing constraints permit].
I have not used Mercurial extensively, and so cannot comment on it in detail -- except to note that it, like Git, has content-hash addressing for revisions; also like Git, it does not treat directories as first-class objects (and cannot store an empty directory). It is, however, faster than any other DSCM except for Git, and has far better IDE integration (especially for Eclipse) than any of its competitors. Given its performance characteristics (which lag only slightly behind those of Git) and its superior cross-platform and IDE support, Mercurial may be compelling for teams with significant number of win32-centric or IDE-bound members.
One concern in migrating from SVN is that SVN's GUI frontends and IDE integration are more mature than those of any of the distributed SCMs. Also, if you currently make heavy use of precommit script automation with SVN (ie. requiring unit tests to pass before a commit can proceed), you'll probably want to use a tool similar to PQM for automating merge requests to your shared branches.
SVK is a DSCM which uses Subversion as its backing store, and has quite good integration with SVN-centric tools. However, it has dramatically worse performance and scalability characteristics than any other major DSCM (even Darcs), and should be avoided for projects which are liable to grow large in terms of either length of history or number of files.
[About the author: I use Git and Perforce for work, and Bazaar for my personal projects and as an embedded library; other parts of my employer's organization use Mercurial heavily. In a previous life I built a great deal of automation around SVN; before that I have experience with GNU Arch, BitKeeper, CVS and others. Git was quite off-putting at first -- it felt like GNU Arch inasmuch as being a concept-heavy environment, as opposed to toolkits built to conform to the user's choice of workflows -- but I've since come to be quite comfortable with it].
Ogre 3D 项目的 Steve Streeting 刚刚 (2009 年 9 月 28 日) 发表了一篇关于这个主题的博客文章，他在其中做了出色的贡献 Git、Mercurial 和 Bazaar 的比较。
最终，他发现了这三者的优点和缺点，但没有明显的赢家。 从好的方面来说，他提供了一个很棒的表格来帮助您决定选择哪一个。
这是一篇简短的文章，我强烈推荐它。
Steve Streeting of the Ogre 3D project just (9/28/2009) published a blog entry on this topic where he does a great and even handed comparison of Git, Mercurial and Bazaar.
In the end he finds strengths and weaknesses with all three and no clear winner. On the plus side, he gives a great table to help you decide which to go with.
Its a short read and I highly recommend it.
在我看来，Git 的优势在于其简洁的底层设计和非常丰富的功能集。 我认为它还为多分支存储库和管理分支繁重的工作流程提供了最佳支持。 它非常快并且存储库大小很小。
它有一些有用的功能，但需要一些努力才能使用它们。 其中包括工作区和存储库数据库之间的可见中间暂存ara（索引），它允许在更复杂的情况下更好的合并解决方案、增量提交和脏树提交； 使用相似性启发式检测重命名和副本，而不是使用某种文件ID来跟踪它们，这种方式效果很好，并且允许责备（注释），它可以跟踪跨文件的代码移动，而不仅仅是批量重命名。
其缺点之一是对MS Windows的支持滞后且不全面。 另一个明显的缺点是它不像 Mercurial 那样有很好的文档记录，并且比竞争对手的用户友好性较差，但它发生了变化。
在我看来，Mercurial 的优势在于其良好的性能和较小的存储库大小以及良好的 MS Windows 支持。
在我看来，主要缺点是本地分支（单个存储库中的多个分支）仍然是二等公民，并且以奇怪而复杂的方式实现标签。 此外，它处理文件重命名的方式也不是最佳的（但这可能已经改变）。 Mercurial 不支持 octopus 合并（具有两个以上的父级）。
据我所听到和读到的，Bazaar 的主要优点是它可以轻松支持集中式工作流程（这也是缺点，集中式概念在不应该可见的地方可见），跟踪文件和目录的重命名。
它的主要缺点是具有较长非线性历史的大型存储库的性能和存储库大小（至少对于不太大的存储库，性能有所提高），事实上，默认范例是每个存储库一个牧场（不过，您可以将其设置为共享数据） ，以及集中的概念（但这也是我所听到的变化）。
Git 是用 C、shell 脚本和 Perl 编写的，并且可以编写脚本； Mercurial是用C（核心，为了性能）和Python编写的，并提供API用于扩展； Bazaar是用Python编写的，并提供API用于扩展。
Subversion (SVN)、Perforce 或 ClearCase 等版本控制系统是集中式的< /em> 版本控制系统。 Git、Mercurial、Bazaar（还有 Darcs、Monotone 和 BitKeeper）都是分布式版本控制系统。 分布式版本控制系统允许更广泛的工作流程。 他们允许使用“准备好后发布”。 它们对分支和合并以及分支繁重的工作流程有更好的支持。 您不需要信任具有提交访问权限的人就能够以简单的方式从他们那里获得贡献。
您可能需要考虑的因素之一是对 SVN 交互的支持； Git 有 git-svn，Bazaar 有 bzr-svn，Mercurial 有 hgsubversion 扩展。
免责声明：我是 Git 用户和小型贡献者，并且关注（并参与）git 邮件列表。 我仅从 Mercurial 和 Bazaar 的文档、IRC 和邮件列表上的各种讨论以及比较各种版本控制系统的博客文章和文章（其中一些列在 GitComparison Git Wiki 上的页面）。
In my opinion Git strength is its clean underlying design and very rich set of features. It also has I think the best support for multi-branch repositories and managing branch-heavy workflows. It is very fast and has small repository size.
It has some features which are useful but take some effort to be used to them. Those include visible intermediate staging ara (index) between working area and repository database, which allows for better merge resolution in more complicated cases, incremental comitting, and comitting with dirty tree; detecting renames and copies using similarity heuristic rather than tracking them using some kind of file-ids, which works well and which allow for blame (annotate) which can follow code movement across files and not only wholesale renames.
One of its disadvantages is that MS Windows support lags behind and is not full. Another perceived disadvantage is that it is not as well documented as for example Mercurial, and is less user friendly than competition, but it changes.
In my opinion Mercurial strength lies in its good performance and small repository size, in its good MS Windows support.
The main disadvanatge is in my opinion the fact that local branches (multiple branches in single repository) is still second-class citizen, and in strange and complicated way it implements tags. Also the way it deals with file renames was suboptimal (but this migth have changed). Mercurial doesn't support octopus merges (with more than two parents).
From what I have heard and read main Bazaar advantages are it easy support for centralized workflow (which is also disadvantage, with centralized concepts visible where it shouldn't), tracking renames of both files and directories.
Its main disadvantage are performance and repository size for large repositories with long nonlinear history (the performance improved at least for not too large repositories), the fact that default paradigm is one ranch per repository (you can set it up to share data, though), and centralized concepts (but that also from what I have heard changes).
Git is written in C, shell scripts and Perl, and is scriptable; Mercurial is written in C (core, for performance) and Python, and provides API for extensions; Bazaar is written in Python, and provides API for extensions.
Version control systems like Subversion (SVN), Perforce, or ClearCase are centralized version control systems. Git, Mercurial, Bazaar (and also Darcs, Monotone and BitKeeper) are distributed version control systems. Distributed version control systems allow for much wider range of workflows. They allow to use "publish when ready". They have better support for branching and merging, and for branch-heavy workflows. You don't need to trust people with commit access to be able to get contributions from them in an easy way.
One of factors you might want to consider is the support for inetracting with SVN; Git has git-svn, Bazaar has bzr-svn, and Mercurial has hgsubversion extension.
Disclaimer: I am Git user and small time contributor, and watch (and participate on) git mailing list. I know Mercurial and Bazaar only from their documentation, various discussion on IRC and mailing lists, and blog posts and articles comparing various version control systems (some of which are listed on GitComparison page on Git Wiki).