我有这种情况,我不认为这种情况并不常见,但我正在努力寻找一个如何在网上正确完成的例子.
我们有我们的项目,有一个主分支.对于我的例子,我们可以说master的当前状态标识了项目的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中编写的新代码？
您可能已经知道git merge -s ours,这不正是你想要做什么相反:它忽略了的变化源分支,让合并的结果是完全相同的内容目标分支.-s theirs但是,没有相应的原因,我不打算进入这里.
所以,我们必须即兴创作具有相同效果的东西.粗略的轮廓:在没有提交的情况下进行合并,将2.0.0代码神奇地破坏到其中,然后完成合并.
首先,请确保您没有未提交的更改.我们将在这里使用有趣的技巧; 保修无效以及所有这些.
git merge -n unstable.这-n将确保合并尚未提交,即使没有冲突(当然,由于您的大量重写,您将会遇到冲突,但让我们保持安全).git read-tree --reset -u unstable读unstable入索引并相应地更新工作树,忽略任何冲突)git commit完成合并.它现在将有历史新旧两种,但树中只有2.0.0的东西.| 归档时间： |
|
| 查看次数： |
779 次 |
| 最近记录： |