开源版教材本控制：git权威指南-toc目录及前言.pdfVIP

前言 前言 版本控制是管理数据变更的艺术，无论数据变更是来自同一个人，还是来自不同的人（一个团 队）。版本控制系统不但要忠实记录每一次数据变更，还要能够帮助还原任何历史改动，以及实现 团队的协同工作等。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 上。但随着新 1 /projects/freemind-mmx/ Git 权威指南 i 前言 的开发人员的加入，问题出现了，即一个人使用 Hg 和 MQ 都很好，但多个人使用则出现难以协 同的问题。于是我们大胆地采用 Git ，并在实践中结合 Topgit 等工具进行代码的管理。再一次， 也许是最后一次，我们的代码库迁移到 Git 。 最早认识分布式版本控制，源自于我们看到了众多开源项目的版本控制系统大迁移，这场迁移 还在进行中。 MoinMoin 是我们关注的一个开源的维基软件，2006 年，它的代码库从 SVN 迁移到 1 Hg 。 Mailman 同样是我们关注的一个开源邮件列表软件。2007 年，它的代码库从 SVN 迁移 2 到 Bazaar 。 Linux 采用 Git 做版本控制系统（一点都不奇怪，因为 Git 就是 Linus Torvalds 开发的）。 Android 是最为流行的开源项