Git 的 `reset` 命令是版本管理中的核心工具，其三种模式（`soft`、`mixed`、`hard`）的区别主要体现在对**暂存区（Index）**和**工作区（Working Directory）**的影响上。
---
### 一、`git reset --soft`
1. **核心行为**
• 仅移动 `HEAD` 指针到目标提交，**暂存区和工作区内容不变**。例如，若从提交 C3 回退到 C2，C3 的修改仍保留在暂存区。
• 相当于将 C2 到 C3 之间的修改“暂存”起来，等待重新提交。
2. **是否支持后续操作**
• **支持**：可直接执行 `git commit`，将暂存区的内容作为新提交（例如合并多个提交为一个）。
• 无需重新 `add`，因为修改已在暂存区。
3. **典型场景**
• 修改最近一次提交的提交信息或合并多次提交记录。
---
### 二、`git reset --mixed`（默认模式）
1. **核心行为**
• 移动 `HEAD` 指针，**重置暂存区**到目标提交状态，但**工作区内容不变**。例如，C3 的修改会从暂存区移除，但仍保留在工作目录中。
2. **是否支持后续操作**
• **支持**：需重新 `git add` 修改到暂存区，再执行 `git commit`。
• 工作区的改动未丢失，但需重新组织提交内容。
3. **典型场景**
• 撤销误添加到暂存区的文件（如 `git reset HEAD`）或重新选择提交内容。
---
### 三、`git reset --hard`
1. **核心行为**
• 移动 `HEAD` 指针，**重置暂存区和工作区**到目标提交状态，所有未提交的修改（包括暂存区和工作区）**永久删除**。
• 例如，从 C3 回退到 C2 时，C3 的所有改动将被丢弃。
2. **是否支持后续操作**
• **不支持**：若目标提交后的修改未备份，则无法恢复。需重新修改文件并 `add` 后才能提交。
• **危险操作**：慎用，建议先提交或备份重要改动。
3. **典型场景**
• 彻底放弃当前所有未提交的修改，强制代码回退到历史版本。
---
### 四、三种模式对比总结
| 模式 | HEAD指针 | 暂存区 | 工作区 | 是否支持继续操作 |
|----------|----------|------------|------------|-----------------------|
| `--soft` | 移动 | **保留** | **保留** | 直接 `commit` |
| `--mixed`| 移动 | **重置** | **保留** | 需重新 `add` 再 `commit` |
| `--hard` | 移动 | **重置** | **重置** | 需重新修改并 `add` |
---
### 五、实操建议
1. **优先使用 `--mixed`**：避免数据丢失，适合日常撤销暂存区错误。
2. **谨慎使用 `--hard`**：确保目标提交后的改动已备份或无价值。
3. **利用 `reflog` 恢复误操作**：即使误用 `--hard`，可通过 `git reflog` 找回丢失的提交记录。
通过合理选择模式，可灵活管理版本历史，同时避免数据风险。
