分支管理参考git-flow(git-flow介绍)的工作流程,但不使用git-flow。所有的分支的操作都需要手工完成。
1.1、git-flow流程图:
1.2、分支说明:
featrue/XXX: 功能开发分支,继承自master分支,根据需求或者线上bug创建分支,开发、测试阶段所有改动只在该类型分支上修改;
dev: 开发合并分支,合并来自feature/*的分支代码,注意不要在此分支上做修改提交!!!只做合并操作!!!,并在此分支打包提交测试;
master:发布分支,feature/*测试通过的分支,合并到该分支,注意不要在此分支上做修改提交!!!只做合并操作!!!,并在此分支打包发布。
hotfix/XXX: 热修复分支,继承自master分支,仅用于修复master分支上的问题。完成后合并到各分支。
bugfix/XXX: bug修复分支,继承自master分支,仅用于修复master分支上的问题,完成后合并到各分支。
注意:当合并有冲突时,要解决冲突后再提交,避免造成页面奔溃。不熟悉命令合并的同学可以使用编辑器的merge功能,或者可以使用工具,如:sourceTree。
2. commit 规范
一般来说,commit message 应该清晰明了,说明本次提交的目的。我们参考目前比较流行的Angular规范
commit 格式:<type>: <subject>(注意冒号后面有空格)。
(1)type: 用于说明 commit 的类别,无特殊情况下只使用下面7个标识。
- feat:新功能(feature)
- fix:修补bug
- docs:文档(documentation)
- style: 格式(不影响代码运行的变动)
- refactor:重构(即不是新增功能,也不是修改bug的代码变动)
- test:增加测试
- chore:构建过程或辅助工具的变动
(2)subject: commit 目的的简短描述,不超过50个字符。
例:
git commit -m "feat: 新增酒店刷新页面"
git commit -m "fix: 活动中心基本信息页活动ID不可选"
git commit -m "doc: readme文件添加项目打包说明"
注意:如果是有多种形式的修改,以最主要的修改选择type,其他修改可在subject中说明。
3、版本发布规范
已经测试完毕的功能分支合并到master,按版本号打tag。
版本号组成::v <主版本号>. <子版本号>. <修订号>。
主版本号前加v标识表示version。如初始版本可为v1.0.0或v0.1.0
管理策略:
- 当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1。如v0.1.1;
- 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0。如:v0.2.0;
- 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1。如:v1.0.0;
版本说明:
每一次版本的发布都需要对该次版本上线进行说明,说明信息参考commit规范:
例:
git tag -a v0.1.0 -m "feat: 初始版本上线,包括首页、列表页、详情页等" master
建议:可在项目中添加版本说明文档,可方便查看生产环境当前版本。