版本号控制系统(Version Control System,VCS)能够帮助我们记录和跟踪项目中各文件内容的改动变化。它能够帮我们保存项目的各个版本号。以及改动原因，我们能够借用此工具回到项目以前的某个状态。除此之外，版本号控制系统也是帮助人员进行协作开发的利器。

     Git是一个分布式版本号控制系统(Distributed Version Control System,DVCS)。与传统的集中式版本号控制系统(如CVS、Subversion和ClearCase)相比，Git具有下面优势：

• 分布式体系结构：能够全然断网工作，不受网络连接的限制
• 分支与合并操作非常easy：创建分支简单、经济、高速，Git仅仅会保存与主干的差异，这与其它版本号控制系统不一样。

  Git把分支上全部修改合并回父分支，即使多次。也仅仅是一眨眼的功夫

• 跟Subversion进行交互：Git能够从SubVersion的版本号库中导入全部的历史，并把你在Git中的修改发送回Subversion的版本号库

     版本号库(Repository)是版本号控制系统用来存储全部历史数据的地方。大多数版本号控制系统在版本号库中存储各个文件的当前状态、历史改动时间、谁做的改动、以及改动的原因、还有改动的内容。

     常见的版本号控制系统能够分为两种类型。

一种是集中式版本号库(Centralized Repository)，全部的程序猿都会把他们的改动提交到server上的一个公共版本号库。详细来说，每个程序猿在本地有一个工作文件夹树，其内容是该版本号库中最新的代码。

当他们在工作文件夹树中完毕代码的改动后。就把改动提交回该版本号库中。这样的方式有一定局限性，在本地工作文件夹树中。仅仅能看到代码的最新版本号。假设想查询历史改动记录，就必须与server上的版本号库打交道，就必需要使用网络。

假设没有网络，也无法记录当前已改动后的项目版本号。

     还有一种就是分布式版本号库(Distributed Repository)。使用分布式版本号控制系统，在本地就有自己的版本号库，全部的历史记录都会记录在本地的版本号库中，提交代码的时候不用连接到远程版本号库，而是记录在本地的版本号库中。git就是这种一种版本号控制系统。

那么git是如何将本地的改动上传到项目的主版本号库中的呢？有两种方式：1.
通过push操作直接把改动上传到主版本号库。2.生成包括少量改动的补丁包，把补丁包提交给项目维护人员。再由他更新主版本号库。

     工作文件夹树是版本号库的一个"断面视图"。它包含了开发该项目所须要的所有文件。包含源码文件、构建文件、单元測试文件等。

     在Git中，版本号库不在server上，而存储在本地工作文件夹树中的".git"文件夹中。工作文件夹树是怎么创建出来的呢？有两种方法。1. 用Git相关的命令初始化版本号库，也就是生成".git"文件夹。于是".git"文件夹的父文件夹就成了工作文件夹树。2. 克隆(Clone)一个已有的版本号库。也就连带创建了对应的工作文件夹树。

     克隆一个已有的版本号库，就是创建该版本号库的一个拷贝，并把版本号库中主分支(Master Branch)的内容检出(check out)到工作文件夹树。在Git中，检出是指把工作文件夹树更新，并使其内容与版本号库中某个特定的历史版本号同样。

     代码在修改之后。须要提交(commit)这些修改。每次提交操作都使得版本号库中新增一个版本号(Revision)。

除了记录修改内容本身外。版本号库还记录修改的日志信息(log
message)或称提交留言(commit message)，这是代码的变动原因。

     我们在开发的过程中，有时须要将本地的修改共享。

为此，须要把变动推入(push)上游版本号库(upstream repository)。

上游版本号库是一个公共版本号库。

     与push相反。我们也应该可以把公共版本号库中内容取到本地版本号库中来。须要两步操作。

第一步。把修改取来(Fetch)，把远程版本号库中的版本号和分支拷贝到本地版本号库中。第二步。在本地版本号库中，把从远程版本号库里取来的修改与自己本地的修改合并(Merge)。一般来说，取来操作和合并操作总是先后运行的。因此，在Git中可以用一个命令完毕这两步操作：拖入(Pull)。

     

     标签以一个简单的名称(即标签名)来标记版本号库历史中某个特定的点。它能够是一个重要的里程碑，比方对外正式公布的版本号；也能够是相对普通的时间点。比方在修复一个缺陷后打个标签。

     本质上。标签是一个对于使用者来说易于理解易于记忆的名字。用来标识版本号库中一个难读难记的内部版本号号，以此帮助使用者跟踪版本号历史。

     使用分支(branche)能够使你的项目有多条路径能够前进。下图展示了分支原理。主分支(Master Branch)是研发的主线，一些版本号控制工具也把主分支称作主干(trunk)。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvVHJveV9f/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

     分支很*，分支后面能够合并到主分支上。也能够选择不合并。

甚至。你也能够把分支看成是还有一个主干。别人能够从你的分支上再拉取一个分支。

     合并操作会把两条及两条以上的分支合并到一起。Git会比較各分支上的变化，确定变化在哪里发生、哪个文件的哪个位置。当不同的变化发生在文件的不同部分时，Git可以自己主动合并。但当发生在同一位置时。就会提示冲突，等待人工介入。而合并的全部操作会被Git所记录下来，便于以后能回归(revert)或者查看。

     在本章中，介绍了Git中最核心的几个概念：版本号库、版本号、分支、合并。版本号库是项目的相关内容的容器，而版本号是项目在每一个时刻下的视图。分支、合并则为团队之间的协作提供支持。