0

我正在帮助将一个长期运行的项目集成回主线。想要回归的功能分支之一本身就是许多其他“迷你功能”分支的章鱼合并（不是单个章鱼合并，而是随着时间的推移进行的多次合并）。

这些迷你功能分支中的每一个都散布在其独特的内容中，一组共同的提交被精心挑选到每个相应的迷你功能分支中。我想在合并回主线之前清理所有这些常见的提交。

可能相关的是功能分支的当前状态是“正确的”，即代码的外观是它应该看起来的样子。

我尝试过的选项：

  1. 直截了当rebase -i：导致了很多冲突，可能是因为樱桃挑选已应用于多个迷你功能分支并已解决
  2. rebase -i -p：这导致完全相同的分支结构与重复的常见提交

在正常情况下，我会简单地挥动投降的白旗并进行壁球合并。但是，我需要做的是用一组新的和改进的常见提交替换这些常见提交——这表明 rebase 是最合适的继续方式。

理想的做法是使用rebase -i冲突解决策略，尝试通过选择使结果看起来最像最终目标（当前章鱼特征分支）的冲突选项来解决冲突。但我不知道如何告诉 git 这样做。

我的问题：

  1. 有什么方法可以告诉 git 以上述方式解决冲突吗？
  2. 有没有更好、更清洁的方法来实现我的目标？
  3. 我是否愿意使用 rebase 手动重建这些迷你功能分支？
4

1 回答 1

0

我假设你对合并有很多了解（在寻找——或者在某些情况下，创建——一个共同的合并基础，根据合并基础区分端点，以及组合差异）并直接跳到这些答案：

  1. 不。在某些情况下，有一个简单的答案：只使用最终版本。但这仅在最终版本是正确版本时才有效。您提供的有点模糊的文本描述向我表明，您希望在这一点上选择一个中间结果，该结果将在未来与其合并基础和分支提示的任何合并时，呈现最少数量的冲突。

    这（显然）是一个难题，甚至可能是 NP-hard 或 NP-complete（通过大力挥手证明:-)）。内部节点的自由度太多。

  2. 也许。要找出答案，请绘制您现在拥有的图表类型，以及您最终希望拥有的图表类型。（也就是说，绘制提交结构，包括其分支和合并，以及每个提交集合的近似值。）用大致内容标记提交并使用它来设想合并步骤。根据您想要保留的内容和您愿意丢弃的内容重新排列中间结构，以获得您重视的任何内容。

  3. 与其使用 rebase（复制提交然后移动分支标签），不如考虑使用git cherry-pick（复制提交 - 没有分支标签运动，除了当前分支以通常的方式推进）来构建新结构。这样，您只需在现有结构旁边添加结构。您可以构建它们直到它们完成（随时添加合并git merge），然后当一切都完成时，然后您声明您的“标志日”并让每个人都从旧提交切换（由现有的分支名称命名） ) 到新提交（拥有旧提交的每个人都必须获取新提交并将其分支名称移动到新提交）。

于 2017-09-25T21:27:47.687 回答