您希望将该更改合并为实际未合并，但将其标记为历史记录。这样您就可以知道从何处获得后续更改。
有几种方法可以做到这一点。一个是
git checkout master
git merge -s ours --no-ff testing
git checkout testing
git merge -s ours --no-ff master
或
git checkout master
git merge testing --no-commit --no-ff
git checkout HEAD -- .
git submodule update # this is optional and only needed if you have submodules
git add -A
git commit
git checkout testing
git merge master --no-commit --no-ff
git checkout HEAD -- .
git submodule update # this is optional and only needed if you have submodules
git add -A
git commmit
现在您有 2 个具有不同配置的分支，但这些提交在重要的 merge-base 之前。
现在您需要编写类似这样的脚本来执行特殊合并，这实际上是底层的变基——这是忽略之前发生的事情的唯一方法：
git checkout master
git merge --no-ff -s ours testing
git checkout -b temp testing
git rebase -s recursive -Xtheirs master # these are the conflicts we care about
git reset --soft HEAD@{2}
git add -A
git submodule update
git commit --amend -C HEAD@{2}
git push . +HEAD:master
git checkout master
git branch -d temp
这只是在分支测试中重新设置您在 master 上没有的东西，并使其看起来像一个合并。因为它将它存储为一个合并，所以您可以随后针对您想要发布到 master 的其他分支运行它。所以你可以用&&s 分隔所有这些命令，用一个参数替换测试，用第二个参数变量主控并将它的别名：
git config alias.smart-merge '...'
这样您就可以像这样发布更改：
git smart-merge testing master
git smart-merge feature2 master
这应该给你测试和特性2，不管这两个可能已经在历史中合并了。
还可以考虑启用 rerere，因为脚本不会发生冲突。因此，如果您确实想发布，您可以先进行常规变基，记录冲突解决方案。现在，您可以更改脚本以利用这些优势，而不会因冲突而中断。
Rebase 冲突解决可能会很痛苦。但不是在这种情况下，因为我们只使用 master 来发布。其他分支操作仍然通过常规合并或变基来完成。
-- 或者--
重要的是涂抹干净的脚本。查看 progit.org/book 中的 git 属性章节。
希望这会有所帮助。