存储库组织

有关更多信息,请参阅SO上的这两个问题:

• What does branch, tag and trunk really mean?
• Subversion question

我通常认为的标准是:

主干应该包含你的主线开发,你的不稳定版本。 您应该为您的发布创建发布分支。

类似于:

/trunk(您正在开发2.0版本) /branches/RB-1.0(这是1.0的发布分支) /分支机构/RB-1.5

当你在1.5中发现一个bug时,你可以在RB分支中修复它,然后合并到主干中。

我也推荐 this book .

Eric有一系列关于源代码管理使用和组织最佳实践的优秀文章。 Chapter 7 deals with branches (是的,它推荐您建议的/trunk/和/brances/目录)。

我已经使用Perforce很长时间了,所以我的评论可能有点以Perforce为中心,但基本原则适用于任何有一半不错分支的SCM软件。 我非常相信使用分支开发实践。我有一个“main”(又名“mainline”),它代表了从现在到永恒的代码库。目的是,在大多数情况下,这是稳定的,如果情况紧急,你可以随时发布反映系统当前功能的版本。那些讨厌的销售人员一直在问。...

开发发生在从MAIN分支的分支中(通常-偶尔您可能希望从现有的开发分支分支)。尽可能经常地从MAIN集成到您的开发分支,以防止事情分歧太大——或者您可以简单地为以后更大的集成期做预算。只有当你确定它将在即将发布的版本中推出时,才能将你的新功能集成到MAIN中。

最后,您有一个RELEASE行,其中包含不同版本的不同分支的选项。根据SCM软件的标签功能以及主要/次要版本的不同程度,有一些选择。因此,您可以选择,例如,为每个点发布设置一个发布分支,或者只设置主要版本号。您的里程数可能会有所不同。

一般来说,从MAIN分支发布要尽可能晚。Bug修复和最后一刻的更改可以直接进入RELEASE,以便稍后集成到MAIN,也可以进入MAIN进行即时集成备份。没有硬性规定——做最有效的事。但是,如果您有可能提交到MAIN的更改(例如,来自开发分支的更改,或者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进行集成,除非MAIN中的代码发生了很大变化,否则修复是不同的。

真正区分代码行的是您用来管理它们的策略。例如,运行哪些测试,谁在更改前后进行审查,如果构建中断会发生什么操作。通常,策略(以及开销)在发布分支中最强,在开发分支中最弱 here 这会经历一些场景,并链接到其他有用的东西。

最后,我建议从一个简单的结构开始,只引入额外的开发和维护;根据需要释放。

希望这能有所帮助,不要说出血太明显。