5

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

所以，我开始正确地做这件事。或者我认为......这是我迄今为止所理解的：你的代码的最新版本/稳定版本应该位于 /trunk/ 而 beta 版本或前沿版本位于 /branches/ 目录中，作为每个 beta 的不同目录释放，然后在释放时合并到主干中。

这种看待事物的观点是否过于简单化了？你们推荐什么存储库布局？如果它有所作为，我正在使用 Subversion。

4

4 回答 4

5

有关更多信息，请参阅关于 SO 的这两个问题：

于 2008-08-20T11:06:07.540 回答
5

我所做的并且通常视为标准的是：

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

就像是：

/trunk（这里你正在开发 2.0 版本）/branches/RB-1.0（这是 1.0 的发布分支）/branches/RB-1.5

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

我也推荐这本书。

于 2008-08-20T11:10:16.360 回答
1

Eric 有一系列关于源代码控制使用和组织最佳实践的优秀文章。 第 7 章涉及分支（是的，它推荐了您建议的 /trunk/ 和 /branches/ 目录）。

于 2008-08-20T11:28:43.193 回答
1

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

开发发生在从 MAIN 分支的分支中（通常 - 有时您可能希望从现有的 dev 分支分支）。尽可能频繁地从 MAIN 集成到您的开发分支，以防止出现太多分歧 - 或者您可以简单地为以后更大的集成期进行预算。仅当您确定它将在即将发布的版本中推出时，才将您的屁股踢新功能集成到 MAIN 中。

最后，你有一个 RELEASE 行，它为不同的版本选择不同的分支。有一些选择取决于您的 SCM 软件的标签功能，以及主要/次要修订的不同程度。因此，您可以选择，例如，为每个点发布选择发布分支，或者只选择主要版本号。你的旅费可能会改变。

通常，尽可能晚地从 MAIN 分支到发布。错误修复和最后一分钟的更改可以直接进入 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 中发生了很大变化，否则修复是不同的。

真正区分代码线的是您用来管理它们的策略。例如，运行哪些测试，谁在更改前/后进行审核，如果构建中断会发生什么操作。通常策略——因此开销——在发布分支中最强，而在 DEV 中最弱。这里有一篇文章介绍了一些场景，并链接到了其他有用的东西。

最后，我建议从一个简单的结构开始，并且只根据需要引入额外的开发和发布结构。

希望这会有所帮助，并且不会过多地说明流血。

于 2008-08-20T11:37:35.577 回答