git学习总结

版本控制器是我们最为常用的工具之一，而GIT又是其中的佼佼者，今天就来总结一下我学习到的那一部分。较为基础，仅适小白解惑，如有任何错误，请帮忙指出谢谢。

1.Git功能理解：

版本控制器：顾名思义以为帮助我们控制代码版本，并且可以回溯之前的版本，并可以统筹多人开发多人提交等等的一系列的状况。使得我们的团队开发将会更为的有效率。

　　　　版本控制器其实还是分多种类型的，分类如下:

- 集中化版本控制系统：就是东西都在集中一台机器上面，然后拷贝快照到本地，然后在完成修改之后进行提交，但是有一点不好的就是，当存储版本的机器蹦蹦哒的时候，那几端没有代码可写，没有东西可修改的时间内就知道急迫了，当BOSS在后面黑着连追讨的时候就更是心慌了。。。
- 分布式版本控制系统：就是把服务器上面的版本镜像到本地，然后在本地修改。因此，如果服务器出现了错误的话，任何一个镜像文件都是可以回复服务器端的内容的。当然，由于其是本地内容进行相关的处理的，可以分成多镜像不同走向的形式来进行开发。
版本控制方式：Git实际上自这一块进行了一种全新的处理方式。一般来说，版本控制器是以变更列表的方式来进行版本变更信息的存储，之后虽则内容的累加，修改列表的内容也会越来越多。而GIT则是使用快照的方式来进行信息的修改的表示方式。每当我们提交的时候git是加上是为当前的额所有文件进行一次快照并存储快照的索引。当然如果文件没有修改的话则不存储新的快照而是直接的引用前一次的当前文件的快照。当然git所有的操作实际上都是可以本地完成的。
GIT内容在提交的时候会计算校验和，并使用校验和来带表当前内容的引用。（仅供了解：Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。这是一个由 40 个十六进制字符（0-9 和 a-f）组成字符串，基于 Git 中文件的内容或目录结构计算出来。）
GIT控制的文件内容有三种状态的：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。P.S.这一概念还是比较重要的，为后面理解其用法做基础。就如图中的内容，checkout到工作本地，之后进行修改，这个时候其实是一种已经提交的源文件的状态，而当用户对当前的文件作出任意的修改的时候，用户工作使用的文件实际上就已经是处于一种已修改的状态，然后使用git add命令，git会将当前的文件添加到staging Area，也就是缓存地带，当我们最后被使用commit内容的时候，git将会把当前的缓存中的内容提交到版本存储仓库（repository）。下面一张图将会更清晰的展示git中管理的文件的状态。
最后原生GIT内容使用命令行就不需要我多说了吧，当然也有一些git图形化的工具，也是不错的，对于不想使用或是使用命令行感觉很别扭的人来说还是不错的。

2.GIT CONFIG配置内容。

内容安装这里就不详细的讲解了，网上一搜一大堆。安装好后打开我们的git-bash，就可以开始使用了。
当我们安装完成git之后首要的任务并不是去直接开始项目版本的初始化等等内容，而是应该首先配置好一些在使用git的时候需要用到的参数，使用git Config命令命令行就是吊炸天有没有这样的感觉，输入git config --help内容可以看见如图的内容。这是命令的基础说明和使用方式，其表明git config命令是用来进行获取和设置版本库或是全局项属性的命令。
在使用git的时候，git进场会使用到两个参数，用户名称以及用户的邮箱，因为每次提交版本的时候，在本地的版本仓库，每一个版本的代号计算就要使用到这些数据。甚至在提交到远程版本库的时候，或者是生成SSH key的时候也会是用到这些内容的。纳闷我们要如何设置这些内容呢。上图。
上面所说的内容实际上是配置全局的用户信息内容，我们其实也是可以设置的东西其实并不止这些。例如文本编辑器，当git需要你输入信息的时候会使用到它。git默认的文本编辑器是VIM，如果你需要设置的话可以使用图中的命令，当然需要你修改一些东西，emacs可以修改你需要使用的文本编辑器。
我们在设置完成之后就可以进行信息的查看了使用的命令是git config --list，结果如下:

3.GIT基础命令行内容的学习：基础的命令行篇，了解了这些其实就可以开始使用git了。这一部分只是简单的介绍和使用，如果想看命令行的复杂用法请看第四部分。

git学习帮助。学习的前期是我们对于许多的内容都不是很熟悉的情况之下我们可能进场需要获取关于git使用方面的帮助，这是后我们可以通过git命令来打开git的帮助页面。命令行形式如下：$git help <verb>, $git <verb> --help, $man git <verb>，其中的<verb>内容表示的是git指令如图中内容：，这样我们就可以打开关于init指令的帮助页面了。

GIT INIT创建版本库，也可以用于重新初始化一个已有的版本库。使用命令行跳转到想要的初始化成为版本库的文件夹中，使用的命令为为cd，或者是在资源管理其中打开文件后，右键有一个git-bash-here。打开之后在命令行界面中会显示当前的打开的文件夹的路径信息。之后使用git init命令就可以初始化当前的文件夹为本地版本库了。之后在命令行中打开版本库文件夹之后，命令行界面会在路径后面显示一个(master)表示当前文件已经是版本库了。版本库中会有一个.git文件夹，此种存储的就是版本库的信息。所以不要随意修改哟。出现了如上图中的内容就说明已经完成初始化了。

GIT CLONE克隆已有的版本库镜像文件到本地。克隆版本库我们需要的是远程版本库的URL，例如：，这样的话实际上是克隆github上面的libgit2版本库到本地，并且命名成为libgit2。当然我们也是可以为克隆到本地的版本库进行命名的，只需要在上述指令后面添加空格与版本库名称就可以了。例如:这样就是将libgit2版本库克隆到本地并且命名为mylibgit。

GIT STATUS查看当前版本库中的状态。可以查看当前的版本库中的文件情况，什么文件没有上传，有什么文件修改了，并提示出相关的可以执行的操作内容。当然我们也可以的紧凑模式的版本库当前状态了，只需要使用 git status -s就可以了。你会得到如图结果,是不是很短小精悍。

GIT ADD添加文件进入暂存区。我们现在来添加文件在我们初始化的版本库中，例如我们添加一个README.md文件，上面写一些版本库内容预期与介绍吧。我们使用git status来看一看状态，课件git提示我们使用add将内容添加进入暂存区中。这时候我们通过git add <filename>来进行添加，然后在使用git status再次来进行文件状态的查看。。之后我们就可以进行文件的提交了，当然也可以由撤回的操作。但是在我们ADD的时候会有特殊的情况需要交代一下。当我们ADD完一次文件的时候，修改之后的文件存储在了暂存区，之后在没有提交的情况之下，我们再一次的修改，这个时候如果用户直接提交的话我们的版本库中存储的实际上是千亿次存储到暂存区的版本，而之后的修改部分实际上是没有进行提交的，所以可见git实际上是以一次修改（更新）为数据基础的，那么我们要如何你面这种情况呢，实际上就是在第二次修改的时候在调用一次add指令来跟新暂存区内的数据就可以了。

忽略文件配置。在我们的版本库中有的时候会有一些内容是我们不需要纳入版本库的，这个时候我们需要进行一些配置来使git忽略这些的内容。首先创建一个".gitignore"文件，没有后缀名称的哟。然后文件 ".gitignore" 的格式规范如下：

所有空行或者以 ＃ 开头的行都会被 Git 忽略。
可以使用标准的 glob 模式匹配。
匹配模式可以以（/）开头防止递归。
匹配模式可以以（/）结尾指定目录。
要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。

