我有这种情况，我认为这种情况并不罕见，但我正在努力寻找如何在网上正确完成的示例。
我们有我们的项目，有一个 master 分支。对于我的示例，假设主控的当前状态标识项目的 v1.5.0。
现在我们决定编写 v2.0.0，将对其进行大量更改和重写，文件将被完全移除和删除。这种重写现在发生在我们称之为不稳定的新分支上。
在 v1.5.0 中需要添加不稳定的功能和/或错误修复需要一周左右的时间，没问题我们说新分支 - 编写功能 - 与主分支 merge 。大师现在是v1.6.0。
现在，此修复/功能不适用于项目的新版本，因为整个项目正在重写。
我们在 unstable 分支上完成了 v2.0.0，该分支最初基于 master 分支的 v1.5.0，现在说... v1.8.4 -在不破坏 1.5 到 1.8.4 版本的历史记录或在 merge 分支中留下 2.0.0 之前版本的人工制品并可能破坏 v2.0.0 中编写的新代码的情况下，您将如何将不稳定分支与主分支 merge ？
最佳答案
您可能已经知道 git merge -s ours，它做的与您想要做的完全相反:它忽略 source 分支中的更改并让 merge 结果与 target 分支的内容完全相同。但是，没有相应的 -s theirs，原因我不打算在这里讨论。
因此，我们必须即兴创作具有相同效果的东西。粗略的概述:在不提交的情况下进行 merge ，神奇地将 2.0.0 代码混入其中，然后完成 merge 。
首先，确保没有未提交的更改。我们将在这里使用有趣的技巧；保修无效等等。
- 在 master 上，
git merge -n unstable。-n将确保 merge 尚未提交，即使没有冲突(当然，由于大量重写，您会遇到冲突，但请注意安全)。 - 这就是魔法:
git read-tree --reset -u unstable(将unstable读入索引并相应地更新工作树，忽略任何冲突) git commit完成 merge 。它现在在其历史 中既有旧的也有新的，但树 中只有 2.0.0 的东西。- 检查整个过程是否没有留下您以前的主版本的未跟踪文件。我不确定这是否真的会发生，但检查一下也无妨。
关于GIT - 在单独的分支上重写核心代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17742458/