2. Git 使用约定

2.1 仓库规范

仓库按组分类，分配权限。

现有分组：

  • Doc 文档

  • Ruishi 锐视

  • Lumicare 路美康尔

2.2 分支规范

开发过程主要存在以下分支：

  • master (新版使用main作为主分支)

  • dev

  • hotfix-[问题名称 | bug编号]

  • feature-[功能名称]

  • bugfix-[bug编号]

  • refactor-[重构名称]

master 主分支

  • master主分支始终保持稳定的可发布版本

  • 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）

dev 开发分支

  • dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的

  • 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发

hotfix-[问题名称 | bug编号] 紧急热修复分支

  • 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于**生产线问题紧急修复**！！！！

  • 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除

feature-[功能名称] 功能开发分支

  • 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程

  • 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支

bugfix-[bug编号] 问题修复分支

  • 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号

  • 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支

refactor-[重构名称] 重构分支

  • 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）

  • 重构以后，必须经过严格测试通过，才能向dev分支合并。

2.3 commit 规范

commit 格式

commit提交的日志格式 【类型:描述】

|类型|描述 |
|----|----|
|feature|新开发的功能|
|fix|问题修复|
|refactor|重构代码|
|doc|增加文档（如readme），注释等|

例如：

  • feat:新步进电机控制

  • fix:摄像机颜色显示不正确

  • refactor:重新实现device类

  • doc:doxy更新项目文档

commit 提交频率

  • 每天下班前必须提交feature分支，并push到远程

  • hotfix、feature、bugfix、refactor分支尽量按照功能点或修复重构的问题及时commit（不要求push）

standard001.png