详解Git工作区、暂存区、历史记录区以及git reset、git revert、git checkout等撤除命令的区别
一、可以将git简单的分为三个区域
1、工作区（working directory）
2、暂缓区（stage index）
3、历史记录区（history）
如图所示：
其中git add files把当前目录中的文件放入暂存区域，这其实做了两件事：
1、将本地文件的时间戳、长度，当前文档对象的id等信息保存到一个树形目录中去（index，即平时说的暂存区）
2、将本地文件的内容做快照并保存到Git 的对象库 。
综上2点来说，暂存区实际上就是一个包含文件索引的目录树，像是一个虚拟的工作区。在这个虚拟工作区的目录树中，记录了文件名、文件的状态信息（时间戳、文件长度等），文件的内容并不存储其中，而是保存在 Git 对象库（.git/objects）中，文件索引建立了文件和对象库中对象实体之间的对应。 如图所示：
在这个图中，我们可以看到部分 Git 命令是如何影响工作区和暂存区（stage, index）的：
图中左侧为工作区，右侧为版本库。在版本库中标记为 "index" 的区域是暂存区（stage, index），标记为 "master" 的是 master 分支所代表的目录树。
图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个“游标”。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
图中的 objects 标识的区域为 Git 的对象库，实际位于 ".git/objects" 目录下
当对工作区修改（或新增）的文件执行 "git add" 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID 被记录在暂存区的文件索引中
当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树 。
当执行 "git status" 命令扫描工作区改动的时候，先依据 .git/index 文件中记录的（工作区跟踪文件的）时间戳、长度等信息判断工作区文件是否改变。如果工作区的文件时间戳改变，说明文件的内容可能被改变了，需要打开文件，读取文件内容，和更改前的原始文件相比较（本地文件和与之对应的object库中的文件的内容进行对比），判断文件内容是否被更改。如果文件内容没有改变，则将该文件新的时间戳记录到 .git/index 文件中。因为判断文件是否更改，使用时间戳、文件长度等信息进行比较要比通过文件内容比较要快的多，所以 Git 这样的实现方式可以让工作区状态扫描更快速的执行，这也是 Git 高效的因素之一。
git diff files用来进行具体文件的变动对比，通常用来进行工作区与暂存区之间的对比，实质上是用 git objects 库中的快照与工作区文件的内容的对比。
另外，Git中提供了几个相关的撤销操作的命令，如git reset、git revert、git checkout，这几者之间的用法各有不同。
二、git reset的用法
从上图可知：git reset -- files 用来撤销最后一次的git add files（因为每git add file一次，暂存区的文件都会被更改一次），你也可以用git reset 撤销所有暂存区域文件。 另外：
2.1、git reset的用法：git reset + commit号
1、git reset命令后面需要加2种参数："--hard"和"--soft"，如果不加，默认情况下是"--soft"。
2、--soft表示该条commit号之后（时间作为参考点）的所有commit的修改都会退回到git缓冲区中。所以使用git status命令可以在缓冲区中看到这些修改。
3、"--hard"则表示缓冲区中不会存储这些修改，git会直接丢弃这部分内容，但需要注意的一个问题是：这样的重置是直接在本地的修改，无法提交到远程服务器，如果直接丢弃的内容已经被推到远程服务器上了，则会造成本地和服务器无法同步的问题，即git reset --hard只能针对本地操作，不能针对远程服务器进行同样操作。如果从本地删掉的内容没有推到服务器上，则不会有副作用，如果被推到服务器，则下次本地和服务器进行同步时，这部分删掉的内容仍然会回来。
（其实这个问题则可以很好的被git revert 命令解决，使用git revert + commit号，该命令撤销对某个commit的提交，这一撤销动作会作为一个新的修改存储起来，这样，当你和服务器同步时，就不会产生什么副作用。）
其实在merge的时候，也有可能会用到git reset.
如果我们当前使用git pull的时候，可能会出现merge冲突，在冲突状态下，需要解决冲突的文件会从index暂存区打回到工作区。
如果有冲突的时候，一般用如下步骤解决冲突：
1、用工具或者手工解决冲突
2、git add 命令来表明冲突已经解决。
3、再次commit已解决冲突的文件。
这当中，可以使用git reset --hard ORIG_HEAD用来撤销已经commit的merge.
使用git reset --hard HEAD 用来撤销还没commit 的merge,其实原理就是放弃index和工作区的改动。
也可以使用git reset --merge ORIG_HEAD，注意其中的--hard 换成了 --merge，这样就可以避免在回滚时清除working tree。
三、git checkout的用法
从上图可知，git checkout -- files 把文件从暂存区域复制到工作目录，用来丢弃本地修改。 需要另外注意的是：
1、当执行 "git rm --cached
2、当执行 "git checkout ." 或者 "git checkout --
3、当执行 "git checkout HEAD ." 或者 "git checkout HEAD
四、git revert的用法
git revert 也是撤销命令，区别在于reset是指向原地或者向前移动指针，git revert是创建一个commit来覆盖当前的commit，指针向后移动。
那么两者的具体区别有：
1）git revert 是撤销某次操作，此次操作之前的commit都会被保留，而git reset 是撤销某次提交，但是此次之后的修改都会被退回到暂存区中。
具体一个例子，假设有三个commit(commit1,commit2,commit3)，使用 git status
commit3: add test3.c
commit2: add test2.c
commit1: add test1.c
当执行git revert HEAD~1时（撤销倒数第二个操作），第二个操作即commit2这个操作被撤销了，使用git log可以看到：
commit1：add test1.c
commit3：add test3.c
**由于git revert不会回退到暂存区中，所以使用git status 没有任何变化 **
如果换做执行git reset --soft(默认) HEAD~1后，运行git log可以看到
commit2: add test2.c
commit1: add test1.c
运行git status，可以看到test3.c处于暂存区了，准备提交。
但如果换做执行git reset --hard HEAD~1后，显示：HEAD is now at commit2，运行git log可以看到
commit2: add test2.c
commit1: add test1.c
运行git status， 则没有任何变化
所以，git revert与git reset最大的不同是，git revert 仅仅是撤销某次提交，而git reset会将撤销点之后的操作都回退到暂存区中。
1、git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
2、在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。
3、git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。
