git规范
git人员角色
- Owner
- Master
- Developer
- Reporter
- Guest
git分支
| 分支类型 | 命名规范 | 示例 | 说明 | | — | — | — | — | — | | master | master | master | 主线分支、线上稳定版本 | | develop | develop | develop | 开发稳定版本 | | release | release/xxx | | 发布到测试环境的版本 | | hotfix | hotfix/xxx | | 特定版本,用来紧急修复线上bug | | feature | feature/xxx | | 功能开发分支,可存在多个,用来开发不同功能 |
分支管理流程
- 开发开始时，从 develop 分支拉取新的 feature 分支 和 release 分支
- 如果此次迭代的版本中有些功能要上线，有些不要上线。要将这些功能区分开，拉取不同的 feature 分支。要发布的和不发布的在不同分支上开发。
- 功能开发完成后，将要测试的功能代码合并到 release 分支上。不用发布的分支不合并。
- 从 release 分支上拉取代码，部署到测试服务器上。测试人员进行测试。
- 测试完毕后，将 release 分支合并到 develop 和 master分支。
- 从 master 分支拉取最新的代码部署到客户现场，并打 tag。
- 客户现场部署后，如果发现 bug 要紧修复。需要从 develop 分支拉取 hotfix 分支。在该分支上进行修复。修复完后合并到 release 分支进行测试。然后再进入步骤 4。
hotfix 分支使用完后可立即删除。
需要同时开发不同迭代版本的功能时，要建多个 feature 和 release 分支。
git提交规范
提交时的信息采用流行的 Angular 规范。每次提交，信息都包括三部分：Header、Body、Footer。
Header 是必须的，Body 和 Footer 可省略。
<type>: subject
// 空一行
<body>
// 空一行
<footer>
如：
fix: 修复xx时的bug
将xx表的xx字段设定默认值
Header
- type
- feat: 新增功能
- fix: 修复bug
- docs: 修改文档、注释等
- refactor: 代码重构，未新增功能、未修复bug
- build: 新增依赖、工具等
- style: 不改变代码逻辑，仅修改代码格式
- perf: 改善性能
- test: 修改测试用例
- ci: 自动化相关修改
- revert: 回滚到上个版本
- scop: 可选填，表示影响的范围
- subject: 简要说明，不超过 50 个字
Body
此次提交的详细描述，可分多行
Footer
- 不兼容的相关信息
- 关闭哪些 Issue