reset和revert最佳实践

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

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

1️⃣ revert 做了什么？

bash 复制代码

git revert <commit>

它的本质是：

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

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

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

假设原历史：

text 复制代码

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

执行：

bash 复制代码

git revert C

结果：

text 复制代码

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 的三种模式（重点）

bash 复制代码

git reset --soft
git reset --mixed  (默认)
git reset --hard

但 不管哪种：

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

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

原始提交历史

text 复制代码

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

执行：

bash 复制代码

git reset --hard B

reset 之后：

text 复制代码

A --- B (HEAD)

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

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

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

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

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

1️⃣ --soft（只改 HEAD）

bash 复制代码

git reset --soft B

结果：

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

📌 等价于：

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

2️⃣ --mixed（默认）

bash 复制代码

git reset B

结果：

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

📌 等价于：

"撤回提交 + 取消 add"

3️⃣ --hard（最危险）

bash 复制代码

git reset --hard B

结果：

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

⚠️ 代码直接没了

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

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

六、真实工程中的使用建议

✅ 已 push / 多人协作分支（main、develop）

✔ 只能用 revert

bash 复制代码

git revert <commit>

✅ 本地分支 / 还没 push

✔ reset 非常好用

bash 复制代码

git reset --soft HEAD~1

用于：

合并提交
修改 commit message
整理提交历史