•  09-06-2019
  •  | 
  •  

题

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

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

这样的看法是否过于简单化了？你们推荐什么存储库布局？如果有影响的话，我会使用 Subversion。

有帮助吗？

解决方案

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

其他提示

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

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

就像是：

/TRUNK（此处您正在开发2.0版） /Branches/RB-1.0（这是1.0的版本分支） /Branches/RB-1.5

当你在1.5中发现bug时，你可以在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 中的代码发生了很大变化，修复会有所不同。

代码线的真正区别在于您用于管理它们的策略。例如，运行哪些测试、谁在更改前/后进行审查、如果构建中断会采取什么操作。通常，策略（以及开销）在发布分支中最强，而在开发分支中最弱。有一篇文章 这里 它经历了一些场景，并链接到其他有用的东西。

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

希望能有所帮助，并且不要说得太明显。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top