回退代码——git revert / git reset

git revert

适用于一些简单场景的的代码回退：

这个操作的本质是创建一个指定的commit的反向代码的commit

比如你在某个commit里面进行了【添加了一行代码A，并删减了一行代码B】的修改操作，我们将本次操作命名为commit1

那么你在进行对该次commit的git revert操作时，会创建一个内容包含了【删除了一行代码A，并添加了了一行代码B】的commit，我们将本次操作命名为commit2

那么此时git的head指针指向的是commit2

【

所以这就有一个问题了，如果说head指针的指向的是commit2，那么就意味着另一个包含有commit1的分支在尝试merge这个分支的时候，git将无法识别到commit1，因为git会认为commit1是一个已经提交过的代码

】

可能上面的【理论分析】还有点云里雾里，那么举个例子就好说明上面的情况了：

现在有一个主分支master，今天有一个dev_20231109分支合到master，合进去以后才发现，今天不是11月8号吗？然后你用git revert操作回滚了刚刚的merge操作。可是当年隔天（11月9号）再次准备将这个dev_20231109合到master的时候你会发现，两个分支竟然毫无差异！这就是我上面提到的点：git会认为你在9号这天的merge操作中的commit差异，已经在昨天8号的merge操作合并过了，这就是往往导致git合并时丢失代码的一个原因，此时的代码完全可以抢救，接下来要介绍的正儿八经的git回退代码——git reset

git reset

git reset是正儿八经的回退代码的git代码，为什么这么说呢？因为它可以移动head指针到达指定位置

我们还是举上面那个例子，假设，你在8号这天进行dev_20231109合到master这个操作之前的最后一个commit的编号是【A001】（这个编码你可以在任何包含git信息的页面看到，比如如下图所示的这个，一般会显示成一个比较短的号码，如图只有de40fd5，实际的完整编码是非常长的，但是git可以通过这个显示的短号码匹配到正确的commit），而把8号那天的dev_20231109合到master的这个commit的编号为【A002】，那么reset需要指向的是这次错误的提交【A002】前的最后一次正确的提交【A001】

此时你首先执行

git reset --hard A001

将本地分支的head指针指向A001

git push -f

然后将本地分支推送到远程仓库

此时你会发现你再次创建dev_20231109合到master的merge请求时，git就能显示正确的差异了