当一个人拥有另一个不想要的还原时,合并git分支

Question

我们正在开发两个版本,一个是次要版本,另一个是主要版本,每个版本都有自己的git分支.在创建主分支之前,最初将一个功能添加到次要分支.后来该功能已从次要分支中移除(带有revert提交),因为我们决定在主要版本中引入该功能.

所以现在我们有这样一种情况:如果我们将来自次要分支的更改合并到主分支中,它将包括恢复提交,这在主要分支中没有意义.

我考虑过的一个选项是cherry-pick在恢复提交后使用次要分支中的提交,但这样做的缺点是任何基于次分支的分支都不能与主分支合并.(我们必须继续使用cherry-pick类似的东西.)但它具有更准确的历史记录的优势,因为不会包含恢复提交.

另一种选择是将所有次要分支合并到主分支中,只是"忽略"恢复变更.通过"忽略",我的意思是在进行合并时手动恢复还原的更改.从git的角度来看,这可以更好地保留历史,但可能意味着在合并期间会有一些纠缠.

一般来说,我们只在主分支中使用合并,而只是在合并之前调整修复最新代码.所以我的偏好是选择第二种选择,但我想在这里找出这是否是处理这种情况的正确方法,或者是否有我遗漏的东西.

编辑:这是ASCII艺术:-)

*   (major)
| * (minor)
* | ...
| * revert feature on minor
* | major: unrelated commit
| * minor: unrelated commit
* |
|/
*   common ancestor
|
*   add feature to main branch

Answer 1

我很好奇你的意思,"在主要分支中没有意义." 您是否担心该功能将在主要分支上恢复？或者你是否感到恼火的是,一个名为"恢复功能"的提交将出现在主要分支的历史中,而事实上该功能在那里？

如果没有更多细节,很难说合并的结果是什么,但这里有一些可能性:

如果您的历史记录如下所示:

*   (major)
| * (minor)
* |
| * revert feature on minor
* | cherry-pick feature onto major
| * add feature to minor
* |
|/
*   common ancestor
|

然后你可以简单地合并minor到major没有任何问题.

为什么？想想这样说:当你合并minor到major,你实际上走的是共同的祖先(之间的差异git merge-base major minor)和minor,把它当成一个补丁上major,然后创建一个承诺,恰好拥有二者major和minor家长.

共同祖先之间的差异minor并不包含任何添加然后恢复的功能的提示,因为两个提交相互抵消.因此,引入的唯一变化是major由其他提交引起的变化minor.

如果您的历史记录如下:

*   (major)
| * (minor)
* |
| * revert feature on minor
* | merge minor into major
|\|
* | cherry-pick feature onto major
| * add feature to minor
* |
|/
*
|

那你有问题.在这种情况下,major和之间的共同祖先minor是标记为" add feature to minor" 的提交.如果你看一下这个共同祖先之间的差异minor,差异将包括特征的恢复.当您合并minor到major,这种差异将被应用到major,恢复该功能major.

在这种情况下,有几种简单的方法可以避免丢失该功能major:

• 合并minor到major,然后恢复的复归.生成的图形如下所示:

  *   revert the revert (major)
  |
  *   merge minor into major
  |\
  * |
  | * (minor)
  * |
  | * revert feature on minor
  * | merge minor into major
  |\|
  * | cherry-pick feature onto major
  | * add feature to minor
  * |
  |/
  *
  |
  

• 创建一个新的分支minor.我们称之为minor-for-merge.在此分支上,还原还原.然后合并分支major并删除分支.生成的图形如下所示:

  *     merge minor-for-merge into major (major)
  |\
  | *   revert the revert
  *  \
  |   * (minor)
  *   |
  |   * revert feature on minor
  *   | merge minor into major
  |\_ |
  *  \| cherry-pick feature onto major
  |   * add feature to minor
  * _/
  |/
  *
  |
  

无论哪种方式都有效.后者有点尴尬 - 恢复恢复的提交在无人区域中有点悬空 - 但它可以帮助你在合并时避免许多合并冲突major.

无论你走到哪里,任何分支minor都可以合并到major不恢复功能.如果minor在恢复之前进行了分支,那么恢复将不会在合并的历史中.如果分支关闭minor是在恢复之后(或者如果minor在恢复之后合并到分支中),那么恢复仍然不会在合并的历史中,因为该提交已经在major祖先.