在版本控制软件中将当前开发与维护开发区分开来的推荐方法是什么？

我有一些使用Git管理的软件应用程序。我刚刚发布了一个我打算长期维护的新版本2.x（主要是错误修复）。同时，我想开始使用3.x版。建议的管理方式是什么？我应该为版本2.x创建分支并在主版本上进行3.x开发吗？或另一种方式？

这里描述了一种非常有趣的做事方式：成功的Git分支模型

我发现它很有趣，但尚未实际使用。

很好，按要求对文章内容进行了（非常）简短的总结：

• Master分支仅每个代表已完成的里程碑（即1.0、1.1、1.2等版本）
• 开发是在它自己的分支中完成的（通常叫“ develop”，谁曾想到？）。每当完成功能完整版本时，develop分支就会合并回Master分支。
• 从开发中分支出来的是功能分支。这些代表下一个（或任何将来）版本的单个功能。他们与开发分支合并。
• 来自开发的另一个分支是“发行”分支。这是一个代表几乎完整的发行版本的分支，其中仅需要清除少量细节。它与开发部门合并，最终与Master部门合并
• 如果您在一个发行版中发现严重的错误，则从master分支的“ Hotfix”分支分支（即“如果使用者输入了konami代码，我们的程序将重新格式化主硬盘驱动器...”）。它来自越野车发行版，当修复完成时，它会合并回到master分支和devlopment分支中。

这是它的不足，但请相信我，本文以更详细的方式对其进行了描述，并且借助有用的可视化图形，它更易于理解。

我的原则是分支的期限越短，分支结构中的分支应越深，其名称越具体。分支的期限越长，分支结构中的分支将越浅，其名称将更通用。

因此，您保留了较高版本（3.X）的master，并继续使用通用名称（master，trunk，devel等）命名该分支，而不使用特定名称（发行代号或更糟糕的发行版）在实践中过于依赖后期的营销决策）

在像git这样的系统中，它没有多大关系，该系统为分支有一个统一的名称空间，并且分支等效。对于像clearcase这样的系统，它具有分支的分层命名空间（V4分支的全名以beeing main / v1 / v2 / v3 / v4 ...结尾）更重要。