Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/77485/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
提问by Jordan Dea-Mattson
What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
这里的人们认为 Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
在考虑它们中的每一个并针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
在计划从 SVN 迁移到这些分布式版本控制系统之一时，您会考虑哪些因素？
回答by Charles Duffy
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.
Git 速度非常快，扩展性非常好，并且其概念非常透明。不利的一面是它的学习曲线相对陡峭。Win32 端口是可用的，但不是一等公民。Git 将哈希作为版本号公开给用户；这提供了保证（因为单个散列总是指完全相同的内容；攻击者无法在不被检测到的情况下修改历史记录），但对用户来说可能很麻烦。Git 具有跟踪文件内容的独特概念，即使这些内容在文件之间移动，并将文件视为一级对象，但不跟踪目录。git 的另一个问题是它有很多操作（比如rebase) 这使得修改历史变得容易（从某种意义上说——散列引用的内容永远不会改变，但对该散列的引用可能会丢失）；一些纯粹主义者（包括我自己）不太喜欢那样。
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.
Bazaar 相当快（对于历史较浅的树来说非常快，但目前随着历史长度的扩展很差），并且对于那些熟悉传统 SCM（CVS、SVN 等）的命令行界面的人来说很容易学习。Win32 被其开发团队视为一流目标。具有针对不同组件的可插拔架构，并频繁更换其存储格式；这使他们能够引入新功能（例如更好地支持与基于不同概念的修订控制系统的集成）并提高性能。Bazaar 团队认为目录跟踪和重命名支持一流的功能。虽然全局唯一的修订 ID 标识符可用于所有修订，树本地 revnos（标准修订号，更类似于 svn 或其他更传统的 SCM 使用的那些）代替内容哈希来识别修订。Bazaar 支持“轻量级结账”，其中历史记录保存在远程服务器上，而不是复制到本地系统，并在需要时通过网络自动引用；目前，这在 DSCM 中是独一无二的。
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 stronglyrecommend its use over that of git-svn when budget and licensing constraints permit].
两者都有某种形式的 SVN 集成可用；然而，bzr-svn 比 git-svn 强大得多，主要是由于为此目的引入了后端格式修订。[更新，截至 2014 年：第三方商业产品 SubGit 提供了 SVN 和 Git 之间的双向接口，其保真度与 bzr-svn 相当，并且更加完善；我强烈建议在预算和许可限制允许的情况下使用它而不是 git-svn]。
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.
我没有广泛使用 Mercurial，因此无法对其进行详细评论——除了要注意它与 Git 一样，具有用于修订的内容哈希地址；也像 Git 一样，它不会将目录视为第一类对象（并且不能存储空目录）。然而，它比除 Git 之外的任何其他 DSCM 都快，并且比任何竞争对手都具有更好的 IDE 集成（尤其是对于 Eclipse）。鉴于其性能特征（仅略落后于 Git）及其卓越的跨平台和 IDE 支持，Mercurial 可能会吸引拥有大量以 win32 为中心或受 IDE 限制的成员的团队。
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 PQMfor automating merge requests to your shared branches.
从 SVN 迁移的一个问题是 SVN 的 GUI 前端和 IDE 集成比任何分布式 SCM 的更成熟。此外，如果您目前大量使用 SVN 的预提交脚本自动化（即要求在提交可以继续之前通过单元测试），您可能希望使用类似于PQM的工具来自动化对共享分支的合并请求。
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.
SVK 是一个 DSCM，它使用 Subversion 作为其后备存储，并且与以 SVN 为中心的工具有很好的集成。然而，它的性能和可扩展性特征比任何其他主要的 DSCM（甚至 Darcs）都差得多，并且应该避免用于在历史长度或文件数量方面容易增长的项目。
[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].
[关于作者：我在工作中使用 Git 和 Perforce，在我的个人项目和嵌入式库中使用 Bazaar；我雇主组织的其他部分大量使用 Mercurial。在之前的生活中，我围绕 SVN 构建了大量自动化；在此之前，我有 GNU Arch、BitKeeper、CVS 等方面的经验。Git 一开始很令人反感——感觉就像 GNU Arch，因为它是一个概念繁重的环境，而不是为符合用户选择的工作流程而构建的工具包——但从那以后我就非常适应了它]。
回答by Michael La Voie
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.
Ogre 3D 项目的 Steve Streeting 刚刚（2009 年 9 月 28 日）发表了一篇关于这个主题的博客文章，他在文章中对 Git、Mercurial 和 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.
这是一个简短的阅读，我强烈推荐它。
回答by Jakub Nar?bski
What do folks here see as the relative strengths and weaknesses of Git, Mercurial, and Bazaar?
这里的人们认为 Git、Mercurial 和 Bazaar 的相对优势和劣势是什么？
In my opinion Gitstrength 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.
在我看来，Git 的优势在于其简洁的底层设计和非常丰富的功能集。它还具有我认为对多分支存储库和管理分支密集型工作流的最佳支持。它非常快，并且存储库大小很小。
It has some features which are useful but take some effort to be used to them. Those include visibleintermediate 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; detectingrenames 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.
它有一些有用的功能，但需要付出一些努力才能习惯它们。这些包括工作区和存储库数据库之间的可见中间暂存ara（索引），它允许在更复杂的情况下更好的合并解决，增量提交和脏树提交；使用相似性启发式方法检测重命名和副本，而不是使用某种文件 ID 跟踪它们，这种方法运行良好，并且允许责备（注释），它可以跟踪跨文件的代码移动，而不仅仅是批量重命名。
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.
其缺点之一是 MS Windows 支持滞后且不完整。另一个明显的缺点是，它不像 Mercurial 那样有详细的文档记录，并且比竞争对手更不友好，但它会发生变化。
In my opinion Mercurialstrength lies in its good performance and small repository size, in its good MS Windows support.
在我看来，Mercurial 的优势在于其良好的性能和较小的存储库大小，以及对 MS Windows 的良好支持。
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).
在我看来，主要的缺点是本地分支（单个存储库中的多个分支）仍然是二等公民，并且以奇怪而复杂的方式实现标签。它处理文件重命名的方式也不是最理想的（但这种可能性已经改变）。Mercurial 不支持八达通合并（有两个以上的父母）。
From what I have heard and read main Bazaaradvantages 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.
从我所听到和读到的Bazaar 的主要优点是，它可以轻松支持集中式工作流程（这也是缺点，集中式概念在不应该看到的地方可见），跟踪文件和目录的重命名。
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.
Git 是用 C、shell 脚本和 Perl 编写的，并且是可编写脚本的；Mercurial 使用 C（核心，用于性能）和 Python 编写，并提供 API 用于扩展；Bazaar 是用 Python 编写的，并提供用于扩展的 API。
In considering each of them with one another and against version control systems like SVN and Perforce, what issues should be considered?
在考虑它们中的每一个并针对 SVN 和 Perforce 等版本控制系统时，应该考虑哪些问题？
Version control systems like Subversion (SVN), Perforce, or ClearCase are centralizedversion control systems. Git, Mercurial, Bazaar (and also Darcs, Monotone and BitKeeper) are distributedversion 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.
Subversion (SVN)、Perforce 或 ClearCase 等版本控制系统是集中式版本控制系统。Git、Mercurial、Bazaar（还有 Darcs、Monotone 和 BitKeeper）是分布式版本控制系统。分布式版本控制系统允许更广泛的工作流程。它们允许使用“准备好后发布”。它们对分支和合并以及分支密集型工作流有更好的支持。您不需要相信具有提交访问权限的人能够以简单的方式从他们那里获得贡献。
In planning a migration from SVN to one of these distributed version control systems, what factors would you consider?
在计划从 SVN 迁移到这些分布式版本控制系统之一时，您会考虑哪些因素？
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.
您可能要考虑的因素之一是对使用 SVN 进行 intracting 的支持；Git 有 git-svn，Bazaar 有 bzr-svn，Mercurial 有 hgsubversion 扩展。
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 GitComparisonpage on Git Wiki).
免责声明：我是 Git 用户和小时间贡献者，并观看（并参与）git 邮件列表。我只从他们的文档、IRC 和邮件列表上的各种讨论，以及比较各种版本控制系统的博客文章和文章中了解 Mercurial 和 Bazaar（其中一些列在 Git Wiki 的GitComparison页面上）。
回答by Pat Notz
InfoQ has a nice comparison.
InfoQ 有一个很好的比较。
回答by Herge
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.
Mercurial和Bazaar在表面上非常相似。它们都提供基本的分布式版本控制，如离线提交和合并多个分支，都是用 python 编写的，并且都比 git 慢。一旦您深入研究代码，就会有很多不同之处，但是，对于您的日常日常任务，它们实际上是相同的，尽管 Mercurial 似乎有更多动力。
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 不适合初学者。它比 Mercurial 和 Bazaar 快得多，并且是为了管理 Linux 内核而编写的。它是三者中最快的，也是三者中最强大的，相差甚远。Git 的日志和提交操作工具是无与伦比的。但是，它也是使用起来最复杂和最危险的。丢失提交或破坏存储库非常容易，尤其是当您不了解 git 的内部工作原理时。
回答by Martin Geisler
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:
看看 Python 开发人员最近进行的比较：http: //wiki.python.org/moin/DvcsComparison。他们选择 Mercurial 是基于三个重要原因：
The choice to go with Mercurial was made for three important reasons:
- According to a small survey, Python developers are more interested in using Mercurial than in Bazaar or Git.
- Mercurial is written in Python, which is congruent with the python-dev tendency to 'eat their own dogfood'.
- Mercurial is significantly faster than bzr (it's slower than git, though by a much smaller difference).
- Mercurial is easier to learn for SVN users than Bazaar.
选择使用 Mercurial 是出于三个重要原因：
- 根据一项小型调查，与 Bazaar 或 Git 相比，Python 开发人员对使用 Mercurial 更感兴趣。
- Mercurial 是用 Python 编写的，这与 Python 开发人员“吃自己的狗粮”的趋势是一致的。
- Mercurial 比 bzr 快得多（它比 git 慢，但差异要小得多）。
- 对于 SVN 用户来说，Mercurial 比 Bazaar 更容易学习。
回答by DGentry
回答by Davide
A very important missingthing in bazaar is cp. You cannot have multiple files sharing the same history, as you have in SVN, see for example hereand here. If you don't plan to use cp, bzr is a great (and very easy to use) replacement for svn.
bazaar中一个很重要的缺失是cp。您不能让多个文件共享相同的历史记录，就像在 SVN 中一样，请参见此处和此处的示例。如果您不打算使用 cp，bzr 是 svn 的一个很好的（并且非常易于使用）替代品。
回答by sh1mmer
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.
我使用 Bazaar 有一段时间了，我很喜欢它，但它只是较小的项目，即使那样也很慢。很容易学习，但不是超级快。虽然它是非常 x 平台的。
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.
我目前使用 Git，我非常喜欢它，因为 1.6 版使它在使用的命令方面与其他 VCS 更加相似。
I think the main differences for my experience in using DVCS is this:
我认为我使用 DVCS 的经验的主要区别在于：
- Git has the most vibrant community and it's common to see articles about Git
- GitHubreally rocks. Launchpad.net is ok, but nothing like the pleasure of Github
- The number of workflow tools for Git has been great. It's integrated all over the place. There are some for Bzr but not nearly as many or as well maintained.
- Git 拥有最活跃的社区，经常能看到关于 Git 的文章
- GitHub真的很棒。Launchpad.net 还可以，但与 Github 的乐趣完全不同
- Git 的工作流工具的数量非常多。它到处都是集成的。Bzr 有一些，但没有那么多或维护得很好。
In summary Bzr was great when I was cutting my teeth on DVCS but I'm now very happy with Git and Github.
总而言之，当我在 DVCS 上崭露头角时，Bzr 很棒，但我现在对 Git 和 Github 非常满意。
回答by k1udge
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.
Linus Torvalds 在 git 上有很好的视频。他是 Git 的创造者，所以这就是他所提倡的，但在视频中，他解释了分布式 SCM 是什么以及为什么它们比集中式 SCM 更好。有很多比较 git（mercurial 被认为是可以的）和 cvs/svn/perforce。观众也有关于迁移到分布式 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.
我发现这个材料很有启发性，我被卖给了分布式 SCM。但是，尽管 Linus 做出了努力，我的选择还是反复无常。原因是 bitbucket.org，我发现它比 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.
在这里我需要说一句警告：Linus 的风格相当激进，我认为他想搞笑但我没有笑。除此之外，如果您不熟悉分布式 SCM 并考虑从 SVN 迁移，那么该视频也很棒。
