当我第一次开始使用CVS和SVN之类的修订控制系统时，我并没有真正理解“主干”，分支，合并和标记的概念。我现在开始理解这些概念，并且真正了解它们的重要性和力量。
所以，我开始正确地做到了。或者我认为......这是我到目前为止所理解的：代码的最新版本/稳定版本应位于/ trunk /，而beta版本或最新版本位于/ branches /目录内，作为每个beta的不同目录释放，然后在释放时合并到主干中。
这是对事物的看法过于简单吗？你们推荐哪些存储库布局？如果它有所作为，我正在使用Subversion。
答案 0 :(得分：5)
有关更多信息，请参阅SO上的这两个问题：
答案 1 :(得分：5)
我所做的和通常看作标准的是：
主干应包含您的主要开发线，您的不稳定版本。 您应该为您的版本创建发布分支。
类似的东西：
/ trunk（这里你正在开发版本2.0） /branches/RB-1.0（这是1.0的发布分支） /branches/RB-1.5
当你在1.5中发现一个错误时，你会在RB分支中修复它，然后合并到主干。
我还建议this book。
答案 2 :(得分：1)
Eric有一系列关于源代码控制使用和组织最佳实践的优秀文章。 Chapter 7 deals with branches（是的，它推荐你建议的/ trunk /和/ branches /目录）。
答案 3 :(得分：1)
我已经使用Perforce了很长时间，因此我的评论可能有点以Perforce为中心，但基本原则适用于任何具有一半分支的SCM软件。 我非常坚信使用分支开发实践。我有一个“主”（又名“主线”）代表从现在到永恒的代码库。目标是，在大多数情况下，这是稳定的，如果推动推动，您可以随时切换一个能够反映系统当前功能的版本。那些讨厌的销售人员一直在问......
发展发生在从MAIN分支的分支中（通常 - 有时您可能希望从现有的dev分支分支）。尽可能多地将MAIN与您的开发分支集成，以防止事情发生太大分歧 - 或者您可以在以后预算更大的集成期。只有当您确定它将在即将发布的版本中发布时，才能将您的新功能集成到MAIN中。
最后，您有一个RELEASE行，可以选择不同版本的不同分支。根据SCM软件的标签功能以及可能的主要/次要修订版本的不同，有一些选择。因此，您可以选择每个版本的发布分支，或仅针对主要版本号。您的里程可能会有所不同。
通常，从MAIN分支到尽可能晚地发布。错误修正和最后一刻更改可以直接进入RELEASE以便以后集成到MAIN，也可以直接进入MAIN以立即进行集成备份。没有硬性和快速的规则 - 做最好的事情。但是，如果您有可能提交给MAIN的更改（例如来自开发分支，或MAIN上某人的“小调整”），那么请执行前者。这取决于您的团队的工作方式，发布周期等等。
E.g。我会有这样的事情：
//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中最弱。有一篇文章here介绍了一些场景，并链接到其他有用的东西。
最后，我建议采用简单的结构开始，并且只引入额外的开发和放大器。根据需要发布。
希望有所帮助，而不是说出血 - 显然太多了。