存储库组织

有关详细信息，请参阅有关 SO 的以下两个问题：

• branch、tag 和 trunk 的真正含义是什么？
• 颠覆问题

我所做的和通常被视为的标准是：

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

像这样：

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

当您在 1.5 中发现错误时，您可以在 RB 分支中修复它，然后合并到主干中。

我也推荐这本书。

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

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

开发发生在从 MAIN 分支的分支中（通常 - 有时您可能希望从现有的开发分支分支）。尽可能多地从 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 中最弱。这里有一篇文章介绍了一些场景，并链接到其他有用的东西。

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

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