由一个个case组成：
case 1
场景
在前一家公司的时候遇到过一次，没有完美解决，今天又重现了：我将部分代码从仓库A拆出来，放到新仓库B中，因为图方便，我直接使用了copy命令，但是！！！没有想起来隐藏的.git目录，于是新仓库B的初次提交直接更新到了A上。
解决办法
上一次遇到类似的问题，我是直接一个reset --hard 到错误 commit 的前一个 commit，但是自此之后，恶梦开始：因为我们组同学较多，多数从主分支切的代码已经是被污染过的，于是经常带着错误的commit回归！！！
我左思右想，无法找到合适的办法，好在此次开发的同学不多——并且各自切出去的分支都是没有被污染的，我手动reset了所有被污染的分支，再让同学们将已经提交的在污染之后的功能手动合并到主分支上。左右算是解决了。
这种错误的commit没有及时发现，发现时已经在后面提交了许多正常commit的情况应该不算少见，如何在发现之后方便地解决问题？我目前想到的就是使用git rebase的提交规范，保证大家的commit都是连续的，这样在解决此类错误的相对来说还是比较方便的。
case 2
场景
本地 reset 过猛，跑过头了，像以前我可能直接就把本地的仓库直接删了，再下载一个，今天忽然觉得太low了。于是我搜了下，发现一个很好玩的命令，git reflog
git reflog
git reflog 记录了本地git上的所有操作，并且有对应的索引，可以直接使用git reset 索引的方式，回归到对应的操作。
140c8eb [email protected]{0}: reset: moving to 140c8ebcf6d使用 140c8eb 和 [email protected]{0}都可以回归。