git reset 三种模式来重置当前分支的 HEAD 到指定的提交：--hard、--mixed（默认选项）和 --soft

1. --hard

• 作用：将 HEAD 移动到指定的提交，并且会把工作目录和暂存区都重置为该提交的状态。任何未提交的工作都会被丢弃。
• 适用场景：当你想要完全恢复到某个历史提交的状态，并且不介意丢失自那个提交以来的所有更改时使用。
• 风险：因为所有未提交的更改都会被丢弃，所以如果不确定要做什么或没有备份，应该非常谨慎地使用 --hard 模式。

示例：git reset --hard <commit-hash>

2. --mixed (默认)

• 作用：将 HEAD 移动到指定的提交，仅重置暂存区以匹配该提交的内容，但不会影响工作目录中的文件。这意味着你的工作目录保持不变，而暂存区则会被清空，所有更改变为未暂存状态。
• 适用场景：当你想取消暂存区的更改，但又不想丢失工作目录中的修改时使用。这是最安全的选择，因为它允许你在决定是否继续之前检查更改。
• 风险：相对较低，因为你仍然可以查看和选择性地重新添加更改到暂存区。

示例：git reset --mixed <commit-hash>

或者简单地：git reset <commit-hash>

3. --soft

• 作用：只移动 HEAD 到指定的提交，既不改变工作目录也不改变暂存区。也就是说，它保留了所有已暂存的更改作为待提交的更改。
• 适用场景：当你只想取消最近的一次提交，但保留所有更改以便你可以重新组织提交信息或调整提交内容时使用。
• 风险：几乎没有风险，因为所有的更改都被保留下来了，只是提交历史被改变了。

示例：git reset --soft <commit-hash>

总结

模式	工作目录	暂存区	使用场景
--hard	重置为指定提交	重置为指定提交	完全回滚到某个历史提交，可能丢失未提交的更改
--mixed	保持不变	重置为指定提交	取消暂存区的更改，但保留工作目录中的更改
--soft	保持不变	保持不变	只是移动 HEAD，保留所有更改

选择哪种模式取决于你希望如何处理未提交的更改以及你对项目历史记录的管理需求。对于团队合作而言，通常建议尽量避免使用 --hard 重置，特别是在已经推送过更改的情况下，以免造成其他开发者的困扰。