GIT - 在单独的分支上重写核心代码

Question

我有这种情况，我认为这种情况并不常见，但我很难找到一个如何在网上正确完成的例子。

我们有我们的项目，有一个主分支。对于我的示例，我们可以说主服务器的当前状态标识项目的v1.5.0。

现在我们决定编写v2.0.0，将发生大规模的更改和重写，文件将被完全删除和删除。这个重写现在发生在我们称之为不稳定的新分支上。

需要在v1.5.0中添加不稳定的功能和/或错误修复一周左右的开发，没问题我们说新的分支 - 写入功能 - 与主服务器合并。主人现在是v1.6.0。

现在，当整个项目被重写时，此修复/功能不适用于新版本的项目。

我们在不稳定分支上完成v2.0.0，该分支最初基于主分支的v1.5.0，现在位于... v1.8.4 - 如何在没有的情况下将不稳定分支与主分支合并：破坏版本1.5到1.8.4的历史记录，或者在合并分支中保留2.0.0之前版本的伪像，并可能破坏在v2.0.0中编写的新代码？

Answer 1

您可能已经知道git merge -s ours，它与您想要做的完全相反：它忽略了 source 分支中的更改，并让合并结果与目标分支的内容。但是，没有相应的-s theirs，因为我不打算进入这里。

所以，我们必须即兴创作具有相同效果的东西。粗略轮廓：在没有提交的情况下进行合并，将2.0.0代码神奇地破坏到其中，然后完成合并。

首先，请确保您没有未提交的更改。我们将在这里使用有趣的技巧;保修无效以及所有这些。

1. 在主人身上，git merge -n unstable。 -n将确保合并尚未提交，即使没有冲突（当然，由于您的大量重写，您会遇到冲突，但让我们保持安全）。
2. 这是神奇的：git read-tree --reset -u unstable（将unstable读入索引并相应地更新工作树，忽略任何冲突）
3. git commit完成合并。现在它的历史中既有旧的又有新的，但树中只有2.0.0的东西。
4. 检查这整件事情是否保留了以前主版本的遗留物作为未跟踪文件。我不确定这是否真的会发生，但检查不会有什么坏处。

Answer 2

关于如何处理大量分支的分支。这里有几个选项：

• 合并：不太理想，因为你会遇到很多冲突，如果核心发生了变化，就很难解决并确保一切正常。
• handcraft：检查自master分散后unstable所做的更改，并重新编码。当你意识到分支之间的差异太大，并且合并没有任何意义时就是这种情况。但是你仍然可以挑选仍然适用的提交。您最好有一个单独的问题跟踪器，列出自分支分离后master上应用的内容。

请注意，rebase不是一个选项，因为master分支已经发布。

另一方面，一个非常有趣的项目处于测试阶段，但看起来很有用：git-imerge。该项目允许逐个合并提交，并解决更小的冲突。