当我第一次开始使用CVS和SVN等版本控制系统时，我并没有真正理解"主干"，分支，合并和标记的概念。我现在开始了解这些概念，并真正了解它们背​​后的重要性和力量。

所以，我开始正确地做它。还是我想...到目前为止，我的理解是：我们代码的最新发行版/稳定版应该位于/ trunk /中，而beta版或者最新版本则位于/ branches /目录中，作为每个beta的不同目录释放，然后在释放时合并到主干中。

对事物的看法太简单了吗？你们推荐什么存储库布局？如果有什么不同，我正在使用Subversion。

解决方案

回答

有关更多信息，请参见以下关于SO的两个问题：

• 分支，标记和主干到底是什么意思？
• 颠覆问题

回答

我通常做的标准是：

中继线应包含开发主线，不稳定的版本。
我们应该为发布创建发布分支。

就像是：

/ trunk(此处正在开发2.0版)
/branches/RB-1.0(这是1.0的发行分支)
/分支机构/RB-1.5

当我们发现1.5中的错误时，可以在RB分支中对其进行修复，然后合并到主干中。

我也推荐这本书。

回答

埃里克(Eric)撰写了一系列有关源代码管理使用和组织最佳实践的出色文章。
第7章讨论分支(是的，它建议我们建议使用/ trunk /和/ branches /目录)。

回答

我使用Perforce已有很长时间了，因此我的评论可能有点以Perforce为中心，但是基本原理适用于任何具有一半适当分支的SCM软件。
我坚信使用分支开发实践。我有一个" main"(又称" mainline")，代表从现在到永恒的代码库。目的是在大多数情况下保持稳定，并且如果一推再推，我们可以随时减少一个反映系统当前功能的发布。那些讨厌的销售人员一直在问...。

开发发生在从MAIN分支的分支中(通常偶尔我们可能要从现有的dev分支中分支)。尽可能频繁地从MAIN集成到开发分支，以防止事情发生太大分歧，或者我们可以在以后较大的集成期间简单地进行预算。仅当确定在即将发布的版本中会淘汰该功能时，才将驴子踢新功能集成到MAIN中。

最后，我们有一个RELEASE行，该行用于不同版本的不同分支。根据SCM软件的标签功能以及主要/次要版本的不同可能有一些选择。因此，例如，我们可以为每个点发行版选择发行版分支，或者仅针对主要版本号。你的旅费可能会改变。

通常，从MAIN分支以尽可能晚的时间发布。错误修正和最新更改可以直接进入RELEASE以供以后与MAIN集成，也可以直接与MAIN进行立即集成备份。没有硬性规定可以做到最好。但是，如果我们有可能提交给MAIN的更改(例如，从dev分支提交，或者MAIN上的某个人进行了"小调整")，则请执行前者。这取决于团队工作方式，发布周期等。

例如。我会有这样的事情：

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

一个不平凡的项目可能会同时有多个DEV分支处于活动状态。将开发集成到MAIN中以使其成为核心项目的一部分后，请尽快删除旧的DEV分支。许多工程师会将DEV分支视为自己的个人空间，并随着时间的推移将其重用于不同的功能。不鼓励这样做。

如果在发布后必须修复错误，请在相应的发布分支中进行修复。如果先前已在MAIN中修复了该错误，则将其整合，除非该代码在MAIN中发生了太大更改，否则修复会有所不同。

真正区别代码行的是用于管理代码行的策略。例如，运行哪些测试，谁在更改之前/之后进行审核，构建失败会采取什么措施。通常，策略和开销因此在发布分支中最强，而在DEV中最弱。这里有一篇文章介绍了一些场景，并链接到其他有用的东西。

最后，我建议从一个简单的结构开始，并仅根据需要引入其他开发和发布的结构。

希望能有所帮助，而不是太过强调流血。