Git command之回退篇
欲练回退 必先了解：HEAD、index、WorkingCopy
HEAD: 对应local repository，指当前所在的分支版本顶端的别名，也就是最新的一次commit. git commit 之后与HEAD一致
index: 对应staging area,指git add 之后放入该区域
WorkingCopy: 对应working directory，指当前文件包括修改等操作所在区域，没有 git add 和 git commit 操作
git reset HEAD --file (回退单个文件版本)
可与git checkout --file(撤销单个文件修改)配合
git reset HEAD --file：【回退版本】回退暂存区里的某个文件，还原为HEAD commit里该文件的状态，撤销从上一次commit之后所有的操作。或者说是从HEAD commit里重新拉到暂存区覆盖当前的(被add乱掉的)文件。但是working copy里没有任何变化。此时如果想丢掉working copy里的修改，执行git checkout --file.
git checkout --file：【撤销修改】是以最新的存储时间节点（add和commit）为参照，覆盖工作区对应文件file：
①如果上次commit之后没有将任何修改add到暂存区，则HEAD和暂存区是一致的，执行命令后也会将工作区同化为一致，看起来像是从HEAD版本库重拉了一遍到工作区。
②但如果上次commit之后往暂存区add了修改，那么工作区只能跟暂存区一致了，也就是从暂存区拉下来覆盖到工作区。
git reset --hard HEAD
影响同下面介绍的<git reset --hard 目标版本号>，只是HEAD位置看起来没有变化。小技巧：上个版本用HEAD或者HEAD~1,上上个版本HEAD^或者HEAD2，上100个版本HEAD100
git reset --hard 目标版本号
版本号指：commit生成的hash码，可用 git log 命令查看
该命令修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本，最后需要用 git push -f 强推到远端
--hard参数将会blow out everything.它将重置HEAD返回到另外一个commit，重置index以便反映HEAD的变化，并且重置working copy也使得其完全匹配起来。
这是一个比较危险的动作，具有破坏性，数据因此可能会丢失！如果真是发生了数据丢失又希望找回来，那么只有使用：[git reflog](http://blog.csdn.net/ibingow/article/details/7541402)命令了。
git reset --soft 目标版本号
--soft参数Git重置HEAD到另外一个commit，HEAD位置改变，但index,working copy都不会做任何变化，所有的在original HEAD和你重置到的那个commit之间的所有变更集都放在stage(index)区域中。
git reset --mixed 目标版本号
--mixed是reset的默认参数，也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD相匹配，但working copy不会被更改。所有该branch上从original HEAD（commit）到你重置到的那个commit之间的所有变更（未git add的操作）将作为local modifications保存在working area中，你可以接着coding，之后再进行git add, git commit.
总结：--hard --mixed(default) --soft 分别覆盖3个、2个、1个位置的代码，--mixed（默认的参数）只会保留working copy里的代码
git revert -n 目标版本号
- 与git reset不同的是，复制了一个目标版本（某个想要回退到的历史版本）加在当前分支的最前端。而git reset是HEAD指针跳到目标版本，但将跳过的版本丢弃掉了。(git log已经看不到，但git rflog还是可以看到的)
- use 'git commit -m "the name of the new release" ' to commit
- use 'git push' to push
git commit --amend
- 改写commit，包括改写提交的文件和追加文件到提交中。
- 还可以对这种改写回退，用git reflog得到相应的版本号，然后git reset --soft HEAD@{xxx}