像素点建网站,自豪地使用wordpress,深圳网站建设黄浦网络-骗子,河南网站建设公司哪家好一、目的
通过标准化的流程和最佳实践#xff0c;确保代码组织清晰、版本控制高效、变更管理有序#xff0c;从而提高软件开发的质量、效率和可维护性#xff0c;支持团队协作和持续集成/持续部署流程#xff0c;最终实现项目的长期成功和发展
二、分支命名规范 简洁明了…一、目的
通过标准化的流程和最佳实践确保代码组织清晰、版本控制高效、变更管理有序从而提高软件开发的质量、效率和可维护性支持团队协作和持续集成/持续部署流程最终实现项目的长期成功和发展
二、分支命名规范 简洁明了使用英文小写字母和下划线避免使用特殊字符。 易于识别通过命名能够快速识别分支的用途和所属项目。 统一规范确保所有团队成员遵循相同的命名规则。
分支名称分支命名功能介绍约束对应环境主干分支master用于线上部署的稳定代码只接受合并请求每次发布打上Tag标签生产环境开发分支dev用于整合开发成员的代码的主干分支从master分支创建开发环境发布分支release/xxx用于发布新版本的分支xxx为版本号从develop分支创建最终合并回maste分支只接受合并请求测试/UAT/生产环境修复分支hotfix/xxx用于修复线上紧急bug的分支xxx为版本号从master分支创建并合并回master和develop分支。测试环境修复分支fix/xxx用于修复转测的bug。从release/xxx创建xxx为迭代编号转测编号如fix/1.6就是迭代1第6次转测最终合并到release/xxx和dev分支开发环境测试环境
三、分支的使用和管理规范
1、源码仓库初始化
当接收到正常的业务需求时项目经理/开发主管根据架构设计在gitlib上创建初始版项目全英文小写中间用_作为连接符 后端代码以_service后缀 前端代码以_web后缀 移动端代码以_app后缀
创建分支项目创建为master分支为主干分支基于master创建dev分支基于dev创建release分支如果版本没确定可以放到转测时创建设置三分支均为受保护分支且master/release分支只有Maintainer角色可以合并。
注Maintainer角色只能授予PM、测试组长、技术组长 2、新功能开发流程 新的迭代开始所有开发人员从主干dev拉个人分支开发特性, 分支命名规范 feature-name根据项目实际情况可以省略特分支此分支就是个人远程仓库防止直接合入开发分支通过提交merge的方式只有代码检视通过才能合入提升代码库质量--这里可以增加自动代码审查。 开发完成后通过自测本地代码质量扫描合入dev分支 将本次迭代转测所有代码部署到dev环境完成集成测试并通过代码质量检查 基于dev拉取要发布的分支release/xxx如果创建好则跳过将这个分支部署到测试环境进行测试 验收测试通过后基于release/xxx发布版本。 待版本发布稳定后将release/xxx同步到master同时在 Master 分支上打个 Tag 记住 release 版本号然后可以删release/$version
3、修复线上Bughotfix分支 从 master 分支某个 tag 上创建一个 hotfix 分支热修复分支一般是最新的 tag 应该和当前生产环境对应 开发人员完成Bug 修复提交 hotfix 分支到测试环境验收通过 基于hotfix分支发布版本 待版本发布稳定后将 hotfix 分支合并到dev与master 分支同时在 master 分支上打个 Tag 记住 hotfix 版本号 删除 hotfix 分支
4、测试Bug修复流程 基于release/xxx分支创建fix/xxx的修复分支 在fix/xxx的修复分支在开发环境自测通过通知测试部署到测试环境验证 测试验证通过研发将fix/xxx分支代码同步到release/xxx与dev分支同时删除fix/xxx分支 四、提交内容规范
Git 每次提交代码都要写 Commit message提交说明否则就不允许提交。但是一般来说commit message 应该清晰明了说明本次提交的目的。提交规范设置为 type:subject
type
用于说明 commit 的类别只允许使用下面7个标识。 feat新功能feature fix修补bug docs: 仅文档更改 style格式不影响代码运行的变动 refactor重构即不是新增功能也不是修改bug的代码变动 revert回滚到上一个版本 test增加测试
subject
subject 是 commit 类型的简短描述建议不超过50个字。
五、提交分支规范 禁止向主分支直接提交代码包括代码仓库在线编辑修改 禁止提交测试性代码到任何主分支源码src目录测试代码只能存在于测试test目录 禁止任何工作分支跨主分支提交代码工作分支从只能合并到与工作分支同源的主分支 必须备注每一次提交代码备注必须简要可读。准确的描述具备可检索性 必须备注每一次合并请求对合并请求包含的功能点简要描述。准确的描述具备可检索性。 必须每次提交之前本地完成代码质量扫描 必须完成代码质量扫描才能合入release/xxx分支
六、分支的删除规范 修复分支
– hotfix/xxx 合并到master与dev分支可以删除fig/xxx合并到dev和release/xxx 可以删除。 发布分支
– release/xxx合并到master后可以产出。 注意事项
– 删除分支前确保该分支的代码已经合并回了相应的主分支并且不再需要保留。
七、其他注意事项 定期进行分支清理避免分支过多导致管理混乱。 团队成员应定期培训和交流确保对分支管理规范有深入理解和遵循。 遵循敏捷开发原则灵活调整分支管理策略以适应项目需求变化。
