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