在我正在研究的公司中，我们每x释放时间（通常为三个月）。在此期间，我们有四个六个"分支可释放"的冲刺，我们所有的代码都进入该分支。
一段时间后，该分支以XXX版本发布，我们只是转到下一个版本。但是由于通常的承诺，我们必须继续维持数月/年的旧版本。
我想知道该分支作为版本释放是否正确。因此，我们的释放分支从未完全重新整合到后备箱中。他们永远活着。为了维护它们，当在分支中找到一个错误时，我们将其修复在中继线中，然后手动将其移植到分支（我更喜欢这个），或者我们在分支中工作并移植它重新融合）回到后备箱。请注意，可以肯定的是，这可能会发生这种行李箱包含无法/无法合并到分支机构的代码，也许是因为该分支太老了，无法支持巨大的更改。
您知道我们使用的方法的好处/缺点吗？您还有另一种处理可维护版本的方法吗？也许外面的SVN？
基本上有两个不同的"躯干策略"：稳定的中继，其中躯干应始终是可释放的质量，所有发育都在重新整合的分支中进行，不稳定的躯干在主干中进行主动发育的位置，并且在释放前进行了分支以进行稳定。
无论使用哪种中继策略，发布的版本都应始终是不重新融合的分支。
遵循不稳定的树干策略的一个示例策略（行李箱中的主动开发需要在发布之前进行稳定）：
开发在树干中的发展为1.0。在某个时候，创建了1.x的分支，并稳定了代码。一旦将代码视为稳定，将其标记为1.0并释放。同时，工作在第2版的中继线中进行了进展，该版本很快将在2.x分支中分支。
。版本1.0中发现的错误可以在1.x分支中固定，并且版本1.1可以使用BugFix从该分支发布。如果该错误在中继中相关，则可以将其合并。但是该功能可以在中继线中删除或重建，从而使此错误将其合并到毫无意义或不可能的行李箱中。如果该版本2的Beta测试仪在中继线中发现了该错误，则可以在此处修复该错误，然后查看旧的维护分支（例如1.X）是否具有错误，然后将其合并到那里。它双向工作。
我看不出每个版本的分支机构如何更好的策略（在我的示例中是每个主要版本的分支，而不是每个版本），而且我看不到版本/版本分支应该的情况重新整合到后备箱中。
我想知道分支作为版本释放是否正确。
好吧，至少这不是完全不正确的 - 您一直都有可管理的代码。不是您的内部游戏，您可以在不破坏主要任务的同时玩游戏 - 随着时间的推移并解决较旧的问题，您可以玩。差异的代码线是您的成本
从PM POV中，您的"混合"工作流程（分支机构中的2个来源，合并组和普通线性历史记录）在更难转换为从log转换为最终的"完成列表"以供发布，我更喜欢，广告和广告系列"分支" - 按任务"工作流程（在任何SCM中） - 这种方式分支（开发，大多数）是短期，可整合的工作部分，并且Mainline＆amp;版本分支只能获得合并集，而易于观察。但这只是个人喜好和口味
我想我将始终将最新的稳定代码保留在中继线中，当前的开发版本将在分支机构中存在（分支机构中会有许多版本要求）。当我的代码准备发布后，我将其将其合并到中继线上，因为这将是最新的稳定代码。同时，我将使用最新版本号和发布日期标记为标签文件夹。
现在，由于您将最新的稳定代码纳入行李箱和最新发布的源代码中，因此您可以删除该特定分支。