生成了一部分项目代码，但必须对其进行跟踪，因为重新生成这部分需要大量资源(主要是时间(。
在主分支上，当这部分代码发生更改时，将执行提交，只是为了隔离这些更改。
在主题分支上，可以重新生成相同部分的代码。
然而，在合并主题分支时，这部分代码不得因主题分支中的更改而更改，主分支上的文件必须保持不变。
我尝试使用 .gitattribute 来设置 merge=ours 策略，但这仅适用于文档中所述的冲突。
应在没有手动干预的情况下应用合并约束。 因为它很容易忘记。
Git 没有提供自动执行此操作的方法。
您可以编写自己的代码来执行此操作。 特别要注意的是，如果您运行：
git merge -s qt-x somebranch
你的 Git 将调用它在你的$PATH上找到的任何命令
git-merge-qt-x
这个程序，你必须编写，必须做与git-merge-recursive、git-merge-octopus、git-merge-ours、git-merge-subtree和git-merge-resolve相同的事情。但是，您可以检查 Git 的源代码，包括git-merge-resolve和git-merge-octopus的源代码。 这些将使您了解如何开始。
使用其中任何一个作为模板的问题在于，它们依赖于git read-tree来完成大部分工作，并且导致问题的原因git read-tree：如果只有一个合并库，并且读取树看到文件F从基到提示#1 没有变化，但从基底更改为提示#2， read-tree 只是从 tip#2 中获取F，即使您不希望它这样做。 最好的办法可能是无论如何调用git read-tree，然后更正特定文件的结果。
(除非你编写了相当多的代码，否则你也会失去执行递归合并的能力，但在阅读这两个脚本后，应该很容易检测调用递归合并的情况。
考虑也围绕git merge --no-commit编写脚本，如加密西瓜的答案。
不久前我不得不做类似的事情。合并分支而不提交合并并还原单个文件。这很乏味，但如果您保存了文件列表，那么将来的合并也不错。
git merge branch_foo --no-commit
git checkout HEAD file1 file2 file3
git add -u
git merge --continue
编辑：根据@knittl输入更改git add行