2

我在 SCM 工作，使用各种工具（Subversion、Clearcase、TFS、Perforce）和技术（主要是.NET、Java）。在我开始工作之前，正常的业务顺序是创建一个受控分支。

我将受控分支定义为： - 一个单独的分支，其中包含开发人员无法访问的提升代码。只有一个构建工程师团队可以访问它。

受控构建： - 构建引擎从受控分支获取代码并生成开发人员无法修改的工件。

因此，作为受控构建过程的一部分，合并到这个分支已成为重要的一步。这可能会产生速度和错误的问题（这将主要通过自动化来缓解）。

好处：自动代码锁定（因为开发人员不能修改分支）分支名称可以不同（其他团队不一定遵循标准化的做法，我们不一定能够施加所需的压力。）查找确切版本代码的简单方法状态（即版本的受控分支中的最新代码是去生产的）

缺点：在与开发人员讨论问题时，速度将开发构建与受控构建相匹配（这是自动化的，但有点混乱）。错误（过程中另一个混乱的地方） 安全/角色分离功能是否可以通过使用变更列表/变更集/不可变标签来完全处理？

问题：

我应该建议从当前的受控分支策略转移吗？我错过了其他好处吗？

4

2 回答 2

3

我不建议使用分支作为提升机制，除非您打算对要合并到所述分支的标签进行大量修改。分支应该隔离开发工作（即修改文件和提交新版本的地方
）

与某种元数据（ClearCase 属性、SVN 属性、Git 注释……）相关联的标签应该足以通过各种促销级别监控所述标签（及其不可变内容）的促销。

于 2011-01-11T18:59:33.043 回答
0

我们使用受控分支（MAIN）作为我们的官方构建分支。开发人员只能通过开发分支的合并操作访问该分支。此外，MAIN 分支代码被合并到一个 BUGFIX 分支，该分支专用于我们当前版本软件的错误修复，以及一个 PROD 分支，其中代码按每个版本进行标记。

我认为，任何为测试（以及最终）生产目的而构建的东西都不应该有随意的开发人员访问权限，并且应该由 SCM 经理或其他类型的图书馆员角色管理。

当我们在 MAIN 分支中确实存在构建问题时，我们也坚持让开发人员在开发分支中修复这些错误，并将解决方案合并回我们的 SCM 策略中的 MAIN。

于 2011-01-11T20:30:09.853 回答