本文主要是对git-scm上的一篇博客的总结与补充，有说的不清楚的地方希望读者能读一下原博客
git的三个空间
在设计上，git将传统的工作空间，也就是工作目录，划分为三个层次：
由右往左分别为：工作目录，暂存区和版本库。中文翻译版本众多，我们就用它的英文版本好了。那么，平时我们工作于Working Directory，作出一部分修改后，我们会git add来将我们的修改暂存，也就是加入Index，最后使用git commit完成一次提交，也就是将当前Index中的文件加入到版本库，并移动HEAD指针指向当前提交。如下图：
git reset
git reset指令主要用来恢复文件，撤销提交。
对整个工程使用reset
不指定特定文件时，git reset指令会进行如下3步操作：
- 修改HEAD（与其指向的分枝）指针，让它（们）指向指定版本。这一步reset了版本库，仅影响到HEAD（与其指向的分枝）指针。
- 用指定版本的工程文件还原Index区。
- 用指定版本的工程文件还原Working Directory。
而git reset命名后面带的三种参数则分别表示reset过程进展到上面的三个阶段：
指定文件的reset
既然指定了reset特定文件，那就说明使用者的意图不在于修改版本库，因此指定文件的reset命令都不会执行阶段1，也就是不会修改HEAD指针。实际上在指定文件的情况下，reset指令只会用版本库中指定版本的文件还原Index区。
git checkout
git checkout在功能上与reset命令很相似，但是二者确实是被设计用于不同场合的，下面来讨论它们的区别。
不指定文件的checkout
效果上，不指定特定文件，git checkout与git reset --hard几乎完全一样，区别在于：
-
git checkout在对Working Directory进行“安全检查”。它会尝试对你当前Working Directory中的文件与指定checkout的版本进行一次简单合并，如果在运行git checkout之前，你改动了工作区的文件，checkout操作不会覆盖你当前修改过的文件；而git reset --hard操作则仅仅简单粗暴的覆盖整个工作区。所以git checkout操作是安全的。 - 我们知道HEAD作为头指针实际上指向了版本库当中的分支指针，而分支指针才实际的指向某次提交，比如
HEAD->master->8bcea这种结构。git reset --hard命令实际是修改了上面例子中的master分支指针的指向；git checkout命令修改的则是HEAD指针的指向：
因此，checkout更多的用于分支切换等非破坏性操作，而reset则用于还原等破坏性操作。
指定文件的checkout
有没有觉得刚刚在讨论指定文件的reset操作时，似乎漏了点功能？指定文件的reset只还原了Index区，可是如何还原Working Directory？是的，指定文件的checkout操作可以还原当前工作目录。
也就是说，可以简单的理解为，指定文件的git checkout实现了指定文件的git reset --hard操作，它首先用特定文件还原Index区，再还原Working Directory。
git revert
git revert命令可以被认为是安全的reset操作。它会用指定版本的版本库状态在当前的HEAD指针后面添加一个提交，并移动HEAD指针。
也就是说，git会取出你指定的版本，“覆盖”你的Working Directory，然后执行：
git add .
git commit -m "Revert xxx"
这个操作的安全性在于：
- 不像reset那样有可能修改提交历史，而是增加了提交，符合git的设计思想，可逆操作。
- “覆盖”Working Directory的过程与checkout指令类似，会进行安全检查。
下面是一个例子：
git rm
*nix的软件思想有一条是不做重复的工作，因此git rm与/bin/rm功能是不同的：
- 默认情况下，
git rm会讲文件同时从版本库、Index和Working Directory删除 - 加上
--cached参数时，rm操作会保留Working Directory中的文件，而将其它两个区域中的指定文件删除。
而删除文件操作在git中也有安全限制，因此，如果Index或Working Directory中的指定文件与版本库中的校验和不一致，git rm操作就会报错，而-f参数可以指定强制删除。
