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

What's the difference between git reset --hard and git reset --merge

提问by opsb

In my experiments I haven't been able to find any functional difference between

在我的实验中，我无法找到任何功能差异

git reset --hard

and

和

git reset --merge

The usage instructions don't give any hint either

使用说明也没有给出任何提示

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

I regularly use the --hardoption so understand how that works. What's the difference between the --mergeand the --hardoptions?

我经常使用这个--hard选项，所以了解它是如何工作的。--merge和--hard选项之间有什么区别？

Cheers, Olly

干杯，奥利

Perhaps an example would help here, let's use the following sequence:

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

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

Now if I try

现在如果我尝试

git reset --merge 123abc

I get

我得到

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

the reason being that file_one has changes in both the working area and the index

原因是file_one在工作区和索引中都有变化

To remedy this I do

为了解决这个问题，我做

git add .
git reset --merge 123abc

This time it works, however, I get the same result as git reset --hard. The index is empty, working area is empty, file_one is empty, as it was after first commit.

这次它起作用了，但是，我得到了与git reset --hard. 索引为空，工作区为空，file_one 为空，就像第一次提交后一样。

Can someone come up with the steps that illustrate the difference?

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

采纳答案by Jakub Nar?bski

From git reset manpage:

从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.

The git reset --mergeis meant to be a safer version of git reset --hard, when your changes and somebody else changes are mixed together, trying to carry our changes around.

本git reset --merge是为了成为一个更安全的版本git reset --hard，当你的变化和别人改变混合在一起，想随身携带我们的变化。

回答by VonC

The article "Git undo, reset or revert?" summarizes the different usages, when used with ORIG_HEAD:

“ Git undo、reset 或 revert？”一文总结了不同的用法，当与 一起使用时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

As mentioned by manojlds's answer, and illustrated by the blog post, the latter is especially useful when you see an error message like:

正如manojlds的回答所提到的，并在博客文章中进行了说明，当您看到如下错误消息时，后者特别有用：

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

The thread "[PATCH] refuse to merge during a merge" also details that point:

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

git reset --merge HEAD

It fills the rather different case where you did a clean merge with some uncommitted changes in the worktree, but then want to discard the merge again without losing the uncommitted changes.
In absence of the changes, you would just use --hard, but here you want to move the branch tip while merging them over, similar to what 'git checkout -m' does for moving HEAD.

它填补了完全不同的情况，即您对工作树中的一些未提交的更改进行了干净的合并，但随后又想再次丢弃合并而不丢失未提交的更改。
在没有更改的情况下，您只需使用--hard，但在这里您希望在合并它们的同时移动分支尖端，类似于 ' git checkout -m' 对移动的作用HEAD。

回答by manojlds

This is helpful when you do a pull with changes in working tree, and find that the merge is not as expected ( you might have been expecting that the commits would not affect the files you were working on ). At this point, if you do git reset --hard ORIG_HEAD, you blow away everything, including your local changes. If you do git reset --merge ORIG_HEAD, you will keep your local changes.

当您对工作树中的更改进行拉取并发现合并不符合预期时（您可能一直期望提交不会影响您正在处理的文件），这很有用。在这一点上，如果你这样做git reset --hard ORIG_HEAD，你会吹走一切，包括你的本地更改。如果这样做git reset --merge ORIG_HEAD，您将保留本地更改。

回答by Jon

Apparently according to:

显然根据：

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

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

--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.

--hard- 将工作树和索引与要切换到的树的索引相匹配。此后对工作树中跟踪文件的任何更改<commit>都将丢失。

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