这里要种点说以下什么是glob匹配模式：所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号（*）匹配零个或多个任意字符；[abc] 匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如 [0-9] 表示匹配所有 0 到 9 的数字）。使用两个星号（*) 表示匹配任意中间目录，比如a/**/z 可以匹配 a/z, a/b/z 或 a/b/c/z等。具体内容可见：https://github.com/github/gitignore

GIT DIFF查看修改过的文件（未暂存）与原版本文件之间的差别。当我们修改了文件之后但是还没有使用git add来进行暂存的话，我们是可以通过git diff来进行相关的文件修改内容查看，课件内容如图：，当然我们将修改了的文件添加到暂存区的时候，在使用这一命令就不会显示这样的信息了，但是我们可以使用另一个命令来进行暂存文件的查询，如图：，图中显示的git diff --staged就可以查询暂存文件的更新内容。当然也可以写成git diff --cached.

GIT COMMIT提交更新。课程内容在我们存储到暂存区之后就可以使用git commit命令来进行提交。当然单纯的git commit指令会开启编辑器，需要提交本次更新的说明。当然我们也可以直接在指令后面添加-m “message”，其中的message为我们这一次需要记录的内容。当然咯，如果你觉得使用暂存区在提交的方式比较麻烦的话，并且确定当前的文件修改是你想要的话，则可以使用git commit -a -m “message”，跳过暂存区直接进行提交。有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。此时，可以运行带有 --amend 选项的提交命令尝试重新提交。当我们在上一次提交之后就进行再一次的提交之间并没有做什么，则那么快照会保持不变，而你所修改的只是提交信息。但是当我们的两次提交之间有信息变动的话如图：则最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。

GIT RM文件删除。我们先尝试一下 rm <file>命令的效果吧如下图。这一命令是删除当前页面的某一文件，虽然标记为deleted，但是其更新操作是未暂存的。。然后我们来试验一下git rm的删除效果：可以发现这时候的删除更新是暂存的，也就是说，下一次的提交将会把这一删除操作一同提交到服务器中。当然我们也可以直接从提交问姜忠直接删除某一文件，只需要使用git rm --cached <file>。当然在删除命令之中也是可以使用glob模式的。表示删除log文件夹中的所有的.log文件。这里的*前面使用，因为git有自己的文件匹配机制，想用glob模式的话需要转义。

GIT MV移动文件（就、其实就是文件改名字啦）。其命令行格式如同git mv file_move file_to。这一命令实际上就相当于，mv file_move file_to。然后git rm file_move,最后git add file_to。所以实际上这一操作本质就是一次更名。。。有点无语。

4.GIT进阶篇命令行内容：上面只是讲的是基础的命令行用法，这里将会记录进阶相关的内容（其实就是难一些的命令行，这一部分也会有提到上一部分中所提到的内容，例如commit 的其他用法。）。

GIT LOG 日志查看。重头戏来了，日志是版本控制中的重头戏，其中记录了版本库中的每一版本的每次操作。当我们使用git log命令并且不带任何的参数的时候，git会自动的按照时间的顺序来列出每一个版本内容，如图：

。当然我们也可以在指令后面带入参数，例如-p就表示需要列出每条日志中记录的具体的更新操作，每次commit之后的变化，如图：，当然你可以从图上看见有-2这个参数，这是表示显示就近的两条记录。你也可以为 git log 附带一系列的总结性选项。比如说，如果你想看到每次提交的简略的统计信息，你可以使用 --stat 选项如图：

。另外一个常用的选项是 --pretty。这个选项可以指定使用不同于默认格式的方式展示提交历史。这个选项有一些内建的子选项供你使用。比如用 oneline 将每个提交放在一行显示，查看的提交数很大时非常有用。另外还有 short，full 和 fuller 可以用，展示的信息或多或少有些不同，请自己动手实践一下看看效果如何。。但最有意思的是 format，可以定制要显示的记录格式，规则见下列表格：

`%H`	提交对象（commit）的完整哈希字串
`%h`	提交对象的简短哈希字串
`%T`	树对象（tree）的完整哈希字串
`%t`	树对象的简短哈希字串
`%P`	父对象（parent）的完整哈希字串
`%p`	父对象的简短哈希字串
`%an`	作者（author）的名字
`%ae`	作者的电子邮件地址
`%ad`	作者修订日期（可以用 --date= 选项定制格式）
`%ar`	作者修订日期，按多久以前的方式显示
`%cn`	提交者(committer)的名字
`%ce`	提交者的电子邮件地址
`%cd`	提交日期
`%cr`	提交日期，按多久以前的方式显示
`%s`	提交说明

第二张表列出了我们目前涉及到的和没涉及到的选项，已经它们是如何影响 log 命令的输出的：

`-p`	按补丁格式显示每个更新之间的差异。
`--stat`	显示每次更新的文件修改统计信息。
`--shortstat`	只显示 --stat 中最后的行数修改添加移除统计。
`--name-only`	仅在提交信息后显示已修改的文件清单。
`--name-status`	显示新增、修改、删除的文件清单。
`--abbrev-commit`	仅显示 SHA-1 的前几个字符，而非所有的 40 个字符。
`--relative-date`	使用较短的相对时间显示（比如，“2 weeks ago”）。
`--graph`	显示 ASCII 图形表示的分支合并历史。
`--pretty`	使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。

当然我们也可以限制log指令输出的日志数量，见下表：

`-(n)`	仅显示最近的 n 条提交
`--since`, `--after`	仅显示指定时间之后的提交。
`--until`, `--before`	仅显示指定时间之前的提交。
`--author`	仅显示指定作者相关的提交。
`--committer`	仅显示指定提交者相关的提交。
`--grep`	仅显示含指定关键字的提交
`-S`	仅显示添加或移除了某个关键字的提交

GIT RESET指令操作。在我们提交了文件到暂存区的时候，我们使用status命令可以看见当前的状态中有一段提示用来回退的指令是这样的，git reset HEAD <file>，如果我们使用这一段指令并填写如相关的暂存区的文件的名称的时候，我们在执行完命令行之后再次的使用git status指令，这可以看见文件已经成功的排除在暂存区之外了。

GIT CHECKOUT指令介绍。当我们修改了版本库中的额文件之后，但是还没有存储进暂存区的时候，可以使用git checkout指令进行修改回退，你需要知道 git checkout -- [file] 是一个危险的命令，这很重要。你对那个文件做的任何修改都会消失 - 你只是拷贝了另一个文件来覆盖它。除非你确实清楚不想要那个文件了，否则不要使用这个命令。

GIT REMOTE指令操作远程库。之前我们已经说过了，git clone可以将远程库中的东西拷贝到本地来，但是我们也是可以在本地配置自己的远程库的相关信息的，这是后我们需要使用到remote指令。-v属性的添加，可以看见本地种所有的用户配置的远程库的相关的简要信息，当然我们也可以添加远程库通过git remote add <shortname> <url>指令就可以了，URL可以是多种形式的，在github上面一般以SSH或是HTTP的形式体现。这样做的好处就是方便我们之后直接的通过简称来使用远程库。例如通过git fetch <shortname>来获取本地没有的远程库中有的信息----必须注意 git fetch 命令会将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作。当准备好时你必须手动将其合并入你的工作。还有就是git pull命令，如果你有一个分支设置为跟踪一个远程分支，可以使用 git pull 命令来自动的抓取然后合并远程分支到当前分支。默认情况下，git clone 命令会自动设置本地 master 分支跟踪克隆的远程仓库的 master 分支（或不管是什么名字的默认分支）。运行 git pull 通常会从最初克隆的服务器上抓取数据并自动尝试合并到当前所在的分支。之后如果我们想要将我们本地的内容推送到远程库中的话，我们可以使用git push <shortname> <分支名称>命令来进行。当然默认的情况是当前的分支。然后如果想要查看某一个远程仓库的更多信息，可以使用 git remote show [remote-name] 命令，如图：。如果想要重命名引用的名字可以运行 git remote rename 去修改一个远程仓库的简写名。最后可以通过git remote rm 来进行远程库的删除操作。

