git补丁管理工作流程：将更改从重新部署的补丁队列分支移植到合并的功能分支

Question

我正在将一些代码上传到qemu，qemu希望补丁以可管理的小块形式发送邮件列表。 因此，我的git信息库中有三个分支：

• master ，跟踪上游。
• feature ，具有我的所有开发历史，包括尚未准备好上游的代码。 定期将其与master合并，并发布在github上。
• upstreaming ，正在等待补丁提交的队列，该队列会定期修订并根据主服务器进行重新调整（因此，尽管按照Git的发布补丁队列方法 ，我不会发布此队列，也许我可以使用适当的警告）。

每次我向邮寄列表提交补丁程序系列的一个版本时，我都会得到代码审查反馈，并在生成新版本的补丁程序系列之前，在上游分支中解决此问题（使用git rebase --interactive和git commit --amend ）。 。 这工作得很好。

但是，我也想通过这些更改使feature分支保持最新。 理想情况下，我想记录一次feature上的提交，该提交等同于补丁程序系列的最后一次重新发布中的所有更改，但是我没有找到一种干净的方法来完成此操作。

如果我从upstreaming合并到feature ，那么每次都会有大量的冲突需要手动解决，因为似乎具有（几乎不完全）相同内容的相同文件似乎是独立创建的； 也就是说，三向合并没有共同的祖先，也没有合并历史记录，因此新修订的每次后续合并似乎都在重新引入同一文件的稍有不同的副本。

我认为我想做的是比较upstreaming分支的vN和vN + 1，然后将其作为单个补丁应用到功能分支。 但是（除了手动的diff-and-patch），我在git中还没有找到任何东西来处理这个问题。

Answer 1

我使用了一个技巧，但这并不理想。 重新排列upstreaming基准之后，您可以git merge --strategy-ours ..它的旧头。 它比被记住是向前更新的，可以合并。

缺点是：

1. 历史上看起来很丑。 在重新设置基准之前和之后都提到了所有提交，有时是混合的。

2. 您应该注意只重新设置基础。 例如，如果您在某个主控提交A1的upstreaming ，然后重新定位以稍后从主控A2提交，该主控是A1的子孙。 然后可以合并我们的较早的upstreaming 。 但是，当您将其重新设置为其他分支B1或主节点A0中的更早提交时，则不得合并较早的upstreaming ，否则它将考虑合并A1之前的某些历史记录，但实际上不会进行任何更改。