本人在实际工作中总结出的Git使用规范，比较简单，容易落地。
1. 分支管理
开发过程主要存在以下分支：
- master
- develop
- release
- hotfix-[问题名称 | bug编号]
- feature-[功能名称]
- bugfix-[bug编号]
- refactor-[重构名称]
1.1 master 主分支
- master主分支 用于部署生产环境的分支,确保master分支稳定性,始终保持稳定的可发布版本
- master 分支一般由release以及hotfix分支合并，任何时间都不能直接修改代码
- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）
1.2 develop 开发分支
- develop开发分支为不稳定版本，但已有的功能必须是完整的
- 始终保持最新完成以及bug修复后的代码
- 原则上不允许直接在develop分支上进行功能开发，必须新建feature分支进行开发
1.3 release分支 预上线分支
- release 为预上线分支，发布提测阶段，会release分支代码为基准提测
- 当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
1.4 hotfix-[问题名称 | bug编号] 紧急热修复分支
- 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，横线后面跟上问题名称或者对应的bug编号，仅仅适用于生产线问题紧急修复！！
- 修复完成，测试通过，合并到master和develop分支上，然后将此分支删除
1.5 feature-[功能名称] 功能开发分支
- 从develop分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
- 开发完成以后，在远程发起向develop分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支
- 命名规则: feature-user_module、 feature-cart_module
1.6 bugfix-[bug编号] 问题修复分支
- 从develop分支创建，用于修改测试提出的bug，横线后跟bug编号
- 修复以后，在远程发起向develop分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支
1.7 refactor-[重构名称] 重构分支
- 从develop分支创建，用于代码的重大规模重构（小规模重构创建feature分支即可）
- 重构以后，必须经过严格测试通过，才能向develop分支合并。
常见任务
增加新功能
1
2
3
4
5
| (develop)$: git checkout -b feature/xxx
(feature/xxx)$: blabla
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(develop)$: git merge feature/xxx --no-ff
|
修复紧急bug
1
2
3
4
5
6
| (master)$: git checkout -b hotfix/xxx
(hotfix/xxx)$: blabla
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff
(develop)$: git merge hotfix/xxx --no-ff
|
预发布环境代码
1
| (release)$: git merge develop --no-ff
|
生产环境上线
1
2
| (master)$: git merge release --no-ff
(master)$: git tag -a v0.1 -m '部署包版本名'
|
2. Commit 提交规范
2.1 commit提交的日志格式
:
