存储库组织

当我第一次开始使用版本控制系统如CVS和SVN时，我并没有真正理解“trunk”，分支，合并和标记的概念。我现在开始理解这些概念，并真正了解它们的重要性和力量。存储库组织

所以，我开始正确地做。或者所以我认为...这是我目前了解的内容：代码的最新版本/稳定版本应该位于/ trunk /中，而beta版本或流血版本位于/ branches /目录内作为每个测试版的不同目录释放，然后在释放时合并到主干中。

这是对事物过于简单化的看法吗？你们建议什么样的存储库布局？如果它有所作为，我使用Subversion。

来源

2008-08-20 mercutio

看到这两个问题上的SO了解更多信息：

来源

2008-08-20 11:06:07

我做什么，通常会看到一个标准是：

树干应该包含你的主要发展路线，你的不稳定版本。您应该为您的版本创建发布分支。

喜欢的东西：

/中继线（这里你正在开发2.0版） /branches/RB-1.0（这是1.0发布分支） /branches/RB-1.5

当你在1.5中找到一个bug，将其修复到RB分支中，然后合并到主干。我也推荐this book。

来源

2008-08-20 11:10:16

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

来源

2008-08-20 11:28:43

我已经使用Perforce很长一段时间了，所以我的评论可能会以Perforce为中心，但基本原则适用于任何具有一半体面分支的SCM软件。我是一个非常坚信使用分支开发实践的人。我有一个“主”（又名“主线”），代表从现在到永恒的代码库。目标是在大多数情况下，这是稳定的，如果推动推进，您可以在任何时候削减发布，以反映系统的当前功能。那些讨厌的销售人员不断询问......

开发发生在从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分支视为他们自己的个人空间，并随着时间的推移将其重用于不同的功能。劝阻这一点。

如果在发布之后，您必须修复一个bug，然后在相应的发布分支中执行该操作。如果之前在MAIN中已经修复了该错误，则整合，除非MAIN中的代码已经发生了很大的变化，修正则不同。

真正区分代码行的是您用来管理它们的策略。例如，哪些测试运行，哪些人评论变更前/变更后，如果构建中断，会发生什么操作。通常情况下，策略 - 因此开销 - 在发布分支中最强，在DEV中最弱。有一篇文章here经历了一些场景，并链接到其他有用的东西。

最后，我建议以一个简单的结构开始，并根据需要只引入额外的dev &版本。

希望能够帮助，而不是说出血 - 显然太多了。

来源

2008-08-20 11:37:35

回答

相关问题