有没有办法可以故意导致与我的存储中的文件发生合并冲突？

Question

我的存储库中有一个 SCSS 文件，还有几个存储库。我们称之为

target.scss

。它是其中唯一的文件，包含少量修改过的选择器。

我已经修改了

target.scss

。

我想要做的是git merge stash@{2}

（它的位置），并让 git 像任何其他合并一样对待它。也就是说，我

想要 Git 报告冲突，这样我就可以解决冲突然后git add

，提交并推送。

我知道还有其他方法可以做到这一点。是的，我可以承诺并申请。是的，我可以启动一个新分支，应用并重新设置基准。甚至合并。但我希望避免在执行合并之前进行提交。

是否存在一种模式，我可以在其中触发从我的存储到我目前脏的 HEAD 的合并，处理合并冲突，然后提交，就像我只是手动合并它们一样？

我可以用

git diff stash@{2} target.scss diff

 文件，但我无法弄清楚如何将 git 置于“合并冲突”模式来解决相同问题。我应该看 

diff

 而不是 

merge

 吗？

Answer 1

好吧，所以我正在回答这个问题，但所有功劳都归功于@jonrsharpe，他向我指出了来自

muhqu的这篇文章，它非常接近为我提供了答案；我只需要稍微调整一下。

另一个答案建议：

git stash show -p | git apply -3 && git stash drop 这接近我想要的，尽管它会：

合并错误的储藏室，
同样应用失败，然后
删除较新的存储（我一开始就不想涉及），并且
它不会引发合并冲突。它的行为就好像我告诉它在文件范围内“接受两者”。

但是，它完全为我指明了正确的方向！要解决这些问题：

让我们更改目标存储：

git stash show -p stash@{2} # This will select the stash 2 nodes back, 
                            # and create a patch from it.

因为它是一个较旧的存储库，所以我需要降低补丁申请意愿的严格程度。这可以通过将
2. -C1

    标志修改为 

   git apply

    语句来完成。所以：

git apply -3 -C1 这本质上是告诉 Git，“只要该文件中的任何行匹配，就假定它是一个有效的应用程序。尝试使用 3 路合并进行合并。否则，回退到普通合并。”

3. 我不想删除相关的藏品，所以我会省略

   && git stash drop

4. 在这种特殊情况下，我确实想接受双方的一切，所以没有伤害也没有犯规。但我对传统冲突的实际引发的探索仍在继续。

我会留下这个问题，以防有人知道如何管理最后一点。