分布式版本控制软件水银(Mercurial)使用指南0.docxVIP

分布式版本控制软件水银(Mercurial)使用指南0 　　当我们公司的程序员决定将版本控制工具从SVN转为水银时，我很迷惑。 　　我首先想到的是所有不能换工具的理由。“我们必须要有一个中心仓库，那样才安全，”我说。然而我错了。在水银中，每个开发人员的硬盘中都存有仓库的一份拷贝，那样才真的是安全。况且几乎每个用水银管理的团队都用了中心仓库。 　　“分布式版本控制的麻烦在于它制造了太多的分支，”我说，“而分支往往带来麻烦。”结果，这个想法又错了。连续挫败。分支在SVN上造成问题是因为SVN没有存储足够的信息来进行合并操作。在水银中，合并不会带来任何损失且很容易，因此分支是常用而无害的东西。 　　最后我说：“好吧，我会用它的，但是别指望我弄懂它。”然后我让Jacob帮我弄一张小抄，列出所有SVN常用操作在水银上的替代。 　　现在，我可以给你展示一下这张小抄，但我想还是算了。因为它把我的脑子搞坏了几个月。 　　如果你一直是用SVN的，那说好听点，你会脑残。不好意思，这似乎并不好听。你需要来点再教育。我脑残了6个月，在这6个月中，我觉得水银比SVN复杂多了。而现在想起来，都是因为我没有理解其精髓。而一旦我了解到了，水银就变得异常简单。 　　所以我为你写下这份教程。我小心翼翼地绕开SVN来解释这个系统，因为我不想你也像我一样脑子灌水。因为这个世界已经够二了。对于那些也是从SVN转来的朋友。我写这一章的目的就是为了试着替你清洗脑伤以使得你可以如一张白纸般学习水银。 　　如果你完全没有使用过SVN，那么你可以直接跳到下一章而不会错过任何事。 　　准备好了吗?OK，让我们以一个简短的测试开始。 　　问题1. 你会一次就写出完美的代码吗? 　　如果你的回答是“是的”，那么你是一个骗子一个作弊生。你的测试没有通过。重新测试吧。 　　新的代码总是会有问题。需要花些时间花些努力才能让它较好地运行。而在这之前，你的代码可能会给同一团队的其他开发者造成困扰。 　　下面SVN的方式： 　　当你把你的新代码check in，所有其他人都得到了它。 　　由于你写的新代码会有问题，因此你有两个选择。 　　你可以check in有问题的代码并让所有人都抓狂，或者 　　你可以知道它完全没有问题了再check in。 　　SVN往往给你这样的可怕困境。要么仓库中由于新代码的提交充满了各种bug，要么新代码没办法放到仓库里面去。 　　作为SVN的使用者，我们是如此习惯于这样的困境以致于基本不会去想象没有这个困境的样子。 　　SVN的团队经常数日或数周都不check in任何东西。在SVN的团队中，新手更是不敢check in任何东西，因为害怕破坏构建，或者害怕被上司骂。Mike有一次非常生气，因为有一次checkin破坏了整体的构建。他冲到实习生的隔间，把他桌子上的东西推落一地，然后咆哮道：“这是你的最后一天了!”(当然没有成为实习生的最后一天，但是那个可怜的实习生显然哭了鼻子。) 　　这所有的恐惧导致人们几周几周地不敢使用版本控制工具来控制自己的版本，然后再找个高手帮助他们把代码check in。如果你没办法用版本控制工具，你又为何使用它? 　　下图是SVN生活下的简单示例。 　　在水银中，每个开发者在他们的电脑中都有它们自己的仓库： 　　这样，你就可以把代码提交到你的私人仓库，并且享受版本控制带来的好处。每当你到达了一个代码好了一点点的逻辑点，你就可以提交你的代码。 　　一旦你的版本变的稳固了，并且希望别人也能使用你的新代码时，你就可以把你的变更从你的仓库推送到中央仓库。这样，别人就都可以通过拉取来看到你的代码了。 　　水银将提交新代码的操作与影响其他人的操作分离了。 　　这就意味着你可以在其他人不知情的前提下提交(hg com)。当你已经有了一堆变更，并且你觉得已经稳定了且希望给别人看时，你可以推送(hg push)它们到主仓库中。 　　一个更大的概念上的差别 　　你知道如何给每条街命名吗? 　　在日本，他们往往只是在街与街之间用数字标明街区。只有非常非常重要的街才会有名字。 　　SVN与水银的差别有些类似。 　　SVN喜欢考虑版次。一个版次是说在某个特定的时间点，整个文件系统看起来是什么样的。 　　在水银中，考虑的是变更集。一个变更集是两个版次间的差异列表。 　　半斤与八两：区别在哪里? 　　区别在这里。想象一下你和我都在一段代码上进行工作，并且我们对那段代码进行了分支。我们分别在这段代码上做了很多工作，也改变了很多，所以它们越走越远了。 　　当我们想要合并时，SVN试着去看两个版本——我改的代码，和你改的代码——它尝试着去猜测如何把他们打碎拼装成一个大块。它往往会失败，产生整页整页的“合并冲突”。而它们往往不是真的冲突，而是SVN无法认出我们干了什么。 　　另