简介
在日常开发中，git 代码管理尤其重要，而回滚操作是开发者的一种必备技能，帮助我们回滚一些错误代码，
然后，回滚代码的操作有多种方式，每种方式都有各自的优势和适用场景，并且都存在一些的坑，本文通过实操详细讲解几种常见回滚操作的区别对比，帮助你在不同场景下选择合适的回滚方案
一、方案一：git revert
（一）使用
git revert 命令通过创建一个新的 commit 提交，来抵消指定的 commit 提交，
git revert 不会修改历史 commit 记录，而是会新增一个 commit 提交
例子如下：
shell
复制代码
## 查看当前 log
git log
commit 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef (origin/master, origin/HEAD)
Author: fiveyoboy
Date: Fri Aug 8 17:05:45 2025 +0800
commit 1
现在分支存在一个 log： 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef
执行 git revert
shell
复制代码
git revert 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef
会产生一个新 log
log
复制代码
commit 557c9dba197c64ae03313f4cb565b2848bbea94b (HEAD -> master)
Author: fiveyoboy
Date: Fri Aug 8 17:06:01 2025 +0800
Revert "commit 1"
This reverts commit 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef.
这种方法不会改变历史提交，而是添加一个新的提交来撤销之前的更改。
（二）优点
安全的撤销提交
这是 git revert最大的优势，通过 revert 掉，不会影响其他协作者的开发，这是最安全的（后面与 git reset 对比更加清晰）
不会修改历史提交，会生成新提交，方便审计
会新生成一个 commit，（后面与 git reset 对比更加清晰）
可以精准撤销某个 commit，不会影响该commit之后的提交（后面与 git reset 对比更加清晰）
比如 commit 1， commit 2， commit 3，git revert commit2，是不会影响后面 commit 3 的
（三）缺点
合并冲突
如果你revert 的 commit 有其他 commit 引用了，那么就会出现冲突
比如：如果要撤销的提交（Commit A）之后有新的提交（Commit B），而 Commit B 修改了 Commit A 涉及的相同代码行（或者依赖于 Commit A 的更改），那么 git revertCommit A 时很可能会产生合并冲突
历史记录变得很糟糕
其实也还好，多出一些 commit ，再操作整理一些 commit 即可
效率可能偏低
如果需要回滚的 commit 较多，那么操作起来就会比较复杂
（所以一般代码发布正式环境都需要将开发过程的所有 commit 压缩为一个 commit，不仅清晰好管理而且还发布回滚）
二、方案二：git reset
（一）使用
git reset 是开发中比较常用的命令之一，用于移动分支指针、修改暂存区（Index）或工作目录（Working Directory），从而实现对提交历史的调整。它的核心功能是重置当前分支的状态 ，但使用不当可能导致数据丢失（尤其是 --hard模式），因此需要谨慎操作
常见的参数有：
git reset 【分支/commit】： 表示基于【分支/commit】之后所有修改的代码撤销到暂存区（相当于你所有的代码都需要重新 commit）
git reset --hard 【分支/commit】： 重置分支到指定的 【分支/commit】，相当于【分支/commit】之后的所有提交全部丢失，存在风险
一般都是用 git reset --hard 进行撤销/回滚代码
例子如下：
shell
复制代码
git log
commit f655dcfb261a1d0b5c39443f75b78ff1805606db (HEAD -> master, origin/master, origin/HEAD)
Author: fiveyoboy
Date: Fri Aug 8 17:24:27 2025 +0800
commit -3
commit ea24b69c76872cec4e3bd22937a1e350e7022b16
Author: fiveyoboy
Date: Fri Aug 8 17:24:06 2025 +0800
commit 2
commit 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef
Author: fiveyoboy
Date: Fri Aug 8 17:05:45 2025 +0800
commit 1
可以看到现在有 3 个 commit
这时候我们不需要 commit 2，commit 3.，执行 git reset --hard 回滚到 【commit 1 】
sql
复制代码
git reset --hard 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef
git log
commit 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef
Author: fiveyoboy
Date: Fri Aug 8 17:05:45 2025 +0800
commit 1
会发现 log 记录中 commit 2，commit 3 不见了，实现了代码撤销/回滚的效果
（二）优点
完全清除代码和提交记录，非常干净
git reset --hard 真的是一键恢复到某个 commit 提交，非常干净
非常高效的回滚代码
如果你有多个 需要回滚的连续的 commit 提交，那么 --hard 非常高效，
快速清理分支
在某些情况下，你的开发分支如果确定没有任何代码修改，你可以直接重置 git reset --hard origin/master ，
然后再继续开发，可以避免后续合并代码出现一些非常脏的冲突
（三）缺点（高风险）
永久性数据丢失
安全性问题
在团队协作中，使用 git reset --hard 会出现严重的代码安全故障，
若对已推送的分支执行 reset --hard后强制推送（git push -f）：
✓ 改写远程历史 → 导致团队协作混乱
✓ 其他成员拉取代码时需强制同步（git pull -f），易引发代码覆盖冲突
具体见文章 关于 git reset --hard 引发的代码故障
三、方案三、手动回滚代码
顾名思义，手动注释/删除需要回滚的代码，
虽然很笨重，但是如果是回滚少量代码的情况下，非常推荐，少了很多操作上的麻烦和风险
总结
如果是少量代码的情况下，通过手动注释/修改代码的方式其实是最佳的
如果是不连续的多个 commit，那么使用 revert 是较为安全的
如果确实需求使用 git reset --hard ，一定要确保团队其他成员本地没有 merge 了你的代码，否则会产生严重代码故障（慎用）
原文地址
Git 如何正确回滚代码？常见回滚操作对比,适用不同的场景