Question

在一本关于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^有什么意义？假设开发人员在他的提交图中对此位置进行了更改（即，在这两个分支之间的合并基础上，在他的“保存状态”分支中），那么他之后会做什么以将这些更改与他的最新的主分支？

Answer 1

首先：在这种情况下，他们不想合并他们的工作。他们仍然在工作，所以它会非常适用于合并来自该分支的任何内容。

对我来说，这看起来像一个穷人的git-stash，它可以更好地涵盖这种情况和用例。

让我们看一下流程：

on branch saved_state
将工作提交至saved_state
on branch master
提交修复主人
on branch saved_state
将所有提交从saved_state的提示移动到索引

第二：git reset --soft允许您接受您指定的任何提交并将其放回工作索引中，就好像您之前没有提交过该工作一样。 HEAD^只是要完成你最后一次提交。

同样，它有点像穷人git-stash，执行起来要简单十倍：

on branch saved_state
藏匿工作
on branch master
提交修复主人
on branch saved_state
unstash（弹出或应用）以前隐藏的更改

Answer 2

1）他不想合并，因为分支saved_state上的工作只完成了一半而且可能不稳定，因此无法将其合并回master

2）git reset --soft HEAD^：准确地回到他所处的状态：

--soft仅重置舞台
HEAD^表示在此情况下HEAD之前的修订版

因此，他的工作目录与开头的工作目录相同，他的状态将突出显示他在“猴子提交”时所做的更改

但是，他可以git stash save -u ...更简单，更清洁（恕我直言）。

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

2 个答案: