为什么在这里使用git reset而不是git merge？

在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\u state

合并到他的主分支中不是更好的做法吗

---

尽管有我的第一个问题，在这里执行

git reset--soft HEAD^

有什么意义？假设开发人员在其提交图中的这个位置（即，在这两个分支之间的合并基础上，在他的“保存状态”分支中）对自己喜欢的内容进行更改，那么之后他将如何将这些更改合并到最新的主分支中？

首先：在这个场景中，他们不想合并他们的工作。他们仍在工作，因此将该分支中的任何内容合并在一起会产生反效果

对我来说，这看起来像是穷人的，这将更好地涵盖这个场景和用例

让我们看看流程：

• 在分支保存状态上
• 将工作提交到保存的状态
• 论分行行长
• 向主机提交修复程序
• 在分支保存状态上
• 将所有提交从保存状态的尖端移动到索引中

第二：

git reset--soft

允许您进行指定的任何提交，并将其放回工作索引中，就像您以前没有提交过该工作一样

HEAD^

只会得到您所做的最后一次提交

同样，它有点像一个穷人的

git存储

，执行起来要简单十倍：

• 在分支保存状态上
• 藏匿工作
• 论分行行长
• 向主机提交修复程序
• 在分支保存状态上
• 取消刷新（弹出或应用）以前隐藏的更改

1）他不想合并，因为分支

保存的\u状态

的工作只完成了一半，可能不稳定，因此无法将其合并回

主

2）

git reset--soft HEAD^

：要完全回到他当时的状态：

• --soft

  仅重置阶段

• HEAD^

  表示在这种情况下

  HEAD

  之前的先前版本

因此，他的工作目录与开始时相同，他的状态将突出显示他在“monkey commit”时所做的更改

---

但是，他本可以

git stash save-u

。。。更简单、更干净（IMHO）。

因此，基本上，他达到了中断前的状态，并放弃了“猴子提交”（可能不够干净，不想提交到他的项目的正式历史中）。这是正确的吗（除了

git-stash

可能是更好的方法之外）？