Question

让我们考虑一下这种情况：

---A---B---C---D---E---F---G---H---I---J---  (master from upstream)
       \                    \
        D'--F'               J'              (releases from upstream)
             \
              P---Q                          (own branch)

我们希望将所有自己的分支合并或修补到J＆＃39;。

当P --- Q将成为主分支的直接后代时，我不会遇到太多麻烦。但是，在这个用例中，我得到了许多与我自己的分支中未触及的文件相关的合并冲突。这些冲突起源于D＆＃39; --- F＆＃39;在这个例子中。所以我从F＆＃39; --- Q中生成了一个差异，并尝试将其应用于J＆＃39;。结果：许多应用错误。另一种方法，git-format-patch F＆＃39; --- Q然后git am -3 -k也不能证明是一种有效的解决方案。实际上，这与合并解决方案相当。我也尝试过rebase。再说一遍：我没有触及的许多文件出现在变基过程中。

有任何干净的解决方案吗？

Answer 1

我开始意识到由git format-patch生成的提交数量远远超过了严格要求。处理这个并格式化一个较小的提交范围导致了更好的处理git am迭代。为了解释发生了什么，我扩展了图表：

---A---B---C---D---E---F---G---H---I---J---  (master from upstream)
    \   \                    \
     \   D'--F'               J'              (releases from upstream)
      \       \
       M---N---P---Q                          (own branch)

M - N是以前的提交，基于主人。 P是合并提交，所以

git format-patch F'..Q

导致补丁系列在历史上更深（我的情况：大约60），并且非常奇怪的git am迭代。当使用格式补丁P --- Q时，我得到约。 30次提交（事实上，P --- Q是一种简化）。现在git am迭代导致git mergetool步骤与P之后的提交有明确的关系，并且是可管理的。

如何将功能分支应用/合并到更新的发布分支？

1 个答案: