版本控制之道——使用Git_样章

精彩内容抢先看——

第1章

Git的版本控制之道

Version Control the Git Way

版本控制系统（Version Control System，VCS）可以帮助我们记录和跟踪项目中各文件内容的修改变化。它最简单的、手工的实现形式是：复制文件以备份，在备份文件的文件名中添加上时间和日期。

然而，为了效率起见，我们希望这类操作在某种程度上是自动的。这是我们需要版本控制工具的原因，这类工具能够自动地备份和跟踪项目中所有代码的修改。

分布式版本控制系统（Distributed version control system，DVCS）也是这样，它的主要目标仍然是帮助记录和跟踪项目中所做的修改。而它与传统版本控制系统的区别在于，开发人员相互同步修改内容的方式不同。

本章将研究什么是版本控制系统，以及分布式版本控制系统——特别是Git——与传统的集中式版本控制系统的区别。

本章内容如下：

l  什么是版本库。

l  如何判断该存储些什么。

l  什么是工作目录树。

l  如何管理和同步文件。

l  如何跟踪项目、目录和文件的内容。

l  如何使用标签来标识项目里程碑。

l  如何使用分支来跟踪并行开发。

l  什么是合并。

l  Git中的锁机制。

这些论题全都是围绕着版本库展开的。所以，让我们从学习版本库开始。

1.1  版本库

The Repository

版本库（Repository）是版本控制系统用来存储所有历史数据的地方。大多数版本控制系统在版本库中存储各个文件的当前状态、历史修改时间、谁做的修改，以及修改的原因。

版本控制系统就好比是银行保险箱，而它所保存的历史信息就好比对账单。每当存入一笔存款时，或者用版本控制系统的行话来说，每当进行一次提交（Commit）的时候，版本控制系统就会在“对账单”上添加一个条目，并且把提交的内容保存在版本库里。

在早期的版本控制系统中，必须登录版本库所在的服务器，才能访问这些版本库。这会带来可扩展性方面的问题。而较新的版本控制系统，比如CVS和Subversion，解决了这样的问题。这类版本控制系统允许程序员通过网络来获取版本库中的代码，并在修改后提交回来。

这类版本控制系统属于集中式版本库（Centralized Repository）模式。在这种模式中，所有的程序员都会把他们的改动提交到服务器上的一个公共版本库中。具体来说，每一个程序员在本地有一个工作目录树，其内容是该版本库中最新的代码。当他们在工作目录树中完成代码修改后，就把改动提交回该版本库中。

这类使用集中式版本库的版本控制系统与早期的直接访问式版本控制系统相比，有很大进步，但仍有其局限性。首先，在本地工作目录树中，只能看到代码的最新版本。如果想查询历史修改记录，就必须与服务器上的版本库打交道。这就带来另一个问题：同远程的版本库连接，通常须要使用网络。

在这个“永不断线”的宽带互联网时代，我们几乎忘记了有时候不能上网。以本书的写作过程为例，有时候是在家中，有时候是在咖啡店里，有时候是在飞机上，还有的时候是在长途汽车上。甚至，本书最后的修订是在密苏里州奥扎克族印第安人的小木屋里。

如果使用分布式版本控制系统，就不会遇到不能上网所带来的问题。这是以Git为代表的分布式版本控制系统最大的优势。使用分布式版本控制系统，每个人都会在本地有自己的版本库，而不是连接到服务器上的一个公共的版本库。所有的历史记录都存储在本地的版本库中。向版本库提交代码无须连接远程版本库，而是记录在本地的版本库中。

让我们回到银行保险箱这个类比看一下。集中式版本控制系统就好比是程序员们共用一个保险箱。而分布式版本控制系统就好像是每个程序员都有他自己的个人保险箱。

那么，在分布式版本控制系统中，程序员之间如何传递各自的修改，如何同步呢？程序员还是将修改上传到项目主版本库。这有两种实现方法：可以通过Git的“推入”（Push）操作直接把修改上传到主版本库，也可以生成包含少量修改的补丁包，把补丁包提交给项目维护人员，再由项目维护人员更新主版本库。

1.2  版本库中存储什么

What Should You Store?

对此问题的简短回答：所有内容。

稍微复杂一些的回答是：存储项目开发所必需的所有内容。这使得程序员能够修改代码，编译构建，使项目前进。显然，首先要存储的是项目源代码，否则，既无法修复缺陷也无法继续开发新功能。

大多数项目都有一些构建文件。常见的有：Makefile、Rakefile及Ant的build.xml。这些文件都要放入版本库，以方便源代码编译构建。

版本库中其他常见存储内容还有：配置文件样例、各类文档、程序使用的图片，当然还有单元测试脚本。

要判断哪些内容应该纳入版本控制很简单，自己想一下，“如果没有某样东西，我能在这个项目中工作吗？”如果答案是否定的，那么这样东西就应当纳入版本控制。

但凡事皆有例外：项目中使用的开发工具，通常不用放到版本控制中去。比如，Ant的“build.xml”应该放到版本控制中，但Ant工具本身不需要。

这个例外并不是这么严格的。可以考虑把Ant、JUnit等工具都放入版本库中，以保证大家都使用相同版本的工具。当然，最好把它们与项目本身的内容分开存放。

1.3  工作目录树

Working Trees

至此，我们已经介绍了版本库，以及应该在其中存储哪些内容。下面将介绍工作目录树（Working Tree），也就是程序员进行程序开发的地方。

工作目录树是版本库的一个“断面视图”。它包括了开发该项目所需要的全部文件，包括源代码文件、构建文件、单元测试文件等。

一些版本控制系统把工作目录树称为工作拷贝（Working Copy）。Git新手经常会混淆Git中的版本库和工作目录树。因为在Subversion等传统的版本控制工具中，工作目录在本地，版本库在服务器上，而Git中并非如此。

在Git中，版本库不在服务器上，而存储在本地工作目录树的“.git”目录中。这意味着，要想知道历史信息，只和本地的版本库打交道即可，无须与服务器上的版本库通信。

那么，工作目录树最初是怎么创建出来的呢？有两个方法：第一个方法是用Git相关命令初始化版本库，也就是生成“.git”目录，于是“.git”目录的父目录就成了工作目录树。第二个方法是克隆（Clone）一个已有的版本库，也就连带创建了相应的工作目录树。

克隆一个已有的版本库，就是创建该版本库的一个拷贝，并把版本库中主分支（Master Branch）的内容检出（Check out）到工作目录树。在Git中，检出是指把工作目录树更新，使其内容与版本库中某个特定的历史版本相同。关于克隆版本库，将在7.2节“克隆远程版本库”（第103页）中详细介绍。

跟踪变更是版本控制系统（CVS）的核心功能。到目前为止，我们已经介绍了版本库和工作目录树——也就是版本库的一个“断面视图”——但还没有讲解变更相关的话题，这将在下一节中介绍。

 

更多内容请下载阅读：http://download.csdn.net/source/2443107

------------------------

本书豆瓣主页：http://book.douban.com/subject/4813786/

互动网购买链接：www.china-pub.com/196738