git reset 的三种模式

git reset 是 Git 中一个非常强大的命令，用于撤销更改、回滚提交等操作。它可以更改当前分支的 HEAD 指向，同时控制是否保留工作区和暂存区的内容。

git reset 的三种模式

1. --soft：仅重置提交记录，保留暂存区和工作区的更改。
2. --mixed（默认模式）：重置提交记录和暂存区，但保留工作区的更改。
3. --hard：重置提交记录、暂存区和工作区，所有更改都会丢失。

以下是一些常见的使用示例。

---

1. git reset --soft 示例

场景：

提交了一次更改，但发现提交信息写错了，想修改提交信息。

操作：

git reset --soft HEAD~1

解释：

• HEAD~1 表示回退到当前提交的前一个提交。
• 使用 --soft，回退后提交的更改会保留在暂存区中（git status 会显示已暂存的文件）。
• 可以直接重新提交：

git commit -m "新的提交信息"

---

2. git reset --mixed 示例

场景：

提交了一些更改，但发现有文件不应该被包含在提交中，想重新选择提交的文件。

操作：

git reset --mixed HEAD~1

解释：

• HEAD~1 表示回退到上一个提交。
• 使用 --mixed，回退后提交的更改会从暂存区移出，但保留在工作区中（git status 会显示为未暂存的文件）。
• 重新选择需要提交的文件：

git add 需要提交的文件
git commit -m "正确选择的提交"

---

3. git reset --hard 示例

场景：

提交了一些更改，并且修改了工作区中的文件，后来发现不需要这些更改，想完全回到某个提交的状态。

操作：

git reset --hard HEAD~1

解释：

• 使用 --hard，提交记录、暂存区和工作区都会回退到指定的提交状态，所有未保存的更改都会被丢弃。

⚠️ 注意：--hard 会丢失工作区中的所有未提交内容，操作前需谨慎！

---

4. 回到指定提交

场景：

回退到一个特定的提交，而不是相对的提交（如 HEAD~1）。

操作：

git reset --hard 提交哈希值

解释：

• 提交哈希值 是通过 git log 查看到的提交 ID，例如 a1b2c3d4。
• 这会将当前分支的 HEAD 指针重置到该提交，并丢弃之后的所有提交和更改。

---

5. 从某个分支或提交中恢复文件

场景：

从另一个分支或历史提交中恢复某个文件，而不是整个分支。

操作：

git reset 提交哈希值 -- 文件路径

示例：

git reset HEAD~2 -- src/example.txt

解释：

• 重置指定文件到某个提交状态（如 HEAD~2）。
• 工作区中的文件会被更新为该提交状态的内容，但是暂存区不受影响。

---

6. 撤销 git add 操作

场景：

不小心使用 git add 将一些文件添加到了暂存区，但还没有提交，想把文件移回工作区。

操作：

git reset 文件路径

示例：

git reset src/example.txt

解释：

• 这个命令会将 src/example.txt 从暂存区移出，但工作区中的更改不会丢失。
• 使用 git status 可以看到该文件回到了未暂存状态。

---

7. 撤销最近的合并

场景：

合并了一个分支，但发现有问题，想撤销这次合并。

操作：

git reset --hard ORIG_HEAD

解释：

• ORIG_HEAD 是 Git 自动生成的一个指针，指向合并前的提交。
• 这会将当前分支状态回退到合并之前。

⚠️ 注意：如果合并后有额外的提交或更改，这些更改也会被丢弃。

---

8. 使用 reset 修复错误提交到错误分支

场景：

在错误的分支上提交了更改，想将提交移到正确的分支。

操作：

# 回退提交，但保留更改
git reset --soft HEAD~1
# 切换到正确的分支
git switch 正确的分支
# 将更改提交到正确的分支
git commit -m "提交到正确的分支"

---

总结

git reset 是一个灵活的命令，可以用来回退提交、撤销暂存、更改文件状态等。三种模式的主要区别在于对提交记录、暂存区和工作区的影响：

模式	提交记录	暂存区	工作区
--soft	回退	保留	保留
--mixed	回退	清空	保留
--hard	回退	清空	清空