git reset --hard 和 git reset --merge 之间有什么区别

Question

在我的实验中，我无法发现

git reset --hard

和

git reset --merge

之间的任何功能差异。使用说明没有给出任何提示，

--hard                reset HEAD, index and working tree
--merge               reset HEAD, index and working tree

我经常使用 --hard 选项，因此了解其工作原理。 --merge 和 --hard 选项有什么区别？

干杯， Olly

也许一个例子会有所帮助，让我们使用以下序列：

cd git_repo
touch file_one
git add file_one
git commit -m "commit one" # sha1 of 123abc
echo "one" >> ./file_one
git commit -a -m "commit two" # sha1 of 234bcd
echo "two" >> ./file_one
git add . # populate index with a change
echo "three" >> ./file_one # populate working area with a change

现在，如果我尝试

git reset --merge 123abc

，我得到的

error: Entry 'file_one' not uptodate. Cannot merge.
fatal: Could not reset index file to revision '123abc'

原因是 file_one 在工作区域和索引中都有更改

为了解决这个问题，我这样做了

git add .
git reset --merge 123abc

这次它有效，但是，我得到了与 git reset --hard 的结果相同。索引为空，工作区为空，file_one 为空，就像第一次提交后一样。

有人可以想出说明差异的步骤吗？

Answer 1

来自 git Reset 手册页：

--hard    Matches the working tree and index to that of the tree being
               switched  to. Any changes to tracked files in the working tree since
               <commit> are lost.

--merge
              Resets the index to match the tree recorded by the named commit, and
              updates the files that are different between the named commit and
              the current commit in the working tree.

git reset --merge 是旨在成为 git reset --hard 的更安全版本，当您的更改和其他人的更改混合在一起时，试图携带我们的更改。

Answer 2

文章“Git 撤消、重置或恢复？”总结了与 ORIG_HEAD 一起使用时的不同用法：

# Reset the latest successful pull or merge
$ git reset --hard ORIG_HEAD

# Reset the latest pull or merge, into a dirty working tree
$ git reset --merge ORIG_HEAD

如 manojlds的答案，并由 博客文章，当您看到如下错误消息时，后者特别有用：

fatal: You have not concluded your merge. (`MERGE_HEAD` exists)

线程“[PATCH] 在合并期间拒绝合并" 也详细说明了这一点：

git reset --merge HEAD

它填补了相当不同的情况，即您与一些未提交的内容进行了干净的合并
工作树中发生更改，但随后希望再次放弃合并而不丢失未提交的更改。
如果没有更改，您只需使用 --hard，但在这里您想要在合并它们时移动分支尖端，类似于“git checkout -m” ' 是为了
移动HEAD。

Answer 3

tl;dr git reset --merge 是用于撤消合并的 git reset --keep 。 git reset --keep 是 git reset --hard 尝试保留未暂存的更改。此外， git reset --hard 可能会更改未暂存的文件（

任何未跟踪的文件或写入任何跟踪文件的目录都会被删除。

我认为您通常想了解的有关 git reset --merge 的内容已由 @manojlds 的 @manojlds（合并之前工作树中的更改；冲突或干净合并）。因为这看起来像 git reset --merge 的用例。

但您可能还需要考虑以下两种情况：

1. 如果在合并之前工作树没有发生任何更改，并且您正在解决冲突，git reset --merge ORIG_HEAD< /code> 与 git reset --hard ORIG_HEAD 没有太大区别。除非您此时开始开发新功能（进行与解决冲突无关的更改）。也就是说，如果您想要撤消合并，您很可能想要撤消所有内容。在这种情况下，您只需执行 git merge --abort 即可。

   但在这种情况下， git reset --merge ORIG_HEAD 会保留未暂存的更改。对有冲突的文件进行的更改（丢弃）和对暂存文件进行的更改（中止）除外。

   尽管从理论上讲它可能很方便，但听起来不像 git reset --merge 的用例。

   


2. 如果您没有在解决冲突，并且想要将 git reset --merge 到任意提交，它将尝试保留未暂存的更改。但 git reset --keep 也会如此。后者在合并过程中根本不起作用，并且会忽略分阶段的更改。

   如果无法保留未暂存的更改，它们将中止。如果您更改的文件在 HEAD 和 之间也发生过更改，就会发生这种情况。

Answer 4

显然根据：

http://www.kernel。 org/pub/software/scm/git/docs/git-reset.html

--hard - 将工作树和索引与要切换到的树相匹配。对工作树中跟踪文件的任何更改
因为 丢失了。

--merge - 重置索引以匹配指定提交记录的树，并更新指定提交之间不同的文件
提交和工作树中的当前提交。

Answer 5

当您对工作树中的更改进行拉取并发现合并未按预期进行时（您可能期望提交不会影响您正在处理的文件），这会很有帮助。此时，如果您执行 git reset --hard ORIG_HEAD ，则会清除所有内容，包括本地更改。如果您执行git reset --merge ORIG_HEAD，您将保留本地更改。