Git 仓库结构 （二）***

一、GIT工作流程 了解git，首先要弄清楚对象在被git管理过程中所处的4个阶段，分别是：

• 工作目录
• index(又称为暂存区)
• 本地仓库
• 远程仓库。

从时间先后来讲，工作目录的内容是你当前看到的，也是最新的；index区标记了你当前工作目录中，哪些内容是被git管理的；而本地仓库保存了对象被提交 过的各个版本，比起工作目录和暂存区的内容，它要更旧一些；远程仓库是本地仓库的异地备份，远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库 修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。任何对象都是在工作目录中诞生和被修改；任何修改都是从进入index区才开始被 版本控制；只有把修改提交到本地仓库，该修改才能在仓库中留下痕迹；而要与协作者分享本地的修改，可以把它们push到远程仓库来共享。图最上方的 add、commit、push等，展示了git仓库的产生过程。反过来，我们可以从远程历史仓库中获得本地仓库的最后一个版本，clone到本地，从本 地检出对象的各个版本到index暂存区或工作目录中，从而实现任何对象或整个仓库的任意阶段状态的”回滚”。当正向和反向都能自由切换后，git就强大 到无所不能了。

一开始接触这些概念可能比较绕，其实在git入门阶段，可以先抛开远程仓库不看，只了解管理本地仓库的”3棵树”就够了。如下图：

二、常用GIT命令

在开始之前，我们需要把下面的图看懂：

HEAD，头，它始终指向当前所处分支的最新的提交点。你所处的分支变化了，或者产生了新的提交点，HEAD就会跟着改变。

working directory，它是你的工作目录，也是当前你看到的东西。你的工作目录是与版本、分支相关的。

stage的东西虽然看不见，但是执行git status就会看到哪些对象的修改将在下一次commit的时候被放进本地仓库。这些东西称为stage。

commit

commit把暂存区的内容存入到本地仓库，并使得当前分支的HEAD向后移动一个提交点。如果对最后一次commit不满意，可以使用git commit --amend来进行撤销，修改之后再提交。如图所示的，ed489被4ca87取代，但是git log里看不到ed489的影子，这也正是amend的本意：原地修改，让上一次提交不露痕迹。

checkout

checkout用来检出并切换分支。checkout成功后，HEAD会指向被检出分支的最后一次提交点。对应的，工作目录、暂存区也都会与当前的分支进行匹配。下图是执行git checkout maint后的结果：

reset

reset命令把当前分支指向另一个位置，并且相应的变动工作目录和索引。如下图，执行git reset HEAD~3后，当前分支相当于回滚了3个提交点，由ed489回到了b325c：

reset有3种常用的模式：

• soft，只改变提交点，暂存区和工作目录的内容都不改变
• mixed，改变提交点，同时改变暂存区的内容。这是默认的回滚方式
• hard，暂存区、工作目录的内容都会被修改到与提交点完全一致的状态

diff

我们在commit、merge、rebase、打patch之前，通常都需要看看这次提交都干了些什么，于是diff命令就派上用场了：

来比较下上图中5种不同的diff方式：

• 比较不同的提交点之间的异同，用git diff 提交点1 提交点2
• 比较当前分支与其他分支的异同，用git diff 其他分支名称
• 在当前分支内部进行比较，比较最新提交点与当前工作目录，用git diff HEAD
• 在当前分支内部进行比较，比较最新提交点与暂存区的内容，用git diff --cached
• 在当前分支内部进行比较，比较暂存区与当前工作目录，用git diff

merge

merge命令把不同的分支合并起来。如下图，HEAD处于master分支的ed489提交点上，other分支处于33104提交点上，项目负责人看了下觉得other分支的代码写的不错，于是想把代码合并到master分支，因此直接执行git merge other，如果没有发生冲突，other就成功合并到master分支了。

rebase

rebase又称为衍合，是合并的另外一种选择。merge把两个分支合并到一起进行提交，无论从它们公共的父节点开始(如上图，other分支与 master分支公共的父节点b325c)，被合并的分支(other分支)发生过多少次提交，合并都只会在当前的分支上产生一次提交日志，如上图的 f8bc5。所以merge产生的提交日志不是线性的，万一某天需要回滚，就只能把merge整体回滚。而rebase可以理解为verbosely merge，完全重演下图分支topic的演化过程到master分支上。如下图：

在开始阶段，我们处于topic分支上，执行git rebase master，那么169a6和2c33a上发生的事情都在master分支上重演一遍，分别对应于master分支上的e57cf和f7e63，最后checkout切换回到topic分支。这一点与merge是一样的，合并前后所处的分支并没有改变。git rebase master，通俗的解释就是topic分支想站在master的肩膀上继续下去。

cherry-pick

cherry-pick命令复制一个提交点所做的工作，把它完整的应用到当前分支的某个提交点上。rebase可以认为是自动化的线性的cherry-pick。

例如执行git cherry-pick 2c33a:

正反过程对比

理解了上面最晦涩的几个命令，我们来从正反两个方向对比下版本在本地的3个阶段之间是如何转化的。如下图(history就是本地仓库)：

如果觉得从本地工作目录到本地历史库每次都要经过index暂存区过渡不方便，可以采用图形右边的方式，把两步合并为一步。