【发布时间】：2016-10-25 19:02:24
【问题描述】：
我有一个相当复杂的元层补丁队列要执行，虽然我已经使用 Git 大约 2 年了，但我认为自己并不精通......
我有一个基础应用程序，我将其称为 App，它需要按顺序应用 2 个元层，它们都有自己的 Git 开发分支。
元层ML_A第一个应用，元层ML_B第二个应用，由于ML_A中的依赖关系，ML_B不能在ML_A之前应用。
元层 ML_A 有一个扩展补丁 A01.patch，而元层 ML_B 有一个长补丁队列，由 B01.patch 到 B90.patch 组成。
我从 Meta-layer ML_B 中删除了 B44.patch 和 B51.patch，提取了代码，并将其重新插入到 Meta-layer ML_A 的扩展 A01.patch 中。这很耗时，但足够简单，而且 ML_A 元层干净利落地应用于 App 并按其应有的方式运行。
但是！现在我必须对 Meta-layer ML_B 中成千上万行差异补丁代码进行 rebase，以反映更新后的 Meta-layer ML_A 对 App 的更改，因为 ML_B 和 ML_A 涉及许多相同的文件。我知道我可以在接下来的几周内单独应用 ML_B 补丁并在补丁不适用时更正补丁行号，但我听说有一些时髦的 Git 命令可以真正加快这个过程。
有人知道这里的最佳 Git 实践是什么吗？ Git 格式补丁？ Git rebase-patch？
【问题讨论】：
-
所以，你有这个：
A,B01,B02...B90，你想要这个：A'(which is A+B44+B50),B01',B02'...B43',B45'...B50',B52'..B90'。我做对了吗？ -
是的。那是对的。我在搜索中没有找到任何超级神奇的 Git 解决方案，但我找到了一个不错的工作流程。我可以编写一个脚本来帮助我正在做的事情，但我现在有点紧要关头，可能会在我的截止日期之后编写脚本以供将来使用。
-
伪工作流，从 App_Dev 分支开始：1) git apply A01.patch -v 2) git checkout -b App_after_A01, git add - A、git commit -m "
" 3) git apply .patch -v 4) 是不是完全干净的应用？ Yes: git checkout -b App_after_ , git add -A, git commit -m " ", 回到第三步 No: git reset - -hard，修复模糊和行号，git diff ~/ B .patch，返回步骤 3 -
如果你有一个补丁系列，它适用于某些提交而不会发生冲突，它总是最好先制作一次，然后再变基/樱桃挑选到另一个地方。 1）您不必关心提交消息。 2）在cherry-pick的情况下解决冲突更方便