git checkout 命令详解

转自：http://www.cnblogs.com/hutaoer/archive/2013/05/07/git_checkout.html?utm_source=tuicool&utm_medium=referral

在日常的git操作中，git checkout——检出，是我们的常用命令。最为常用的两种情形是创建分支和切换分支。

在下面的命令中，使用了一些简写，在这里说明一下：

git st # git status
git ci  # git commit
git br # git branch
git co # git checkout
git mg # git merge
git line # git log --oneline

当然，你也可以直接在git中敲命令，将这些简写添加到git配置中

git config --global -e

然后，可以插入下面的配置：

[alias]
    st = status
    co = checkout
    br = branch
    mg = merge
    ci = commit
    md = commit --amend
    dt = difftool
    mt = mergetool
    last = log -1 HEAD
    cf = config
    line = log --oneline
    latest = for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) [%(committername)]'

    ls = log --pretty=format:\"%C(yellow)%h %C(blue)%ad %C(red)%d %C(reset)%s %C(green)[%cn]\" --decorate --date=short
    hist = log --pretty=format:\"%C(yellow)%h %C(red)%d %C(reset)%s %C(green)[%an] %C(blue)%ad\" --topo-order --graph --date=short
    type = cat-file -t
    dump = cat-file -p
    

这样，你也就可以使用这些简写的命令咯。下面步入正题啊。

（一）基础——千里之行，始于切糕(checkout)

先熟悉下常用操作，创建分支和切换分支，也可以称为检出分支。

首先我们新建一个仓库gitTest，然后新建文件a，为什么要用a命名呢，这里是故意为之，后面为大家揭晓分支。呵呵。或许下面的介绍会有些枯燥乏味，因为您已经对这些命令烂熟于胸，而且运用得相当熟练，那么您可以直接跳过这一步。

在master分支上，做一次提交c1，然后现在新建一个分支a，并切换到a分支。

这个操作主要会用到两个命令：

创建新分支：git branch branchName

切换到新分支：git checkout branchName

然后，上面两个命令也可以合成为一个命令：

git checkout -b branchName

（二）真相——HEAD是checkout的灵魂

其实，我们在切换分支，和新建分支的时候，有没有想过，这些操作操作背后的工作原理是怎样的呢？最大的功臣就是.git目录下的HEAD引用，她宛如一个芭蕾舞者，从一个分支飘逸的跳到另一个分支，虽无声无息，却精准无比。

在我们身处master分支的时候，您一定很好奇，当前的HEAD的内容是什么？不妨来看看吧。

我们看到c1的提交hash值和HEAD对应分支master的当前hash值是一样的。也就是说，HEAD指向的是当前分支名master，而master又对应了当前的最新的一次提交ID.

好，那么我们再做一次提交，看看master对应的hash值有无变化。

从上图，我们可以不难看出，HEAD对应的ref没有变化，还是master，但是master对应的commit ID却变成了c2对应的commit ID，即更新为最后一次提交的ID咯。

现在，提交一次的原理，我们已然了解，那么切换分支的时候呢？？

现在我们身处master分支，然后我们切换到a分支，看看会发生什么样的情况吧。

从上图分析，在master分支上的时候，HEAD指向的是master，对应的是c2的commit ID。而切换到a分支的时候，HEAD也相应的指向了a，同时a对应的是a分支上的最新commit ID。因此，我们可以得出结论，在切换分支的时候，HEAD也会相应的指向对应的分支引用。

但是，使用checkout命令的时候，并不是每次都会改变HEAD指针的指向哦。在什么情况下HEAD一直坚定不移的拥护者他的女神呢？可谓衣带渐宽终不悔，长使英雄泪满襟啊！让我们接着往下看。

（三）进阶——HEAD懂不懂，看你怎么用

checkout命令用法如下：

1. git checkout [-q] [<commit>] [--] <paths> ...

2. git checkout [<branch>]

3. git checkout [-m] [ [-b | -- orphan ] <new_branch>]  [start_point]

用法2比用法1的区别在于，用法1包含了路径。为了避免路径和引用（或提交ID）同名而发生冲突，可以在<paths>前用两个连续的连字符作为分隔。用法1的<commit>是可选项，如果省略，则相当于从暂存区进行检出。

来看个例子：

情景1，省略掉<commit>

现在我们处于master分支下，然后我们修改了文件a，输入“c3”文本到a中，这时候，暂存区中的内容是没有"c3"的，通过git diff可以比较。现在我们从当前分支暂存区中检出文件a。那么我们可以直接使用git checkout a。

这时候，提示检出失败，git以为我们想检出仓库a。还记得为什么在第一步中，我们曾新建的文件a吗？这里终于派上用场了，由于仓库中还存在分支a，同时当前分支中又存在文件a，于是git傻傻分不清楚了。这时候怎么办？有两个办法，第一，我们在命名分支的时候要注意语义性，分支名要具有一定的意义，不能使用简单的a,b,c来命名，这样很容易导致分支名和文件名重复；第二，参照用法1，使用两个连字符来分隔。在目前的情形中，我们使用第二种方法吧。

这时候，发现工作区的内容被暂存区的内容覆盖，"c3"文本也没有了，当然HEAD指针也没有什么变化，一切又恢复了平静。

