git的使用回退功能

核心区别：reset vs revert
这是最重要的区别，理解了它就理解了 Git 回退的精髓：

git reset (重置/回滚): 会修改提交历史。它像一台时间机器，直接把你的分支带回到过去某个点，后面的历史记录就“消失”了。

适用场景：只在你自己的本地分支上使用。因为会修改历史，绝对不要在已经推送到远程的公共分支（如 main, develop）上使用！
危险性：较高，尤其是 –hard 模式。
git revert (撤销/反转): 不会修改历史，而是创建一个新的提交来抵消掉某个旧的提交。它像是在账本上写一笔“负数”来冲销之前的错误记录，而不是撕掉那一页。

适用场景：安全，适用于任何分支，尤其是已经推送到远程的公共分支。这是团队协作中推荐的回退方式。
危险性：低。
1. git reset：强大的本地时间机器
git reset 主要用来回退未推送的本地提交。它有三种模式，决定了它对你的工作区和暂存区的影响。

假设你的提交历史是 A -> B -> C，当前在 C (HEAD 指向 C)。现在你想回退到 B。

git reset <commit-B-hash>
# 或者更常用的，回退到上一个版本
git reset HEAD~1

三种模式：
–soft (温柔模式)

命令: git reset –soft HEAD~1
效果:
提交历史: 回退到 B。C 的提交被撤销。
暂存区 (Staging Area): 保留 C 提交时的所有更改，这些更改会处于“已暂存”状态。
工作区 (Working Directory): 保留 C 提交时的所有代码，文件内容不变。
一句话总结：撤销了提交，但保留了所有代码更改并放在暂存区，你可以马上重新提交。
应用场景：“我刚才的提交信息写错了，或者漏了几个文件，想把它们合并成一个新提交。”
–mixed (默认模式)

命令: git reset HEAD~1 (不加参数时默认就是 –mixed)
效果:
提交历史: 回退到 B。
暂存区: 清空。C 提交时的更改被移出暂存区。
工作区: 保留 C 提交时的所有代码，文件内容不变。
一句话总结：撤销了提交，也撤销了 git add，但代码还在。
应用场景：“我刚才的提交不仅有问题，我还想重新检查一下到底哪些文件需要提交。”
–hard (硬核/危险模式)

命令: git reset –hard HEAD~1
效果:
提交历史: 回退到 B。
暂存区: 清空。
工作区: 代码被丢弃。你的文件会完全恢复到 B 提交时的状态。
一句话总结：彻底抹除 C 提交的所有痕迹，包括代码更改。