开源版本控制：Git权威指南-TOC目录及前言.pdf

前言前言版本控制是管理数据变更的艺术无论数据变更是来自同一个人还是来自不同的人（一个团队）。版本控制系统不但要忠实记录每一次数据变更还要能够帮助还原任何历史改动以及实现团队的协同工作等。Git就是版本控制系统中的佼佼者。我对版本控制系统的兴趣源自于我在个人知识管理中的实践其核心就是撰写可维护的文档并保存于版本控制系统中。可维护文档的格式可以是DocBook、FreeMind、reStructuredText等。我甚至还对FreeMind加以改造以便让其文档格式更适合于版本控制系统这就是我的第一个开源实践：托管于SourceForge上的FreeMind-MMX项目1。文档的书写格式问题解决之后就是文档的存储问题了。通过版本控制系统很自然地就可以实现对文档历史版本的保存但是如何避免因为版本控制系统瘫痪而导致数据的丢失呢？Git用其崭新的分布式的版本控制设计提供了最好的解决方案。使用Git我的知识库不再只有唯一的版本库与之对应而是可以通过克隆操作分发到不同的磁盘上、主机上克隆的版本库之间通过推送（PUSH）和拉回（PULL）等操作进行同步数据安全得到了极大的提升。在版本控制系统的忠实呵护下我的知识库中关于Git的FreeMind脑图日积月累变得越来越详实、越来越清晰最终成为这本书的雏形。版本控制还能决定项目的成败甚至公司的生死此言不虚。我在推广开源的项目管理工具和对企业进行顾问咨询的过程中看到过太多的团队因为版本控制系统的管理混乱导致项目延期、修正的Bug重现、客户的问题不能在代码中定位无论他们用了什么版本控制系统开源的或是商业的。而我的公司也同样经历了代码管理的生死考验。因为公司的开发模式主要是基于开源软件的二次开发在最早使用SVN(Subversion)做版本控制时很自然使用了SVN卖主分支模型来管理代码。随着增加和修改的代码越多和开源软件上游的偏离也越远当上游有新版本发布时最早可能只用几个小时就可以将改动迁移过去但是如果对上游的改动多达几十甚至上百处时迁移的过程会异常痛苦基本上和重新做一遍差不多。那时似乎只有一个选择：不再和上游合并不再追踪上游的改动而这和公司的价值观“发动全球智慧为客户创造价值”相背。迷茫之中分布式版本控制系统飘然而至原来版本控制还可以这么做。最先尝试的分布式版本控制系统是Hg（Mercurial）尤其是当发现Hg和MQ（Hg的一个插件）这一对儿宝贝的时候让我如获至宝。逐渐的公司的版本库都迁移到Hg上。但随着新1http://sourceforge.net/projects/freemind-mmx/Git权威指南i前言的开发人员的加入问题出现了即一个人使用Hg和MQ都很好但多个人使用则出现难以协同的问题。于是我们大胆地采用Git并在实践中结合Topgit等工具进行代码的管理。再一次也许是最后一次我们的代码库迁移到Git。最早认识分布式版本控制源自于我们看到了众多开源项目的版本控制系统大迁移这场迁移还在进行中。‰MoinMoin是我们关注的一个开源的维基软件2006年它的代码库从SVN迁移到Hg1。‰Mailman同样是我们关注的一个开源邮件列表软件。2007年它的代码库从SVN迁移到Bazaar2。‰Linux采用Git做版本控制系统（一点都不奇怪因为Git就是LinusTorvalds开发的）。‰Android是最为流行的开源项目之一因为潜在的市场巨大已经吸引越来越多的开发者进入这个市场而Android就是用Git维护的。当开源软件纷纷倒向分布式版本控制系统的大旗（尤其是Git）的时候公司也在行动了尤其是涉及异地团队协同以及Android核心代码定制开发的公司。对于一些因保守而