所以我意识到你们中的许多人在阅读其中的一些内容时会感到畏缩......但是我的项目中有一个开发分支和一个prod分叉，主要是为了防止我的密码，appsettings等被我看到开发者。我最终将我的dev分支中的一些更改合并到我的prod分支中以推送已准备好的内容，并拒绝其他更改。这已经过了几次提交和合并。现在的问题是我已经准备好接受我之前拒绝的一些更改，尝试合并失败，我收到Already up to date消息。再一次，我意识到我不应该这样做，而是使用feature branches等，但现在已经太晚了，我如何强制git重新检查分支之间的差异并允许我将它们整合到我的产品分支中？
答案 0 :(得分：1)
你想要的不是合并 - 也许最好说，而不是git merge。 git merge做的是三向合并。三向合并有三个输入：合并基础和另外两个提交，通常是分支提示提交。
您在评论中写道：
当我做
git diff --stat dev..prod时，我可以看到两个分支之间的差异......
git diff做的是比较两个提交（而不是三个）。
让我们考虑一个文件的情况，它可以存在于两个提交中，第三个提交是合并基础。让我们绘制这个，作为一个小小的提交图片段：
...--B--X <-- main (HEAD)
\
Y <-- branch
假设有问题的文件是hello.txt。在提交B中，它显示为：
Hello!
I am a file.
Don't panic!
在提交X中，它显示为：
Hello!
I am a changed file.
Don't panic!
在提交Y中，它显示为：
Hello!
I am a file.
Don't panic!
But do remember where your towel is.
现在，如果我们想合并这两项更改，我们会注意到：
B中，第二行显示＆＃34;我是一个文件＆＃34;，但在两个提示中只有一个，它现在说＆＃34;我是已更改的文件。＆＃34; B中，只有三行，但在两个提示中只有一个中，有一条关于毛巾的新第四行。要制作合并后的结果，我们会更改第二行，然后添加新的第四行。
但是，如果我们将X中的文件与Y中的文件进行比较，我们会看到：
Hello!
-I am a changed file.
+I am a file.
Don't panic!
+But do remember where your towel is.
我们所知道的是第二行不同并且添加了第四行。
我希望将dev中的差异带入prod
这是一个问题，因为从字面上看，这只是意味着prod与dev＆＃34;完全相同。你可以在Git中轻松地做到这一点，但它可能不是你想要的。
进行这些更改的结果将是：
Hello!
I am a file.
Don't panic!
But do remember where your towel is.
也就是说，我们丢失对第2行的更改。有关详情，请参阅Why is a 3-way merge advantageous over a 2-way merge?
如果做想要在Git中进行双向交互式合并，即采取差异并以交互方式决定应用哪些部分以及忽略哪些部分，那么内置的内容就不多了.Git确实有git add -p：您可以从分支dev中提取文件，在其上使用git add -p，并以交互方式选择是应用大块还是跳过它。 （一旦您对结果感到满意，您可以git checkout-index <file>覆盖工作树版本，并将其交互式修补到索引中，只是为了查看它。）
否则，您将面临找到合适的文件合并基本版本的问题。如果您执行找到合并库，则可以使用git merge-file执行一次文件合并：
git show basecommit:path > path.base
git show dev:path > path.dev
git merge-file path path.base path.dev
git merge做什么自动使用提交历史记录查找合适的合并库，然后自动提取这些文件并运行git merge-file每一个。但是，如果您已完成合并，然后覆盖这些合并的结果，则记录在案的合并基础表示您已经决定（并记录以供将来参考） not not 进行这些更改。所以现在git merge不会接受它们。