本文认为读者有基本git知识，知道pull push branch的基本用法。在此基础上进行延伸介绍。

首先假设一个场景：A和B都在dev分支开发，A和B在本地都有提交，分别为a和b。此时，A push提交a到服务器，正常提交。然后当B想提交b的时候，Git会提示提交失败，你的分支不是最新的。此时一般人会直接git pull 然后git push，但是你有看过这样产生的git log吗？你会发现，你在git pull 的时候，实际上内部git做了这样的操作：

1 从服务器拉取分支到本地
2执行 git merge 操作

由于有merge操作，所以在看git log 的时候，会发现多了一个merge into XXX的提交记录。如果想不要这个多余的提交，怎么做？git pull -r即可。 执行git pull -r，会在内部执行第二步的时候，从merge变成rebase操作。这样产生的log就会是：根提交——a——b。而不是 根提交——a——b——merge。

rebase命令具体是什么含义？可以看看这篇文章。在我看来，rebase是让git提交记录更加干净清晰。在某些情况下更是有奇效。很多情况下，服务器需要配置数据库、微信支付等敏感信息，或者需要根据环境不同选择执行不同的代码。当然，选择全部做成配置文件然后加入gitignore文件也是一种办法，这里提供另外一种思路：
git仓库中秘钥信息等都为空，部署到服务器之后将信息完善，然后创建提交。开发过程中需要同步服务器的时候，在服务器执行git rebase可以完美更新服务器，不会有烦人的merge信息确认框，让自动部署更加方便。

git reset也是一个很好用的命令。用sourcetree之类的，回滚到某个版本，就是用的这个命令。在看git log的时候，会看到commit后面有串很长的字符串，那就是这个提交的hash值。git reset --hard HASH就可以回退到对应版本去。当你只想回退到上个版本时，还可以用 git reset --hard HEAD^。这里的--hard表示代码也回退到对应版本，否则git reset HEAD^相当于是“撤销上次提交”，版本回退到上个版本，但是代码不变。

git reset HEAD^用在哪里呢？某次提交，发现自己改错文件了，或者提交信息没写，那么可以执行git reset HEAD^，改正后执行git push -f，强制提交，覆盖自己之前的提交。但是注意！git push -f非常非常非常危险！必须保证没有其他人提交的情况下才能用，否则其他人的提交也会被覆盖！

当我想要回退某个文件到某个版本，可以用git checkout HASH FILE。获取对应版本的文件，然后按需要修改即可。