从标签创建补丁分支并将其与主干合并答案

【问题标题】：Creating patch branch from tag and merge that with trunk从标签创建补丁分支并将其与主干合并
【发布时间】：2023-04-09 13:40:01
【问题描述】：

现在我们在分支机构开展工作。这些被合并到 trunk 中，并在其中的功能完成时被杀死。所以trunk总是包含最新的稳定代码。

当trunk 准备好发布时，一个tag 会从trunk 在给定点创建。现在，我们如何最好地处理需要为先前版本创建补丁的情况？

我们有一个标记该版本的标签。但是主干现在包含更多新功能。如果我们从旧的 tag 创建一个 branch，我们如何干净利落地将补丁修复程序放入我们的 trunk 并用新的标签？

我能否标记从初始发布标记创建的分支并重新整合合并 分支与我们的主干？或者这会带来问题吗？我觉得它可能会混淆 Subversion。

这张“图片”试图说明流程。

Work branches /-- itter. 1.0 --\      /- 2.0 -\           /------ 3.0 ----------\
             /                  \    /         \         /                   /   \
    ------------trunk----------------------------------------------------------------------  
                                  |                | v2.0 tag              /      | v3.0 tag  
                                  |                                       /
                                  | V1.0 tag----------\                  /
                                                       \-- Branch 1.1 --/
                                                                        |
                                                                        | V1.1 tag

请注意，尽管此处的标签和分支位于同一行，但它们实际上位于标准 主干、分支、标签文件夹布局中。

注意：工作分支不必与给定版本有任何关系。我只是将它们命名为 1.0 等。但它们可以命名为 foo、bar 或其他任何名称。

【问题讨论】：

标签： svn branching-and-merging

【解决方案1】：

更常见的方法是保持发布分支（1.x、2.x、...）打开并从那里标记特定版本。

仅当您停止支持该版本时才关闭分支。

        1.0     1.1         2.0     2.1         (release tags)
       /       /           /       /
   /----------- 1.x       /----------- 2.x      (release branches)
  /                      / 
----------------------------------------------- trunk

无论这个分支是从哪里分支出来的（主干、标签或其他分支），将修复从这样的发布分支合并到主干是安全的。

【讨论】：

我还要说，如果您进行定期合并，您可能会发现分布式版本控制系统（例如 git 或 mercurial）优于 Subversion。
如果名为 1.0、2.0 等的分支不包含发行版怎么办？如果它们是 sprint 分支，甚至是 sprint 分支中的特征分支，会怎样。这个想法是在分支中没有“逻辑”来决定什么是发布。这是由产品所有者决定的，并且在任何给定时间都会从主干发布。当时可能有 1、10 或 0 个正在进行的分支，它们还没有任何东西合并到主干中。这就是为什么我们在发布发布时在我们的主干上标记该点。唯一的问题是如何最好地返回并修补该类型的标记版本。
如果您必须并行管理应用程序的多个版本（2.1、3.0、...），您不能只依赖中继来发布。需要发布分支。
@inquam：功能分支在工作时就存在。当它们的功能准备好发布时，您将它们合并到主干并关闭它们。然后该状态被分支以释放。
但是由于很久以前在主干上进行了补丁工作，因此您无法将其合并到主干中，然后从中分支发布（即标签）。如果是这样，您将在作为路径的一部分修补的版本发布后进行所有更改并提交到主干。必须在更改合并回主干之前进行发布。如前所述，我们使用“稳定主干”模式。但是分支/标签可以命名任何东西，因为它与颠覆相同。

【解决方案2】：

我们现在一直在使用从主干标记发布的方法，如果有一段时间需要补丁，则从该标记创建一个分支，并且它在单个和多个团队中都可以正常工作。

【讨论】：