0

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

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

我们希望将我们自己的所有分支合并或修补到 J' 上。

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

有什么干净的解决方案可用吗？

4

1 回答 1

0

我开始意识到，由 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 是以前的提交，基于 master。P 是一个合并的提交，所以

git format-patch F'..Q

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

于 2012-10-09T08:06:09.287 回答