请考虑以下情况:

  • 开发主要在主干中完成。
  • 在修复复杂的错误或开发新的(最初不稳定)功能时使用分支。
    通常,一旦完成开发,然后将这些分支合并到主干中。
  • 1分支用作当前发行版分支(例如,当前为“R-1.0”)。
  • 标签用于发布(将为“R-1.0.0”)。

  • 现在,必须修复主干以及当前版本1.0.0中的一个复杂错误:
  • 将创建主干的分支“BG-1”。
  • 该错误将在此分支中修复。
    同时,发展将继续进行。

  • 您现在如何继续将分支重新集成到中继和“R-1.0”中?
  • 将中继合并到“BG1”,然后将“BG1”重新集成到中继,然后再集成到“R-1.0”。
    =>这不是解决方案,因为“R-1.0”将接收自发行版1.0开始以来在行李箱中开发的所有内容,这不是目标。
  • 尝试将“BG1”重新集成到中继中,然后再集成到“R-1.0”中,而不合并中继。
    =>这也不起作用,因为不属于1.0版的其他更改已属于“BG1”分支。

  • 有什么解决办法吗?
    我看到的唯一解决方案是从“R-1.0”启动“BG1”,而不是首先使用中继。如果是这样,这是否意味着对于每个bug修复分支,开发人员都必须找到支持的最旧版本,其中包含该bug分支中的bug和分支?

    更新:
    在主干中进行所有开发的实践源自this answer by "Jim T",这是我非常喜欢的概念。

    最佳答案

    我建议将中继合并到BG1,然后将BG1重新集成到中继。然后,您可以将一系列修订合并到R-1.0。将BG1重新集成到主干的提交中应仅包含错误修正,因此可以将其合并到R-1.0。或者,您可以将特定的提交合并到BG1中,以修复您的错误。

    根据自R-1.0以来干线已更改的数量,您可能必须先手工编辑R-1.0,然后再 promise 将更改应用于旧代码。这就是保持旧版本的本质。

    08-26 13:39
    查看更多