不经过暂存合并Git中的更改

Question

我想合并一个分支，而不将自动合并的文件暂存以便提交。 我预计合并会很混乱，我想使用git diff检查所有更改后再提交。 --no-commit选项可以防止提交完成，但是文件仍然暂存。 是否有一种方法可以在合并时不暂存文件以便提交？

- Laizer

---

为什么它们是暂存的还是没有暂存的很重要呢？它们仍然会出现在 git diff 中。您可以执行 git reset 将它们取消暂存。 - EncryptedWatermelon

我从未见过暂存文件出现在差异中。 - Laizer

嗯，好的。git diff HEAD 会显示已暂存和未暂存的更改。git reset 将取消所有暂存的更改。 - EncryptedWatermelon

@EncryptedWatermelon - git reset 似乎也会清除“合并进行中”的标志。实际上我正在寻找类似的东西... 我想开始一个合并（即准备好两个父级，但工作树中没有实际更改）。 - David V. Corbin

Answer 1

如果只是要审查修改内容，您可以使用git diff --cached来查看暂存区的变化。这种方法适用于您的情况吗？

- unixia

---

如果你想要针对你的问题得到技术性的回答，请参考torek的答案；但是，当涉及到解决你所述问题时，这是最简单、最合理的解决方案。 - Mark Adelsberger

如果合并很小，那么这个回答是公平的；但在其他工作场所，政策更倾向于大规模合并；所以我希望能够在合并之前逐个勾选每个文件（明确地使用 git add 命令，然后再执行合并的 git commit）。 - undefined

Answer 2

不可以。

技术原因是，Git的合并实际上发生在索引（index）中，该索引会被临时扩展以容纳所有三个输入提交。每当成功合并一个文件（没有冲突），Git就会将该特定的索引条目缩小回一个单独的零号槽位，这样就为提交做好了准备。对于有冲突的文件，Git将该索引条目保留为三个占用的编号为1（合并基础）、2（--ours或HEAD提交版本）和3（--theirs）的槽位。

在合并过程中，工作树文件大多只是虚拟的/临时的，除了Git更新它们来进行合并尝试之外，并没有太多实际作用。所有真正的操作都发生在索引中。如果一切顺利，所有工作树文件都将被更新为与最终的零号槽位副本匹配的版本，即看起来像是Git已经将它们暂存了。但事实上是相反的：正确的版本已进入索引中的零号槽位，然后Git执行了类似git checkout-index的操作，将索引文件复制到工作树中。

如EncryptedWatermelon在评论中所说，在这里可以使用git reset：

git reset HEAD -- <filename>

使用一个git reset --mixed HEAD命令，可以告诉Git将HEAD提交的文件副本复制到索引的文件副本。这个命令也可以简写为git reset，它会对每个文件执行上述操作。¹但是，通过这种方式使用git reset并没有直接或立即的价值，因为如果你想查看文件的更新索引副本，可以使用git diff --cached比较HEAD和索引。但如果你想要取消暂存的文件，然后重新暂存其中一些文件，那么这个命令也是可用的。

---

¹--mixed形式的git reset命令还会指示Git更新当前分支名称，使其存储的哈希值等于其当前存储的哈希值。如果使用git reset --mixed hash，则会从指定的哈希值重置索引，并将指定的哈希值写入当前分支名称。使用HEAD时，我们强制将分支名称的“更改”设置为“将其设置为当前值”，即根本不移动它。这意味着唯一可见的效果就是覆盖索引内容。

- torek

Answer 3

你可以使用reset命令将在git merge <branch name> --no-commit之后被暂存的所有文件移回未暂存的更改中。 git reset HEAD -- .

- Alan Smith