GIT TAG标签命令。Git 可以给历史中的某一个提交打上标签，以示重要。

列出标签，直接使用git tag命令可以输出之前所有的设置额标签。当然这样将会输出所有的标签，如果想要查找某一系列的标签，可以使用-l属性，例如这样将会输出所有的与v1.8.5相关的标签内容。
创建标签：标签主要有两种类型——轻量标签（lightweight）与附注标签（annotated）。一个轻量标签很像一个不会改变的分支 - 它只是一个特定提交的引用。附注标签是存储在 Git 数据库中的一个完整对象。它们是可以被校验的；其中包含打标签者的名字、电子邮件地址、日期时间；还有一个标签信息；并且可以使用 GNU Privacy Guard （GPG）签名与验证。通常建议创建附注标签，这样你可以拥有以上所有信息；但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的。创建附录标签可以使用如图中的格式，创建好后我们可以使用git show v1.4进行查看版本信息，当然这里的v1.4可以修改成任意版本名称，具体信息如图：。创建轻量级标签要怎么做呢？轻量标签本质上是将提交校验和存储到一个文件中 - 没有保存任何其他信息。创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字，如图：，这样我们就创建了一个轻量级的标签内容。这时，如果在标签上运行 git show，你不会看到额外的标签信息。命令只会显示出提交信息。当然如果在之前还没有创建标签的话，实际上我们是可以在之后补上的，当使用git log --pretty=oneline显示出版本日志的时候，这是后我们可以看见每一条日志之前的HASH值，如图：，然后我们可以使用git tag -a <版本名称> <版本hash号前几位>。
共享标签：默认情况下，git push 命令并不会传送标签到远程仓库服务器上。在创建完标签后你必须显式地推送标签到共享服务器上。这个过程就像共享远程分支一样 - 你可以运行 git push <远程库名称> <标签名称>。如果想要一次性推送很多标签，也可以使用带有--tags 选项的git push命令。这将会把所有不在远程仓库服务器上的标签全部传送到那里。现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。
检出标签：在 Git 中你并不能真的检出一个标签，因为它们并不能像分支一样来回移动。如果你想要工作目录与仓库中特定的标签版本完全一样，可以使用GIT checkout -b [分支名称] [标签名称] 在特定的标签上创建一个新分支

GIT别名。我们可以为我们常用的命令设置别名，这样可以更方便的使用git了，那么怎么设置呢。这又是config命令的一大功能（前面提过这一指令，如有不清楚请翻阅前文），我们应该怎么做呢，上图：，图中可见，设置命令为git config --global alias.<别称> <元指令>。当然使用的时候我们也可以使用别名替代，繁复命令中的一部分，例如。这用在使用git reset HEAD --<filename>可以变成git unstage <filename>。可以看出，Git 只是简单地将别名替换为对应的命令。然而，你可能想要执行外部命令，而不是一个 Git 子命令。如果是那样的话，可以在命令前面加入 ! 符号。如果你自己要写一些与 Git 仓库协作的工具的话，那会很有用。我们现在演示将git visual定义为gitk 的别名：。

5.分支模块：首先我们来具体说以下相关git数据存储的内容吧，前面已经说过了git以修改内容为基础的并且是以快照的形式来存储内容信息。当我们每一次提交修改后的内容的时候，实际上git会为我们生成一个新的提交对象，并使得当前的额提交对象指向一个树对象，并由书对象指向相关的修改内容快照。具体内容如图：其中blob内容是文件快照，而commit是提交保存对象，tree内容是书对象内容。

