当前位置：首页 > news >正文

reset和revert最佳实践

news 2026/6/15 17:07:09

git revert = 新增一个“反向提交”，历史不变
git reset = 移动 HEAD / 分支指针，历史被重写

一、git revert：不修改已有 Git 历史

1️⃣ revert 做了什么？

gitrevert<commit>

它的本质是：

生成一个新的 commit
这个新 commit 的内容 = 把指定 commit 的修改「反向再做一遍」

📌原来的 commit 还在，历史是线性的

2️⃣ revert 之后的 git log 长什么样？

假设原历史：

A --- B --- C --- D (HEAD)

执行：

gitrevert C

结果：

A --- B --- C --- D --- E (HEAD)

其中：

C：原提交（还在）
E：revert C 的提交（内容上抵消 C）

📌Git 记录没有被删，没有被移动，只是多了一条提交

3️⃣ revert 的特点总结

✅安全

适合已经 push 到远端的分支
不影响其他人

❌历史会“变长”

会看到「提交 + revert 提交」

📌 面试一句话：

revert 是“用新的提交修正旧的提交”，不破坏历史

二、git reset：直接改 Git 历史（移动指针）

reset 的核心动作只有一个：

把 HEAD / 当前分支指针，指向一个旧的 commit

1️⃣ reset 的三种模式（重点）

gitreset --softgitreset --mixed(默认)gitreset --hard

但不管哪种：

提交历史都会被改（HEAD 回退）

三、git reset 执行后，git 记录长什么样？

原始提交历史

A --- B --- C --- D (HEAD)

执行：

gitreset --hard B

reset 之后：

A --- B (HEAD)

📌C、D 在当前分支历史中消失了

⚠️ 但注意一句非常关键的点：

C、D 并不是立刻被删除，只是“不可达”了

只要还没被 GC（垃圾回收），还能用git reflog找回。

四、reset 三种模式对「工作区 & 暂存区」的影响

1️⃣ --soft（只改 HEAD）

gitreset --soft B

结果：

提交历史：❌ 被改（C、D 消失）
暂存区：✅ 保留
工作区：✅ 保留

📌 等价于：

“撤回提交，但改动还在，且已经 add 过了”

2️⃣ --mixed（默认）

gitreset B

结果：

提交历史：❌ 被改
暂存区：❌ 清空
工作区：✅ 保留

📌 等价于：

“撤回提交 + 取消 add”

3️⃣ --hard（最危险）

gitreset --hard B

结果：

提交历史：❌ 被改
暂存区：❌ 清空
工作区：❌ 清空

⚠️代码直接没了

五、revert vs reset 终极对比表（面试版）

对比点	git revert	git reset
是否修改已有提交历史	❌ 不修改	✅ 修改
是否生成新 commit	✅ 是	❌ 否
提交记录是否“变短”	❌ 不会	✅ 会
是否安全用于已 push 分支	✅ 安全	❌ 危险
适合场景	回滚线上/公共分支	本地整理提交