Repository organisation当我第一次开始使用CVS和SVN等版本控制系统时，我并不真正理解"主干"，分支，合并和标记的概念。 我现在开始理解这些概念，并真正了解它们背后的重要性和力量。 所以，我开始正确地做它。 还是我想...到目前为止，我的理解是：您代码的最新发行版/稳定版应位于/ trunk /中，而beta版或最新版本则位于/ branches /目录中，作为每个beta的不同目录 释放，然后在释放时合并到中继中。 对事物的看法太简单了吗？ 你们推荐什么存储库布局？ 如果有什么不同，我正在使用Subversion。 我通常做的标准是：
主干应包含您的开发主线，不稳定的版本。 就像是：
/ trunk(此处正在开发2.0版) 当您发现1.5中的错误时，可以在RB分支中对其进行修复，然后合并到中继中。 我也推荐这本书。 有关更多信息，请参见以下关于SO的两个问题：
我使用Perforce已有很长时间了，因此我的评论可能有点以Perforce为中心，但是基本原理适用于任何具有一半适当分支的SCM软件。 开发发生在从MAIN分支的分支中(通常-有时您可能希望从现有的dev分支中分支)。尽可能频繁地从MAIN集成到您的开发分支，以防止事情发生太大的分歧-或者您可以稍后预算更大的集成期。仅当确定在即将发布的版本中会淘汰该驴子时，才将其踢腿功能集成到MAIN中。 最后，您具有RELEASE行，该行用于不同版本的不同分支。根据您的SCM软件的标签功能以及主要/次要版本的不同可能有一些选择。因此，例如，您可以为每个点发行版选择发行版分支，或者仅针对主要版本号。你的旅费可能会改变。 通常，从MAIN分支以尽可能晚的时间发布。错误修正和最新更改可以直接进入RELEASE以供以后与MAIN集成，也可以直接与MAIN进行立即集成备份。没有一成不变的规则-做最有效的事情。但是，如果您有可能要提交给MAIN的更改(例如，从dev分支提交，或MAIN上的某个人进行了"小调整")，请执行前者。这取决于您的团队工作方式，发布周期等。 例如。我会有这样的事情：
一个不平凡的项目可能会同时有多个DEV分支处于活动状态。将开发集成到MAIN中以使其成为核心项目的一部分后，请尽快删除旧的DEV分支。许多工程师会将DEV分支视为自己的个人空间，并随着时间的推移将其重用于不同的功能。不鼓励这样做。 如果在发布后必须修复错误，请在相应的发布分支中进行修复。如果先前已在MAIN中修复了该错误，则可以将其集成，除非在MAIN中对代码进行了太多更改，否则修复将有所不同。 真正区别代码行的是用于管理它们的策略。例如，运行哪些测试，谁在更改之前/之后进行审查，构建失败会采取什么措施。通常，策略(因此开销)在发布分支中最强，而在DEV中最弱。这里有一篇文章介绍了一些场景，并链接到其他有用的东西。 最后，我建议从一个简单的结构开始，并仅根据需要引入其他开发和发布的结构。 希望能有所帮助，而不是太过强调流血。
Eric在源代码管理的使用和组织的最佳实践方面有一系列出色的文章。 |
