【导语】“小面狗”通过精心收集，向本站投稿了4篇分布式版本控制系统入门：学习和对比Bazaar、Mercurial和Git的使用方法，这里给大家分享一些分布式版本控制系统入门：学习和对比Bazaar、Mercurial和Git的使用方法，供大家参考。
- 目录
篇1：分布式版本控制系统入门：学习和对比Bazaar、Mercurial和Git的使用方法
简介：您是否对分布式版本控制感兴趣，但是又被一大堆行话弄糊涂了？本文介绍三种主要的系统 （Git、Mercurial 和 Bazaar），讨论采用分布式工作流的一些优点，比较分布式版本控制的常用操作，
简介
在过去几年，对于分布式版本控制可以给开发过程提供的益处有许多争论。最近，分布式 工具已经很成熟了。尽管分布式工具的一些优点最初可能不明显，但是从长期来看，它们提供的灵活性是 非常有意义的。阅读完本文之后，您应该能够开始使用分布式版本控制系统，基本了解分布式模型能够提 供的优点。
围绕分布式版本控制的争论主要集中在不再需要的中心服务器。这是一个非常独特的 特性，对于一些开发人员组很重要，但是它的真正价值在于，它允许开发人员组实现他们选择的几乎任何 工作流。它能够完成很多事情，比如传统的集中式模型，或两个开发人员在咖啡馆通过无线连接协同工作 ，等等。
允许开发人员以各种新的方式工作，这是分布式版本控制真正令人兴奋的特点。实际上 ，在本文末尾会介绍如何实现这样的“咖啡馆”工作流。这对于作家、学校教师和 Linux® 内核开发人员都有益处。
什么是分布式版本控制？
分布式版本控制 (DVCS) 是一种不需要中心服务器的管理文件版本的方法，但是它也可以使用中心服务器。更改可以被合并到 DVCS 的任何其他用户的系统中，因此可以实现非常灵活的工作流。
DVCS 的两个主要优点是：它 比集中的版本控制更灵活，因为它除了支持传统的（集中式）工作流，还支持其他各种工作流；它比集中 式服务器快得多，因为大多数操作在客户机本地进行，而不需要网络操作。
DVCS 和集中式版本控 制系统的主要差异
在 DVCS 和集中式版本控制系统之间有三个关键差异。第一个差异是，DVCS 通 过本地提交支持离线工作，这是由 DVCS 的操作方式决定的。这与集中式版本控制完全不同，集中式版本 控制要求通过到中心服务器的连接执行所有操作。这种灵活性让开发人员在飞机上也能够像在办公室中一 样轻松地工作，可以一次又一次地进行提交。
第二个差异是 DVCS 比集中式系统更灵活，因为 DVCS 支持许多不同类型的工作流，从传统的集中式工作流到纯粹的特殊工作流，再到特殊工作流和集中 式工作流的组合。这种灵活性允许通过电子邮件、对等网络和开发团队喜欢的任何方式进行开发。
第三个差异是 DVCS 比集中式版本控制系统快得多，因为大多数操作在客户机上进行，速度非常 快。另外，在需要进行推（push ）操作（与另一个节点通信）时，速度也更快，因为两个客户机机器上 都有完整的元数据。速度差异相当显著，根据使用本地存储库还是网络存储库，DVCS 比 Subversion 快 大约 3-10 倍。
分布式版本控制工作流
因为 DVCS 非常灵活，可以实现各种各样的工作流 ，但是由于篇幅有限，本文只讨论两种工作流。首先讨论最常用的工作流之一 Partner 工作流。按照 Partner 工作流，一个开发人员启动一个项目，然后进行分支。然后，在不同开发人员工作的分支之间来 回合并更改。
第二种常用的工作流是通过本地提交使用集中式服务器。在这种工作流中，开发人 员的工作方式与使用集中式 subversion 存储库时非常相似，但是他们进行本地提交，然后把最终更改推 到集中式服务器。这种工作流有许多变体，包括与 Partner 工作流结合使用。重要的是，可以采用许多 种工作方式，通过使用 DVCS，可以灵活地选择最适合自己的工作方式。
快速入门指南
了 解一种新技术的最好方法之一是实际使用它。在本节中，简要介绍 Mercurial、Bazaar 和 Git 中的常用 操作，您可以试试这些操作：
Mercurial
安装：sudo easy_install-2.5 mercurial
建立项目目录：mkdir hgrepo; cd hgrepo
初始化项目：hg init
添加文 件：touch foo.txt; hg add foo.txt
提交：hg commit -m “added foo.txt” commit
抓取共享的存储库：hg clone ssh://example.com//projects/hgrepo
本地提交更 改：hg -ci -m “adding a change”
把更改推到服务器：hg push
以补丁形式查 看未处理的更新：hg incoming -p
从服务器下载更新：hg pull
应用更改：hg update
合并冲突：hg merge
合并两个不相关的远程存储库：hg pull -f ssh://example2.com//projects/hgrepo
Bazaar
安装：sudo easy_install-2.5 bzr
建立项目目录：mkdir bzrrepo; cd bzrrepo
初始化项目：bzr init
添加文件 ：touch foo.txt; bzr add foo.txt
提交：bzr commit -m “added foo.txt” commit
抓取共享的存储库：bzr branch bzr+ssh://example.com/projects/gitrepo
本地 提交更改：bzr -ci -m “adding a change”
把更改推到服务器：bzr push
从服 务器下载更新：bzr pull
应用更改：bzr update
合并冲突：bzr merge
Git
安装：下载最新的 tar 文件 kernel.org/pub/software/scm/
建立项目目录：mkdir gitrepo; cd gitrepo
初始化项目：git init
添加文件：touch foo.txt; git add foo.txt
提交：git commit -m “added foo.txt” commit
抓取共享的存储库： git clone ssh://example.com/projects/bzrrepo
本地提交更改：bzr -ci -m “adding a change” commit
把更改推到服务器：bzr push
从服务器下载更新：bzr pull
应用更改：bzr update
合并冲突：bzr merge
转换工具和与 subversion 的集成
这 三种 DVCS 都能够把现有的 subversion 存储库轻松地转换为各自的格式，甚至可以在不同的 DVCS 之间 进行转换，
这使开发人员能够方便地试用 DVCS 或从一种 DVCS 转移到另一种 DVCS。
例如，对于 Mercurial，可以使用工具 hgimportsvn 和 hgpullsvn 与现有的 subversion 存储库通信，创建新的 hg 存储库和历史。tailor 工具是一种通用的存储库转换工具。
另一种有意思的试用方法是集成 DVCS 与现有的 subversion 存储库。对这种方法的详细讨论超出了本文的范围，但是 参考资料 给出了 一些工具的链接，这些工具可以在 subversion 分支与 Git、Bazaar 和 Mercurial 之间进行双向操作。
第三方托管选项
如果开放源码或商业开发人员不希望或不需要管理自己的集中式 “ 集线器”，那么可以选用流行的托管站点托管自己的 Git、Bazaar 或 Mercurial 项目。对于 Mercurial，流行的免费和付费托管站点是 Bitbucket。对于 Git，可以使用 Github；对于 Bazaar，可 以使用由 Canonical 发起的 Launchpad。
提示：“咖啡馆” Mercurial 工作流
图 1. 咖啡馆工作流
如果希望实现安全的 特殊版本控制工作流，让两个开发人员可以在咖啡馆中通过无线网络一起工作，那么可以试试下面的方法 。
第一个用户使用 Mercurial 创建一个存储库：
mkdir /tmp/myhgrepo
cd /tmp/myhgrepo
hg init
然后，通过 Web 作为只读共享共享它：
hg serve
第二个用户使用以下命令克隆这个存储库：
hg clone example.com:8000
注意：这是另一台机器的 IP 地址或本地主机名。在 OS X 上，可以通过对 your-machine-name.local 使用 Bonjour 获得这一信息。
第二个用户进行 他需要的更改，然后作为只读的 HTTP 共享提供他的存储库：
example.com:8000
第一个用户对第二个用户的存储库拷贝执行 hg 拖 操作：
hg clone example2.com:8000
每个开发人员都是安全的， 因为他们只在需要更新自己的本地文件系统时才对对方的存储库进行拖操作。
结束语
本文 讨论了分布式版本控制能够提供的价值，比较了三种主流工具 Git、Mercurial 和 Bazaar 之间的差异。 如果您不太熟悉版本控制，那么应该继续学习版本控制、钩子和插件以及它们能够提供的功能。
如果您是老手，那么应该试试这些工具，寻找最适合自己的工具。请通过 参考资料 中的链接详细了解各 种分布式版本控制系统以及别人的使用经验。
篇2：分布式版本控制系统 Mercurial
Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强，相对于传统的版本控制，具有如下优点：
更轻松的管理。
传统的版本控制系统使用集中式的 repository，一些和 repository相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的 repository，管理员只需协调同步这些repository，
更健壮的系统。
分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。
对网络的依赖性更低。
由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。
项目主页：www.open-open.com/lib/view/home/1329456066406
篇3：分布式版本控制系统 Git 介绍
Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理，
Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统，
尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如，X.org 最近就迁移到 Git 上来了，很多 Freedesktop.org 的项目也迁移到了 Git 上。
Git与CVS的区别
分支更快、更容易。
支持离线工作；本地提交可以稍后提交到服务器上。
Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
Git 中的每个工作树都包含一个具有完整项目历史的仓库。
没有哪一个 Git 仓库会天生比其他仓库更重要。
项目主页：www.open-open.com/lib/view/home/1326031085515
篇4：分布式版本控制系统 Mercurial与TortoiseHg
Mercurial是我最喜欢的下一代分布式版本控制系统，简单，快速，高效，强大。
最主要的是他的图像客户端TortoiseHg，TortoiseHg就能把所有的比下去了。
为什么不是SVN
- SVN服务器管理复杂。
- SVN不能支持代码重构，当移动文件夹时会出错。
- SVN不能支持离线操作。当在保密环境下或者在家里，不能同步代码。
- SVN在网络故障的情况下产生悲剧。
- SVN速度超慢。提交、更新、浏览历史的速度都很慢。
- SVN强迫使用者即时处理冲突，然后才能提交。导致代码不能即时提交。
- SVN不能恢复到历史版本。SVN记录了单个文件的历史版本，但没有记录全局版本，不能恢复到上次的状态。
- SVN经常莫名奇妙的不能提交。
- SVN不知道为什么老需要手动clearnup。
- SVN自建分支后无法进行合并。
- SVN不能主动推送改变。
为什么不是Git
Git没有好的图像客户端。我们使用代理服务器上网，我在Git上从来没有成功配置过代理服务器（估计是因为我们的用户名中有个@的原因），
更重要是Git比Hg的学习曲线更陡峭。
什么是分布式版本控制
分布式版本控制(DVCS)是一种不需要中心服务器的管理文件版本的方法。它比集中的版本控制更灵活，支持各种工作流；它比集中式服务器快得多，因为大多数操作在客户机本地进行，而不需要网络操作。
Mercurial的基本概念
由于Mercurial是分布式的，所以每个库都是原始库的完整拷贝，每个库都既是客户端也是服务端。
clone：复制一份原始库的完整副本。
commit：提交当前改变到本地库。
changeSet：每一次提交都会生成一个改变集。
update：将当前工作文件还原到给定提交点。
push：将当前改变集推送到别的库。
pull：将别的库的改变集拉回。
push和pull组成一组同步操作，用于两个库之间交互数据。
commit和update组成对当前工作文件的操作，都是在本地完成，不需要网络。
TortoiseHg使用入门
克隆库
提交改变
更新到指定改变集
与远程库同步
★ Git 学习总结
★ 行楷书法入门学习
分布式版本控制系统入门：学习和对比Bazaar、Mercurial和Git的使用方法（精选4篇）
