我正在努力将一些代码上传到qemu，后者希望补丁以小的可管理的块发送到邮件列表。因此，我的git存储库中有三个分支：
master，跟踪上游。feature，包含我的所有开发历史记录，包括尚未准备好进行上游的代码。这个定期与master合并，并在github上发布。upstreaming，修补程序提交的待处理队列，定期修改并针对母版进行修改（因此，我不会发布此版本，尽管每What's the Git approach to publish a patch queue?也许我可以通过适当的警告这样做。）每次我将补丁系列的一个版本提交到邮件列表时，我都会收到代码审核反馈，并在生成新版本的上游分支（使用git rebase --interactive和git commit --amend）之前解决该问题。补丁系列。这种方法运作得相当好。
但是，我还希望feature分支机构了解这些更改的最新信息。理想情况下，我想在feature上记录一次提交，这相当于补丁系列的最后一个respin中的所有更改，但是我还没有找到一种干净的方法来执行此操作。
如果我从upstreaming合并到feature，那么我每次都需要手动解决大量冲突，因为几乎（但不完全）相同内容的相同文件似乎是独立创造的;即3合并没有共同的祖先，也没有合并历史记录，因此新版本的每次后续合并似乎都在重新引入同一文件的略有不同的副本。
我认为我想做的是区分upstreaming分支的vN和vN + 1，然后将其作为单个补丁应用于功能分支。但是（缺少手动差异和补丁）我还没有找到任何git来处理这个问题。
答案 0 :(得分：1)
我使用了一个技巧，但它并不理想。重新定位upstreaming后，您可以git merge --strategy-ours ..更老的头。比它被记住为正向更新并且可以合并。
缺点是：
历史上看起来很难看。所有提交都在rebase之前和之后被提及，有时是混合的。
你应该小心只能前进。例如，如果你在某个主人的提交A1上upstreaming，那么你可以从主人A2（后者是A1的一个曾孙子）重新提交。然后可以合并我们的旧版upstreaming。但是当你将它重新绑定到其他分支B1或主A0中的某些早期提交时，你不能合并旧的upstreaming，否则它会考虑A1合并之前的某些历史记录，但实际上不会改变了。