存储时丢失合并状态答案

【问题标题】：Merge status lost when stashing存储时丢失合并状态
【发布时间】：2014-08-29 12:40:20
【问题描述】：

在我们进行存储后，有关合并的信息会丢失。下面比较了通常的合并和隐藏的合并。

右：合并+推送

git merge release-2013-10-29
# Everything works, cool
git commit -am "Upgraded to release 2013-10-29"
git push origin dev

结果如预期，一次合并提交：

错误：合并 + 存储 + 推送

在这里，我需要隐藏合并更改，以便查看合并前的行为。

git merge release-2013-11-06
# Conflicts fixed, but detected inappropriate behaviour
git stash
git stash pop
git commit -am "Upgraded to release 2013-11-06"
git push origin dev

结果：此提交不再是“合并”。我们还丢失了合并中包含的所有单一创作的提交，就像我会进行所有这些更改一样。

那么，我们不应该在合并时存储任何东西吗？那么如何避免这种行为呢？

【问题讨论】：

不要使用stash。没有什么stash push/pop 可以做到git commit -a -m stash-commit 和git checkout branch-with-stash-commit && git reset HEAD^ 已经完美地做到了（没有任何像你描述的stash 那样的不良行为）。我真的认为没有理由再使用git stash，我认为这是对早期 git 开发的一种解脱。
我不确定你的观点。一旦我修复了合并中的很多冲突，我需要恢复到合并前的状态“只是为了检查一些东西”。 commit、checkout 或 reset 之间的任何一个都不会暂时保存我花了很长时间修复的冲突。只有stash 会。或者你是想说我应该在没有验证以前的行为甚至一些“错误”代码/合并的情况下提交我的文件？更具体地说，从来没有人应该藏匿任何东西？

标签： git merge

【解决方案1】：

当您进行合并时，git stores a reference to the branch you're merging in MERGE_HEAD。但似乎git stash 没有保存引用。

您可以尝试将MERGE_HEAD 设置回您在应用存储后合并的提交：

假设您将 release-2013-11-06 分支合并到 master 上，并且最后一次提交是 -3be2c99，那么您可以这样做：

git stash apply --index
git update-ref MERGE_HEAD 3be2c99
git status
# All conflicts fixed but you're still merging
# ....

在应用存储时注意--index 的用法。这是在索引中恢复更改所必需的，否则您将仅在工作树中获得隐藏的更改。

P.S：理想情况下，您应该避免隐藏未提交的合并。

【讨论】：

我要强调--index 和git stash pop 的用法：没有它，更改将不会应用于索引，只会应用于工作树，并且“冲突已解决”状态意味着有冲突的文件的“可以提交”状态在索引中。
@kostix 是的，添加了关于它的注释:)
@StéphaneBruckert 我的回答有一个小的更正，请重新查看。实际上 MERGE_HEAD 应该指向您要合并的分支中的提交，即 release-2013-11-06 在您的情况下。