　　在每一次的提交的时候我们实际上都有一个这样的提交对象，所以当我们多次提交之后其存储的形式就变成了如图内容：，每一次提交的保存对象将会有一个指针指向其前一次的提交对象（父对象）。理解了这些之后在想理解分之内容就简单多了，因为分支就是指向不同的提交对象的指针变量。当我们初始化的时候的其实就已经有一个自动的指向最新的提交对象的master指针。上图：，线面就来讲一讲关于分之的操作命令吧。

创建分支。我们可以通过$GIT BRANCH <branchname>命令来进行分之的创建，之后就会得到如图：那么，Git 又是怎么知道当前在哪一个分支上呢？也很简单，它有一个名为 HEAD 的特殊指针。在 Git 中，它是一个指针，指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。你可以简单地使用git log 命令查看各个分支当前所指的对象。提供这一功能的参数是--decorate。当然我们也是可以使用$git checkout -b <filename>这样的命令来进行分支的创建和切换一步完成。还有一种情况之下，如果用户需要删除某一分支的时候我们可以使用git branch -d <filename>。当然给予这么强大的命令行内容，git branch是可以用来显示分支信息的。注意某一分支前的 * 字符：它代表现在检出的那一个分支（也就是说，当前HEAD指针所指向的分支）。和可以为当前的额命令添加-v属性进行信息的输出，这样的话我们可以查看到更多的信息。当然还有git branch的很多的其他的用法，可以添加--help属性来查看命令行的使用方式。
分支切换。要切换分支的时候我们可以使用$git checkout命令,这样就可以使得HEAD指向我们我想要使用分支了，例如当这时候如果我们做出任何的修改，并提交的话，我们版本库中的内容将会变化成如图的内容：如图内容。testing内容已经对于当前的版本有一个新的内容的指向，但是master指针并没有变化，之后如果我们在使用checkout命令指向master版本内容的时候，实际上我们是是的当前的版本库跳转到一个比较老的版本了，忽略了testing分支中所体现的修改，但是如果这个时候我们再提交一个版本的内容的时候情况就又不同了，这是后版本苦衷的内容将会显示成为如图中内容：。

合并分支：当我们有多个分支进行工作的时候，我们实际上是可以通过分支合并的功能来进行分支版本归一的，分支合并的内容是（$git merge命令）。

在我们使用合并功能的时候，如果我们所需要合并的分支是被合并分支的上游则合并分支实际上所执行的操作就是向前移动指向位置，这时候的操作名字称为（快进“fast-forward”）。
但是当我们所需要合并的分支并不是被合并分支的上游内容的时候，出现这种情况的时候，Git 会使用两个分支的末端所指的快照以及这两个分支的工作祖先，做一个简单的三方合并。例如我现在有一个issu53需要进行合并情况如图：Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。最后得到的结果如图：
最后，就是当我们合并有冲突的时候会遇到什么情况，我们应该怎么做呢。例如如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们，这时候如果合并的话，此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。这个时候可以使用$git status来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件。Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。当然我们也可以使用冲突解决的图形化界面合并工具，使用$git mergetool命令吧。等你退出合并工具之后，Git 会询问刚才的合并是否成功。如果你回答是，Git 会暂存那些文件以表明冲突已解决。如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以提交合并了。

变基简介。相对于合并我们还可以使用的一种操作叫做变基，举个例子，有如下情况上图：变基操作它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。所以最后变基操作完成的时候版本库内容会变成如图：，最后的最后我们回到master分支之中并进行合并。这样就可以得到最终结果：。变基和合并这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是先后串行的一样，提交历史是一条直线没有分叉。

我们应该如何利用分支呢。通过分支进行开发，在某个特定的时候将一些稳定的新特性的内容添加进入稳定的master版本内容，这样就可以保证当前一定有一个版本的内容是稳定的，而实际稳定运行版本内容将不会被影响到。当然这种情况总是会导致稳定的版本内容距离实际的编写版本落后一大截。这就是一种长期分支的体现。当然还有特性分支一说，某一特性在一短期分支内进行，完成之后合并到主分支。这样可以同时的进行多个独立的特性模块的开发。