我在SCM中使用各种工具（Subversion，Clearcase，TFS，Perforce）和技术（主要是.NET，Java）。在我开始工作之前，正常的业务顺序是创建一个受控分支。
我将受控分支定义为： - 一个单独的分支，包含开发人员无法访问的提升代码。只有一组构建工程师才能访问它。
受控制的构建： -Build引擎从受控分支获取代码并生成工件开发人员无法修改。
因此，作为受控构建过程的一部分，合并到此分支已成为重要的一步。这可能会产生速度和错误的问题（主要通过自动化来缓解）。
优点： 自动代码锁（因为开发人员无法修改分支） 分支机构名称可以不同（其他团队不一定遵循标准化实践，我们不一定能够施加所需的压力。） 找出确切的版本代码状态的简单方法（即版本的受控分支中的最新代码是产生的内容）
缺点： 速度 在与开发人员讨论问题时，将dev构建与受控构建匹配（这是自动化的，但有点混乱）。 错误（另一个陷入困境的地方） 是否可以使用changelists / changesets / immutable标签完全处理安全/角色分离功能？
问题：
我是否应该建议从当前受控分支策略转移？我错过了其他好处吗？
答案 0 :(得分：3)
我不建议使用分支作为促销机制，除非您打算从合并到所述分支的标签上进行大量修改。
branch should isolate a development effort （即修改文件和提交新版本的内容）
与某种元数据相关联的标签（ClearCase属性，SVN属性，Git注释......）应足以通过各种促销级别监控所述标签的推广（及其不可变内容）。
答案 1 :(得分：0)
我们使用受控分支（MAIN）作为我们的官方构建分支。开发人员只能通过合并开发分支的操作来访问此分支。此外，MAIN分支代码合并到BUGFIX分支，该分支专用于我们当前版本的软件的错误修正，以及PROD分支，其中代码在每个版本的基础上被标记。
我认为，为测试（以及最终）生产目的而构建的任何内容都不应该有临时开发人员访问权限，并且应由SCM管理员或其他类型的库管理员角色管理。
当我们在MAIN分支中确实存在构建问题时，我们也坚持要求开发人员在开发分支中修复这些错误，并在我们的SCM策略中将解决方案合并回MAIN。