上一節重置中，很多命令都是有引數 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。該檔案仍在版本庫中，但是這個提交沒有被分支跟蹤到，並不能保證該提交會永久存在。

重新切回到master分支

檢視工作區檔案列表：

發現在分離中提交的new-commit22121.txt檔案不見了。而且，之前的提交日誌也不見了。

同樣的，該不見的檔案還是存在版本庫中的，只是不能保證長久被儲存：

對分離頭指標狀態下的日誌，與 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 .
引數為一個點（”.”）。會取消本地的修改，會用暫存區的所有檔案直接覆蓋本地檔案。