目录

应用场景

错误做法

正确做法-方式1

正确做法-方式2

正确做法-方式3

---

应用场景

比如现在我修改了两个文件：

然后我高高兴兴地把它推送到了远程xianglinteng分支

现在，我突然反悔了，想要回到修改之前的代码，即回到master分支的样子。

错误做法

直接拉取master分支：

结果就是，拉取前后没有任何变化，并没有同步到master分支，当前内容仍然是修改后的内容：

原因是：相当于你基于5.1版本更新了分支，然后又拉取5.1版本的master分支，那你当前的分支本来就是基于5.1版本更新的，对master来说，你已经拉取了它，并且还在其基础上更新了代码，所以你再拉取，最终的结果还是你目前的分支。有点绕，看不懂没关系，知道什么效果就行了

正确做法-方式1

在gitee页面回滚这次远程分支的推送：

然后重新在本地拉取xianglinteng分支：

现在，当前的代码就还原成修改之前的样子了（基于master的修改）：

正确做法-方式2

直接在本地还原提交

先找到git日志：

不管是在本地分支还原提交，还是在远程分支还原提交。最后都是本地的内容会被还原，远程推送的代码不会还原：

本地代码还原了：

远程分支的代码没有还原：

并且这两种方式，只要其中一个操作过了，在执行另一个时，会提示已还原：

如果再对同一个位置进行修改，推送到远程分支时，不会提示冲突，而是直接将最新的修改覆盖掉之前的修改（最开始推送到远程分支的那个修改），比如我在相同的位置添加b=1。

第一次推送到远程分支时是b=0：

最新的推送会直接覆盖之前的推送。（前提是修改的位置在同一处）

正确做法-方式3

直接基于远程master分支创建一个新的本地分支并签出，这样，这个新的本地分支就是master的内容了。这种方式的优点是能跟已修改的本地分支形成对照。缺点是原先的本地分支可能没用了，没有特殊需求的话，应该会删掉，不过如果觉得原先的内容还有用，留着也行。

这样，该分支的内容就跟master同步了：