代码分支管理规范细则

代码分支管理规范细则一、总则规范（一）适用范围。本细则适用于公司所有研发项目代码分支的创建、维护、合并及废弃等全生命周期管理，涵盖前端、后端、移动端及基础设施等所有技术栈，确保代码版本一致性、可追溯性与高可维护性。（二）基本原则。代码分支管理遵循统一规范、最小权限、及时归档、风险可控四项基本原则，所有分支操作必须基于版本控制系统（VCS）进行，禁止任何线下修改行为。二、分支类型定义（一）主干分支。主分支（master/main）为唯一发布源，仅允许通过严格评审的合并请求更新，禁止直接推送代码。主分支每日进行一次全量构建与静态扫描，异常时触发告警。（二）开发分支。各项目组每日创建以日期为命名的临时开发分支（格式：dev-YYYYMMDD），分支存在周期不得超过48小时，使用后需立即删除未完成分支。（三）功能分支。新功能开发必须基于最新主分支创建功能分支（格式：feature/模块名-功能编号），分支创建时需同步更新项目看板，完成后通过CodeReview后方可合并。（四）修复分支。紧急线上问题修复需创建热修复分支（格式：hotfix/模块名-问题编号），优先级高于常规功能分支，合并后48小时内完成双测验证。三、分支创建与命名（一）创建流程。分支创建必须通过GitLab/Jira等工具发起工单，经项目负责人确认后方可执行，禁止无工单创建分支。（二）命名规范。分支命名需包含模块标识、功能标识和创建人信息，具体格式为：模块类型-业务线-功能编号-创建人（如：api-订单模块-001张三）。命名最长不超过50字符，禁止使用中文、空格及特殊符号。四、分支生命周期管理（一）创建时限。功能分支必须在需求评审通过后24小时内创建，开发分支每日工作开始前完成创建。（二）合并标准。主分支合并必须满足：1.代码静态扫描无高危问题2.单元测试覆盖率≥80%3.持续集成构建通过率100%4.产品验收通过（三）废弃机制。超过6个月未使用的分支自动触发废弃流程，由运维团队执行删除操作，需提前30天发布废弃公告。五、操作权限管控（一）权限分级。1.主分支：仅限架构师、测试经理、运维总监2.开发分支：仅限开发人员3.功能分支：仅限需求提出人及关联开发人员（二）权限变更。新增权限申请需填写《权限变更申请表》，经信息安全部门审核后更新RBAC配置，变更记录存档3年。六、合并流程细则（一）合并策略。1.主分支合并：采用变基合并（rebase），禁止快进合并2.功能分支合并：必须基于目标分支最新提交3.热修复分支：优先合并至主分支，后续同步至相关开发分支（二）冲突处理。分支合并冲突必须在分支存在周期内解决，冲突日志需记录在Jira工单附件中，未解决冲突禁止提交至主分支。七、版本发布管理（一）发布流程。1.发布前需完成代码冻结，冻结期不少于24小时2.发布需通过发布评审会，记录在案3.发布后执行全链路监控，异常立即回滚（二）版本命名。正式版本号格式为：主版本号.次版本号.修订号（如：1.2.3），修订号按如下规则变更：1.大版本号：API不兼容变更2.次版本号：新功能添加3.修订号：修复bug八、异常处理预案（一）分支丢失。分支意外丢失时需通过提交历史重建，重建过程需经技术总监审批，重建记录写入项目文档。（二）合并失败。合并失败时必须分析原因，常见问题及解决方法需汇总至《常见问题库》，包括：1.基线不一致：执行gitfetch--all后重新变基2.权限不足：临时提升权限完成合并3.网络中断：使用本地缓存继续合并九、审计与监督（一）日志留存。所有分支操作需在VCS中完整记录，日志保留周期不少于12个月，运维部门定期抽检。（二）定期审计。每季度开展一次分支管理专项审计，重点关注：1.分支创建合规性2.合并请求审批流程3.冲突解决时效性十、附则说明（一）本细则自发布之日起生效，由技术管理部负责解释