背景
最近在开发中遇到一次飞醋严重的代码故障，同事 A 上线了一个需求，但是由于设计原因，需求代码要严重的线上故障，需要紧急回滚，除了部署回滚之外，同事 A 使用了 git reset --hard 进行的代码回滚，然后重新进行了部署发布，看起来是没有什么问题，但是在发布之后不久，团队内另外的同事 B 也发布了需求代码，这时候故障再次产生了，原因是同事 B 将同事 A 回滚的代码再次发布到了正式环境，
同事 B 在合并代码之前确实是再次合并了线上 master 的代码，那么问题来了，为什么同事 A 明明已经 reset 了代码，同事 B 为什么还能又给带到了正式环境
分析
分析后发现，git reset --hard 强制修改了 master 分支的历史提交记录，导致故障产生
完整操作如下
| - | commit 情况 | |
|---|---|---|
| - | 线上 master 分支最新 log commit： "last commit" | commit f655dcfb last commit |
| 同事 A | 提交 commit "需求 1" 到 master 分支 | commit f655dcfb1 需求1 commit f655dcfb last commit |
| 同事 B | 从 master 分支切换了新的需求分支（此时带有 commit "需求 1" ） | commit f655dcfb1 需求1 commit f655dcfb last commit |
| 同事 A | 强制 git reset --hard 到 commit "需求 1" 之前的一个 commit， 也就是 "last commit" 并且执行了 git push -f | commit f655dcfb last commit |
| 同事 B | 需求开发完成，提交 commit ：“需求2 ”，合并了 master 分支的最新代码， 并且将新需求的代码合入了 master | commit f655dcfb2 需求2 commit f655dcfb1 需求1 commit f655dcfb last commit |
从操作上来看，虽然同事 A 线上 git reset --hard 了代码，但是如果其他同事本地仓库就有了这些代码，那么在合并的时候 git 无法识别哪些是被回滚的（因为没有历史记录，无法对比），只能认为这些新添加的
解决
在找到原因之后，解决方法也比较简单
关于 git 代码回滚的几种方案对比，请移步文章 Git 如何正确回滚代码？常见回滚操作对比，适用不同的场景
（一）方法一
不用 git reset --hard，改为 revert
git revert 不同于 --hard，会产生一个新的 commit，这样子其他同事本地 pull 的时 git 就能正确识别合并代码
（二）方法二
如果确实是需要使用 git reset --hard ，在使用之前需要提前和团队内其他成员进行沟通，确保其他成员本地仓库没有拉取你这些需要回滚的代码，才能确保最终代码正常
那么还有一个问题，已经使用了 git reset --hard，造成了代码故障了，也就是上述的情况，应该怎么处理解决？
这就需要团队其他成员检查本地分支是否已经合并了回滚的代码，使用
# 重置本地 master 分支 或者直接删除重新 checkout
git pull -f
git reset --hard origin/master
# 当前分支和 origin/master 进行对比，会展示差异
git diff origin/master
这应该是所有使用 git 的开发者在合并代码时的一个必备操作，很明显同事 B 并没有这样做
通过和 master 进行 diff，就可以展示哪些变动不是你修改的，选择丢弃即可
总结
-
团队协作中，尽可能不用 git reset --hard
-
合并代码时，一定要先进行 diff 合入分支，确保所有变动代码都是你改的（必做操作）
原文地址
