大家好，我是 17。
git checkout 是 git 中最重要最常用的命令之一，本文为大家详细解说一下。
恢复工作区
checkout 的用途之一是恢复工作区。
git checkout .
checkout . 表示恢复工作区的所有更改,未跟踪的文件不会有变化。
恢复工作区的所有文件风险比较大，会丢失所有工作区的修改，一定要慎用
git checkout -- a.txt
中间加上 – 就安全多了，可以只恢复单个文件。
版本切换
git checkout master 取出 master 分支，HEAD 指向 master
git checkout 907d3ba 取出最后提交为 commit id 为 907d3ba 这个版本,HEAD 转到 907d3ba，和 master 分离。
取出分支的时候 HEAD 会指向当前分支。取出某个版本，HEAD也会跟着指过来，分支不动。这会造成 HEAD 和分支 分离。在分离 HEAD 的情况下，可以查看，提交，做各种试验，如果对结果满意，可以就地打新分支保留这些提交：
git checkout -c <new-branch-name>
如果不满意，什么也不用做，切回当前分支既可。
git checkout master 修正 HEAD 指向 master 分支
如果不知道哪前分支名也没关系 checkout - 同样会修正 HEAD。
git checkout -
如果要开发新功能，直接在某个提交上打分支即可，为什么要分离 HEAD？原因是这样比较轻量。比如你现在想开发一个功能，但不知道是否可行，所以先试验一下，确认好了再打分支。如果直接打分支，觉得不合适还得删除。因为分支没有合并，还删不掉，删除还得加强制删除参数。
分离头指针的操作相当于 先上车，后补票 。上车后又下车，不用买票，只有到终点才需要补票。
强制拉分支
git checkout -B dev
假定 dev 存在，如果没有 -B 参数，会报错，加上 -B 会覆盖原来的 dev 分支，打一个新的 dev 分支出来，并转到 dev 分支。
省得费心起名了。如果并行的只有一个任务，可以每次都用 dev 分支开发。
从某个 commit 打分支
我们打分支的时候，默认会从 HEAD 处开始，对于 master 分支来说，就是 G。
如果从 F 处打分支出来，可以用第二个参数指定
git checkout -b dev F
也可以这样写
git checkout -b dev HEAD^
孤儿分支
有这样一个参数 --orphan， orphan 的英文原意是孤儿，如果我们要打一个设计文档分支出来这样写
git checkout --orphan design
因为设计文档和开发的代码完全是独立的部分，不适合和开发代码放一个分支上。
之所以称为孤儿分支，是因为这个分支是完完全全独立的，和以前所有的分支没有任何关联。和其它分支是平行的，永远不会相交。
就算孤儿分支是从 master 分支打出来的，你在 master 分支 执行 git log --oneline 也找不到任何有关孤儿分支的痕迹。当然更无法 merge 一个孤儿分支，实际上，也没有这个需求。
孤儿分支刚生成的时候，没有父提交，也没有任何提交，完全是空的，暂存区和工作区一般来说会有内容，因为我们要存设计文档，原来的内容都没有用，删除
git rm -rf .
现在我们得到了一个纯净的，独立的分支，可以添加设计文档了，并生成第一个提交。
可能你会有疑问，既然我们要一个孤儿分支，为什么还要初始化内容给我们？因为我们可能还有这样的需求:需要一个起点，而不是从一无所有开始。
试想这样的场景：项目开发半年了，市场反馈却是平平，老板觉得这样下去不是办法，需要另寻出路，但又不想放弃现在的方向。因为这次是方向性的问题，改动比较大，如果打普通分支的话，可能无法向主干合并。于是老板想出了一个办法，新建一个孤儿分支，完全独立来验证新想法，如果新方向正确，就可以代取代原来的方向。
从头来实现项目来验证新想法显然是不实际的，可以从项目中选择合适的节点，比如 F 节点，以这个为基础。
git checkout --orphan laboratory F
新分支生成后，会把 F 节点的所有内容带到暂存区和工作区，我们全部保留，在这个基础上开发。laboratory 和原来的 master 分支的级别是完全一样的，laboratory 就相当于原来的 master 分支。master 只是提供了一个起点。laboratory 后面如何发展和 master 完全没有关系。
选择合并
git checkout master
git merge dev
merge dev 的时候发生的冲突，这时可以打开冲突文件手动修改，也可以自动修改
git checkout --ours a.txt
git checkout --theirs a.txt
下面举例说明一下如何自动修改。
首先制造一个 merge 冲突的现场。起点在 master 分支。 在 master 分支 和 dev 分支同时修改 a.txt 的第一行，
echo init >a.txt
git add a.txt
git commit -m 'add a.txt'
git checkout -b dev
echo dev >a.txt
git add a.txt
git commit -m 'alter a.txt'
git checkout master
echo master >a.txt
git add a.txt
git merge dev
看下 a.txt 的内容 cat a.txt
<<<<<<< HEAD
master
=======
dev
>>>>>>> dev
上面的是 master 的修改，下面的是 dev 的修改。
如果现在后悔了，想取消合并，恢复到合并前的状态，
git merge --abort
自动修改用 git checkout 命令。我们可以选择保留 master 分支的内容
git checkout --ours -- a.txt
查看 a.txt 内容，已经恢复正常了。
master
如果发现这不是我们要的结果，可以恢复冲突现场
git checkout -m -- a.txt
查看 a.txt ，又恢复到冲突状态了。这次我们选择 dev 的内容。
git checkout --theirs -- a.txt
检查内容无误后，添加到暂存区。
git add a.txt
冲突解决完了，但 merge 还没完成。
git merge --continue
这时弹出编辑器，可以修改提交信息，确认后会自动提交修改的内容。merge 完成。
新加的 git switch
你会发现 checkout 承载了很多分支相关的命令。为了让命令更清晰，新版 git 增加了 switch 命令。
switch 能做的事 checkout 都能做。
switch 命令的功能很纯粹，就是切换分支，如果分支不存在，顺便新建分支。
举两个常见的例子。
| switch | checkout |
|---|---|
| git switch master | git checkout master |
| git switch -c dev | git checkout -c dev |
| git switch --orphan | git checkout --orphan |
切分支的时候建议把工作区和暂存区的内容都提交
新加的 git restore
和增加 git switch 同样的原因，新版本增加了 git resotre 命令。
git resotre 的职责是恢复工作区和暂存区。原来 checkout 能做的，它都能做。它能做的， checkout 可能做不了。
--worktree 是 git restore 的默认参数
git restore a.txt 把暂存区 a.txt 的内容恢复到工作区
git restore . 恢复工作区的所有内容。
git restore --staged a.txt 把 HEAD 的 a.txt 恢复到暂存区
git restore --source=HEAD --staged --worktree a.txt 恢复工作区和暂存区
–source 表示从哪里来，默认是 HEAD --staged 表示恢复到暂存区，–worktree 表示恢复到工作区。这三个参数有简写方式。
git restore -s HEAD -SW a.txt
当 merge 发生冲突时，也可以用 restore 来解决冲突，用法同 checkout。