8

我有这种情况，我认为这并不罕见，但我正在努力寻找一个如何在网上正确完成的例子。

我们有我们的项目，有一个主分支。对于我的示例，假设 master 的当前状态标识了项目的 v1.5.0。

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

v1.5.0 需要在不稳定的特性和/或错误修复上添加一周左右的开发，没问题我们说新分支 - 编写特性 - 与 master 合并。主人现在是 v1.6.0。

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

我们在不稳定的分支上完成了 v2.0.0，它最初基于master分支的 v1.5.0，现在说... v1.8.4 - 你如何将不稳定的分支与 master 分支合并而不：破坏版本 1.5 到 1.8.4 的历史记录，或者将 2.0.0 之前的版本的人工制品留在合并的分支中，并可能破坏用 v2.0.0 编写的新代码？

4

2 回答 2

5

您可能已经知道git merge -s ours，它与您想要做的完全相反：它忽略源分支中的更改，并让合并结果与目标分支的内容完全相同。-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. 检查整个事情是否没有留下您以前的主版本作为未跟踪文件的残余。我不确定这是否真的会发生，但检查一下也无妨。
于 2013-07-19T09:37:24.330 回答
1

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

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

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

附带说明一下，一个非常有趣的项目处于测试阶段，但看起来可用：git-imerge。这个项目允许一个一个地合并提交，并解决更小的冲突。

于 2013-07-19T09:36:21.503 回答