在我工作的公司中，我们每隔x个时间（通常是三个月）发布一次。在此期间，我们有四到六个分支可释放的＆＃39; sprint和我们所有的代码进入那个分支。
一段时间后，分支机构以版本xxx发布，我们继续下一个版本。但是由于通常的承诺，我们必须继续保持几个月/几年的旧版本。
我想知道版本发布的分支是否正确。因此，我们的release-version-branch永远不会完全重新集成到主干中。他们永远活着。为了维护它们，当在分支中发现错误时，我们将它固定在主干中并手动将其移植到分支（我更喜欢这个）或者我们在分支中工作并移植它（在主干中没有一个提交分支）重新整合）回到行李箱。请注意，可能会发生这样的情况，即主干包含的代码无法合并到分支中，可能因为该分支太老而无法支持巨大的变化。
您知道我们使用的方法的好处/缺点吗？你有另一种处理可维护版本的方法吗？也许在svn之外？
答案 0 :(得分：2)
基本上有两种不同的“中继策略”：稳定中继，其中中继应始终是可释放的质量，所有开发都在重新集成的分支中进行，不稳定中继活跃的发育发生在树干中，并在释放前分层稳定。
无论使用哪种中继策略，发布的版本应始终是未重新集成的分支。
不稳定主干策略之后的示例（主干中的主动开发，需要在发布之前进行分支以进行稳定化）：
开发在1.0的主干中进行。在某些时候，创建1.X的分支并且代码稳定。一旦代码被认为是稳定的，它就被标记为1.0并被释放。同时，在版本2的主干中工作进展，很快将在2.X分支中分支，等等。
版本1.0中发现的错误可以在1.X分支中修复，版本1.1可以通过错误修复从该分支发布。如果错误与主干相关，则可以合并。但是可以在主干中移除或重建该功能，使得该错误修复与主干的合并毫无意义或不可能。如果版本2的beta测试人员在主干中发现了这个bug，那么你可以在那里修复它，然后看看旧的维护分支如1.X是否有bug，然后在那里合并bugfix。它有两种方式。
我没有看到如何为每个版本提供更好的策略而不是分支（在我的示例中，每个主要版本的分支，而不是每个版本），我没有看到版本/发布分支应该出现的情况重新融入后备箱。
答案 1 :(得分：1)
我想知道版本发布的分支是否正确。
嗯，至少并非完全错误 - 您始终拥有可管理代码。没有完全重新整合的分支是你的内部游戏，你可以玩，而不会破坏主要任务 - 随着时间的推移释放产品并解决旧的问题。分散的代码行是你的成本
从PM POV您的“混合”工作流程（2个来源，合并和普通线性历史记录）更难以从日志转换为最终的“Done-List”发布，我更喜欢，广告和宣传“分支” -per-task“工作流程（在任何SCM中） - 这种方式分支（开发，大多数）是短暂的，可集成的工作部分和主线和版本分支将只获得更容易观察的合并集。但这只是个人喜好和品味
答案 2 :(得分：0)
我认为我将始终在trunk中保留最新的稳定代码，当前开发版本将在分支中存在（分支中将有许多版本，因为不同的人将处理不同的要求）。之后我的代码将准备发布我将它合并到主干，因为这将是一个最新的稳定代码。同时，我会将最新的版本号和发布日期标记到标签文件夹中。
现在，由于您在trunk中有最新的稳定代码，并且最新发布的源代码已添加到标记中，因此您可以删除该特定分支。