Git 如何正确回滚代码？常见回滚操作对比,适用不同的场景

简介

在日常开发中，git 代码管理尤其重要，而回滚操作是开发者的一种必备技能，帮助我们回滚一些错误代码，

然后，回滚代码的操作有多种方式，每种方式都有各自的优势和适用场景，并且都存在一些的坑，本文通过实操详细讲解几种常见回滚操作的区别对比，帮助你在不同场景下选择合适的回滚方案

一、方案一：git revert

（一）使用

git revert 命令通过创建一个新的 commit 提交，来抵消指定的 commit 提交，

git revert 不会修改历史 commit 记录，而是会新增一个 commit 提交

例子如下：

## 查看当前 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

git revert 63bd9f19c8c0a97ed9a0ced833b75ceda8f14eef

会产生一个新 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 进行撤销/回滚代码

例子如下：

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 】

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 如何正确回滚代码？常见回滚操作对比,适用不同的场景