在我工作的公司中，我们每 x 时间（通常是三个月）发布一次。在此期间，我们进行了四六次“可发布分支”冲刺，我们所有的代码都进入了该分支。
一段时间后，该分支作为版本 xxx 发布，我们继续进行下一个版本。但由于通常的承诺，我们必须在数月/数年内维护旧版本。
我想知道版本到发布的分支是否正确。因此，我们的发布版本分支永远不会完全重新集成到主干中。他们永远活着。为了维护它们，当在分支中发现错误时，我们在主干中修复它并手动将其移植到分支（我更喜欢这个），或者我们在分支中工作并移植它（类似于主干中的提交分支，没有重新整合）回到主干。请注意，肯定会发生主干包含不会/不能合并到分支中的代码，这可能是因为该分支太旧而无法支持巨大的变化。
您知道我们使用的方法的优缺点吗？你有另一种方法来处理可维护的版本吗？也许在 svn 之外？
【问题讨论】：
标签： svn merge branch svn-trunk
我想知道版本到发布的分支是否正确。
好吧，至少这不是完全错误的 - 你一直有可管理的代码。未完全重新集成的分支是您的内部游戏，您可以在不破坏主要任务的情况下玩它 - 适时发布产品并修复旧问题。不同的代码行是你的成本
从 PM POV 中，您的“混合”工作流程（2 个源、合并集和分支中的普通线性历史记录）更难从日志转换为最终“完成列表”以供发布，我更喜欢“分支”的广告和活动-per-task" 工作流（在任何 SCM 中） - 这样分支（开发，大多数）是短暂的、可集成的工作部分，主线和版本分支将只获得更易于观察的合并集。但这只是个人喜好和口味
【讨论】：
基本上有两种不同的“主干策略”：稳定主干，主干应该始终具有可发布的质量，所有开发都在重新集成的分支中进行，不稳定主干，其中主动开发发生在主干中，并在发布前进行分支以稳定。
无论使用哪种主干策略，发布的版本都应该始终是未重新集成的分支。
一个遵循unstable trunk政策的例子（在trunk中积极开发，需要在发布前分支稳定）：
1.0 的后备箱开发进展顺利。在某个时候，为 1.X 创建了一个分支并且代码稳定了。一旦代码被认为是稳定的，它就会被标记为 1.0 并发布。同时，版本 2 的主干中的工作也在进行中，不久将在 2.X 分支中进行分支，依此类推。
在 1.0 版中发现的错误可以在 1.X 分支中修复，而 1.1 版可以通过该错误修复从该分支中发布。如果 bug 在主干中相关，则可以合并。但是该功能可能会在主干中删除或重建，从而使此错误修复与主干的合并毫无意义或不可能。如果 bug 是版本 2 的 beta 测试人员在 trunk 中发现的，那么您可以在那里修复它，然后查看旧的维护分支（例如 1.X）是否有 bug，然后将 bugfix 合并到那里。它是双向的。
我看不出有什么比为每个版本分支更好的策略（在我的示例中，每个主要版本的分支，而不是每个版本），我没有看到版本/发布分支应该的情况重新整合到后备箱中。
【讨论】：
我想我会一直在主干中保留最新的稳定代码，当前的开发版本将在分支中（分支中会有很多版本，因为不同的人会针对不同的需求工作）。之后当我的代码将准备发布我会将它合并到主干，因为这将是最新的稳定代码。同时我会将最新版本号和发布日期标记到标签文件夹中。
现在，由于您将最新的稳定代码放入主干，并将最新发布的源代码放入标签，您可以删除该特定分支。
【讨论】：