再看一个例子：

情景2，不省略<commit>

在不省略<commit>的时候，<commit>既可以是某一个具体的commit hash值，也可以是某个分支名称，tag名称。不论分支也好，tag也好，它们本质上对应的都是一个commit hash值。

在检出a分支下的a文件的时候，最好把两个连字符加上，不然git也会无法区分。整个过程中，HEAD头指针没有发生改动。

总结：第1种用法（包含<paths>的用法）不会改变HEAD头指针，主要使用于指定版本的文件覆盖工作区中对应的文件。如果省略<commit>，则会用暂存区的文件覆盖工作区中的文件，否则用指定提交中的文件覆盖暂存区和工作区中的对应文件。

接下来，我们看看用法2，在第一部分中，我们知道切换分支，会改变HEAD的指向，那么如果我们是检出某个commit会怎样呢？同检出分支一样，会用该commit下的内容覆盖当前分支工作区和暂存区的内容，请看例子。

目前我们处于master分支上，且已经有了两次提交，分别是c1和c2，然后我们修改a，给a文件添加内容"c3"，并add到暂存区，随即使用checkout到c1的commit 上。注意，刚开始checkout的时候，git不会允许你直接切换，因为你修改了暂存区的内容， 它会提醒你提交后再切换，这时候，你可以使用-f 强行切换。再查看状态的时候，git提示我们已经不在任何分支上，HEAD指针也是指向具体的c1的commit值，进入了“分离头指针”状态。这个状态下，要回到master上面，只需要git checkout master即可，也可以在这个状态上新建分支。

如果，checkou后面不跟任何参数，则就是对工作区进行检查，请看例子。

我们身处master分支上，并且没有任何改动，这时候git checkout没有任何输出。然后，我们给a文件添加内容“c3”，然后再git checkout一下，git就会提示a文件有修改，是不是很简单？

总结：对于第2种用法，不是检出某个具体文件的的时候，即不指定<paths>的时候，单纯的检出某个commit或分支，是会改变HEAD头指针的。而且只有当HEAD切换到某个分支的时候才可以对提交进行跟踪，否则就会进入“分离头指针”的状态。如果省略用法2后面的<branch>，则默认对工作区进行状态检查。

（四）熟悉的checkout，陌生的用法，妈妈再也不用担心我的checkout啦！

1. git branch <branch> <start point>

以某个commit创建新分支。 在通常情况下，我们都会在当前分支的基础上，创建新分支。比如git branch new_branch

也许你不知道，我们还可以基于当前分支的某一次commit来创建分支。请看！

从上图可见，我们想基于master分支的c1 提交ID创建新分支new_branch，创建成功后，切换到new_branch，查看log，只有c1，耶~~成功啦！

当然，也可以使用git checkout -b <new_branch> <start point>这个常用的命令。

 

2.  git checkout --datch <branch>

切换到分支的游离状态，默认以该分支下的最后一次提交ID，请看下面的例子。

当前分支为a，然后使用git checkout --detach master，那么HEAD就会切换到master的最后一次commit值的状态下！

 

3. git checkout -B <branch>

这个命令，可以强制创建新的分支，为什么加-B呢？如果当前仓库中，已经存在一个跟你新建分支同名的分支，那么使用普通的git checkout -b <branch>这个命令，是会报错的，且同名分支无法创建。如果使用-B参数，那么就可以强制创建新的分支，并会覆盖掉原来的分支。请看具体操作。

当前分支为master，且仓库中已经存在分支a，我们先用git checkout -b a来创建a分支，必然会失败的，并提示我们仓库中已经有了一个a分支咯，仿佛在说“hi，哥们，你已经有了一个老婆了，一夫一妻制你的不懂？你以为这里是印度啊？”。随后，我们使用git checkout -B a，耶~~，it works!

4. git checkout --orphan <branch>

是的，假如你的某个分支上，积累了无数次的提交，你也懒得去打理，打印出的log也让你无力吐槽，那么这个命令将是你的神器，它会基于当前所在分支新建一个赤裸裸的分支，没有任何的提交历史，但是当前分支的内容一一俱全。新建的分支，严格意义上说，还不是一个分支，因为HEAD指向的引用中没有commit值，只有在进行一次提交后，它才算得上真正的分支。还等什么呢？赶紧试试！

好了，现在我们终于找到组织了！

5. git checkout --merge <branch>

这个命令适用于在切换分支的时候，将当前分支修改的内容一起打包带走，同步到切换的分支下。

有两个需要注意的问题。

第一，如果当前分支和切换分支间的内容不同的话，容易造成冲突。

第二，切换到新分支后，当前分支修改过的内容就丢失了。

所以这个命令，慎用！

6. git checkout -p <branch>

这个命令可以用来打补丁。这个命令主要用来比较两个分支间的差异内容，并提供交互式的界面来选择进一步的操作。这个命令不仅可以比较两个分支间的差异，还可以比较单个文件的差异哦！

结束语：至此，关于git checkout命令暂告一段落，对于checkout命令，你也有所熟悉了吧。当然，git checkout还有一些其它用法，本文并没有讲到，你可以在git bash或终端中使用git checkout --help去进一步了解