在一本关于git的教科书中，我发现了这个命令提示符的简介，解释了开发人员在紧急情况下通常会如何反应，在紧急情况下，他必须临时安排当前的开发路线来修复错误。我对它的结局感到困惑：
$ cd the-git-project
# edit a lot, in the middle of something
# High-Priority Work-flow Interrupt!
# Must drop everything and do Something Else now!
# Create new branch on which current state is stored.
$ git checkout -b saved_state
$ git commit -a -m "Saved state"
# Back to previous branch for immediate update.
$ git checkout master
# edit emergency fix
$ git commit -a -m "Fix something."
# Recover saved state on top of working directory.
$ git checkout saved_state
$ git reset --soft HEAD^
# ... resume working where we left off above ...
考虑最后两个（即
git reset --soft HEAD^后跟git checkout saved_state）。为什么开发者会用这种方式回到原来的工作状态呢？把
saved_state合并到他的主分支中不是更好吗？我的第一个问题是，在这里执行
git reset --soft HEAD^有什么意义？假设开发人员在提交图中的这个位置（即，在这两个分支之间的合并基位置，在他的“保存状态”分支中）根据自己的喜好进行了更改，那么之后他将如何将这些更改合并到他最新的主分支中？ 最佳答案
1）他不想合并，因为在branchsaved_state上的工作只完成了一半，而且可能不稳定，所以无法将其合并回master
2）git reset --soft HEAD^：要回到他原来的状态：--soft只重置阶段HEAD^表示在这种情况下HEAD之前的先前版本
因此，他的工作目录与开始时相同，并且他的状态将突出显示他在“monkey commit”时所做的更改
但是，他本可以……更简单更干净（IMHO）。
关于git - 为什么在这里使用git reset而不是git merge？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/32147940/