考虑以下情况：
- 开发主要在trunk中完成。
- 修复复杂的错误或开发新的（一开始不稳定）功能时使用分支。
通常，一旦开发完成，这些分支就会合并到主干中。
- 1 分支用作当前版本分支（当前为“R-1.0”）。
- 标签用于发布（将是“R-1.0.0”）。
现在必须修复 trunk 以及当前版本 1.0.0 中的一个复杂错误：
- 将创建来自主干的分支“BG-1”。
- 该错误将在此分支中修复。
与此同时，主干的开发将继续进行。
现在如何将分支重新集成到主干和“R-1.0”中？
- 将 trunk 合并到“BG1”，然后将“BG1”重新集成到 trunk，然后集成到“R-1.0”。
=>这不可能是解决方案，因为这样“R-1.0”将接收自 1.0 版本以来在主干中开发的所有内容，这不是目标。
- 尝试将“BG1”重新集成到主干中，然后重新集成到“R-1.0”中，而不合并主干。
=>这也无法工作，因为不属于版本 1.0 的其他更改已经是“BG1”分支的一部分。
这个问题有什么解决办法吗？
我看到的唯一解决方案是首先从“R-1.0”而不是主干启动“BG1”。如果是这样，这是否意味着对于每个错误修复分支，开发人员必须找到包含此发布分支中的错误和分支的最旧的受支持版本？
Update:
在主干中进行所有开发的做法源于“Jim T”的回答 https://stackoverflow.com/questions/570071/subversion-branch-trunk-best-practice-keeping-branch-up-to-date/570598#570598这是我非常喜欢的一个概念。
我建议将主干合并到 BG1，然后将 BG1 重新集成到主干。然后，您可以将一系列修订合并到 R-1.0。将 BG1 重新集成到主干的提交应该只包含错误修复，因此您可以将其合并到 R-1.0。或者您可以将修复 bug 的特定提交合并到 BG1。
根据自 R-1.0 以来主干的更改程度，您可能必须在提交之前手动编辑 R-1.0，以使更改应用于旧代码。这就是维护旧版本的本质。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
