git检出

上一节重置中，很多命令都是有参数 HEAD 或者HEAD^。这些重置命令实际上所针对的是头指针HEAD。但是实际情况，会导致分支master的游标位置发生变化，而没有改变HEAD的内容。

这是因为HEAD执行一个引用refs/heads/master。所以会导致游标的位置发生变化。

检出命令(git checkout)实质就是修改HEAD本身的指向，该命令不会影响分支master。

1、查看状态：

2、提交其中的第一个文件：

3、将另一个文件加入暂存区：

4、创建一个新文件，并写入内容：

5、查看日志

6、查看HEAD的引用：

7、查看当前分支

8、查看工作区包含的文件列表：

以上部分主要是查看当前master分支的状态信息。
后面开始见证检出操作：
1、检出当前提交的父提交：

2、查看当前分支：

3、查看HEAD头指针，此时HEAD指向一个具体的提交ID，不再是指向refs/heads/master,这就是“分离头指针”状态：

4、查看HEAD 和master的ID，第一个是HEAD，第二个是master。会发现master还是指向原来的ID，并没有变化：

5、查看工作区文件列表：

对比会发现，少了一个文件new-commit2121.txt。该文件就是之前提交到版本库的文件。
5.1。该文件仍在版本库中，但是这个提交没有被分支跟踪到，并不能保证该提交会永久存在。

6、查看工作区其他修改文件和暂存区的文件，并没有变化：

红色标记提醒，当前是在分离头指针状态。头指针现在指向f686dc1.
7、在分离指针状态下，提交暂存区的文件到版本库：

8、查看HEAD指针,此时指向新的提交ID：

9、查看日志：

发现新提交是在之前提交(f686dc1)的基础之上的。

重新切回到master分支

查看工作区文件列表：

发现在分离中提交的new-commit22121.txt文件不见了。而且，之前的提交日志也不见了。

同样的，该不见的文件还是存在版本库中的，只是不能保证长久被保存：

对分离头指针状态下的日志，与 master分支下的日志对比发现：

在分离状态下的提交除了使用ID（92d26031）访问外，不能通过master分支或其他引用访问到。

合并操作
如果这个提交是master所需要的，那么可以通过合并操作将(92d26031)合并到master分支。

1、确认当前分支就是master分支：

2、执行合并操作，将ID为92d26031的提交合并到当前的分支master中:

3、查看工作区文件，发现之前的提交文件new-commit22121.txt又出现在工作区中：

4、查看分支图：

发现从f686dc1处开始出现分支，在新提交c399b处发生了合并。
5、查看合并后master的指向新的提交：

6、查看最新的提交,发现当前的新提交有两个父提交，也就是合并之前的两个提交：

7、查看此时的状态：

总结：
1、命令 git checkout [-q] [<\commit>] [- -] <\paths>
其中commit是可选的，当commit与path同名时，在path前加”–”。
包含了路径path的命令不会改变HEAD头指针，主要是用于指定版本的文件覆盖工作区中的对应文件
a、省略commit ,则用暂存区的文件 覆盖工作区的同名文件：
a-1、修改暂存区中的文件内容：

a-2、用暂存区的detach-test.txt文件覆盖工作区的修改后的detach.txt文件，会导致自上次提交add以来的所有修改都被取消：

b、不省略commit，用指定的提交文件 覆盖暂存区和工作区中的对应文件：
b-1、修改工作区、暂存区、版本库中的同名文件：



开始覆盖，会覆盖工作区的文件 和暂存区的文件，也就是该文件commit提交之后的所有修改都消失了：

2、命令git checkout [<\branch>] ，会改变HEAD头指针。

branch不为空，检出branch分支，HEAD切换到该分支，从而能够进行跟踪。否则进入分离头指针状态。

branch为空，则相当于对工作区进行状态检查，汇总显示工作区、暂存区与HEAD的区别，与命令 git checkout HEAD相同：

3、命令 git checkout [-m] [ [-b|–orphan] <\new_branch>] [<\start_point>]，用于创建和切换到新的分支new_branch，新的分支从指定的提交start_point处开始创建。

4、命令 git checkout .
参数为一个点（”.”）。会取消本地的修改，会用暂存区的所有文件直接覆盖本地文件。