git-reset 的 --merge 和 --keep 标志的典型用例是什么？

Question

在recent answer 中，他详细介绍了git-reset 三个最常用选项（--hard、--mixed 和--soft）的典型用例，torek 顺便提到了@ 987654330@ 还提供了两个相对深奥的标志，称为--merge 和--keep。 git-reset man page 描述这两个标志如下：

--merge
           
   Resets the index and updates the files in the working tree
   that are different between <commit> and HEAD, but keeps
   those which are different between the index and working tree
   (i.e. which have changes which have not been added). If a
   file that is different between <commit> and the index has
   unstaged changes, reset is aborted.

   In other words, --merge does something like a git read-tree
   -u -m <commit>, but carries forward unmerged index entries.

--keep
    Resets index entries and updates files in the working tree
    that are different between <commit> and HEAD. If a file that
    is different between <commit> and HEAD has local changes,
    reset is aborted.

我完全理解何时使用--hard、--mixed或--soft，但我在阅读torek的答案时才知道--merge和--keep存在，我想不出实际用例这两个标志中的......您通常在什么情况下使用这两个标志？

我主要是在寻找一个简单的英语解释。以this answer by VonC 的以下段落为例，该段落阐述了git reset --soft 的典型用例：

[...] 每次：

• 您对最终得到的结果感到满意（就工作树和索引而言）
• 您对所有带您到达那里的提交都不满意：

git reset --soft 就是答案。

但是，我并不反对对这些标志进行一些小实验，在精神上类似于我在 this answer of mine 中发布的愚蠢购物清单示例。

Answer 1

试试这个。

如果你从树枝上拉下来，之后你会看到，哦！有多个冲突。然后突然你记得你从错误的分支中拉出然后它会帮助恢复它。

git reset --merge HEAD@{1}

Answer 2

来自https://git-scm.com/docs/git-reset

reset --keep 用于删除一些最后的 在当前分支中提交，同时保持工作中的更改 树。如果提交中的更改之间可能存在冲突，我们 想要删除以及我们想要保留的工作树中的更改， 不允许重置。这就是为什么如果两者都存在则不允许 工作树和 HEAD 之间以及 HEAD 和 目标。为了安全起见，当有 unmerged 时也是不允许的 条目。

我可以考虑有一些本地提交的场景：Commit0, Commit1, Commit2, ..., CommitX, CommitY, ..., CommitN

我想放弃 Commit1..CommitX 中的更改，但保留 CommitY..CommitN 中的更改

为此，我可以使用git reset --soft CommitX，然后使用git reset --keep Commit0

我猜如果没有 --keep，有人需要使用 stash 才能做到这一点。

Answer 3

我同意乍一看这些标志似乎是异国情调。我花了几个小时才理解它们，但区别非常明显：--keep 取消暂存索引，而 --merge 完全丢弃索引。

回到典型的用例：假设您有一个特定于本地环境的配置文件，例如，包含本地数据库的凭据。当您要进行“硬”重置时，请确保您不想丢失本地更改。那样的话

git reset --keep <commit>

完美地完成了这项工作。这表明您更频繁地希望使用--keep 标志而不是--hard 标志。

标志--merge 比--keep 更激进一点，因为它完全丢弃了索引（请注意，在这种情况下，与--keep 相反，您可能会丢失您的工作），但在我看来实际用例因为两者都是一样的。

最初，git reset --merge 用于中止合并，但现在git merge --abort 是首选（1.6.2 版本中引入了第一个选项，1.7.4 中引入了第二个选项）。

Answer 4

坦率地说，我对此不太确定；我自己从未使用过--merge 和--keep 模式。但是，发行说明表明 git reset --merge 是在 git 版本 1.6.2 中添加的，并带有以下说明：

• git reset --merge 是一种新模式，其工作方式类似于 git checkout 切换分支，同时进行本地更改 切换到另一个提交。

并且--keep 是在 1.7.1 中添加的：

• git reset 学习了 --keep 选项，可让您放弃提交 靠近尖端，同时以类似的方式保留您的本地更改 git checkout branch 是怎么做的。

然后，在 1.7.9 中：

• git checkout -B <current branch> <elsewhere> 更直观 git reset --keep <elsewhere> 的拼写方式。

这告诉我们--keep 背后的想法是，你已经开始在某个分支上工作，然后你意识到：哦，这个分支应该从另一个点（可能是另一个分支的尖端）分叉出来。例如，您可以：

$ git checkout devel
$ git checkout -b fix-bug-1234

然后做一些工作来修复下一个版本的错误 1234；但是后来有人说：“嘿，我们需要为旧版本修复错误 1234！”所以现在你希望fix-bug-1234 从release 分支而不是devel。同时你还没有提交任何东西。所以你：

$ git checkout -B fix-bug-1234 release

将其移至“即将发布”而不是“即将发布”。在 1.7.9 或更高版本中有效，但在 1.7.1 到 1.7.8 中，您必须拼写为 git reset --keep。

这或许可以解释--keep，但--merge 仍然有点神秘。