一、Git commit message基本规范
对格式的说明如下:
- type代表某次提交的类型,比如是修复一个bug还是增加一个新的feature。所有的type类型如下:
- feat: 新增feature
- fix: 修复bug
- docs: 仅仅修改了文档,比如README, CHANGELOG, CONTRIBUTE等等
- style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
- refactor: 代码重构,没有加新功能或者修复bug
- perf: 优化相关,比如提升性能、体验
- test: 测试用例,包括单元测试、集成测试等
- chore: 改变构建流程、或者增加依赖库、工具等
- revert: 回滚到上一个版本
格式要求:
# 标题行:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 尾部:如果需要的化可以添加一个链接到issue地址或者其它文档,或者关闭某个issue。
二、Git分支与版本发布规范
- 基本原则:master为保护分支,不直接在master上进行代码修改和提交。
- 开发日常需求或者项目时,从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复,功能测试完毕并且项目发布上线后,
将feature分支合并到主干master,并且打Tag发布,最后删除开发分支
。分支命名规范:- 分支版本命名规则:分支类型 _ 分支发布时间 _ 分支功能。比如:feature_20170401_fairy_flower
- 分支类型包括:feature、 bugfix、refactor三种类型,即新功能开发、bug修复和代码重构
- 时间使用年月日进行命名,不足2位补0
- 分支功能命名使用snake case命名法,即下划线命名。
- Tag包括3位版本,前缀使用v。比如v1.2.31。Tag命名规范:
- 新功能开发使用第2位版本号,bug修复使用第3位版本号
- 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号,在版本后面加上后缀,用中划线分隔。alpha或者belta后面加上次数,即第几次alpha:
- v2.0.0-alpha-1
- v2.0.0-belta-1
- 版本正式发布前需要生成changelog文档,然后再发布上线。
三、Gitb版本管理规范
1、基本开发流程:
2、分支命名
2.1主分支
① master :随时可供在生产环境中部署的代码
② dev: 保存当前稳定并且最新的开发分支(多人开发同一分支)
2.2辅助分支
主要用于新功能的并行开发、对生产代码的缺陷进行紧急修复工作。合并 master后应该立即删除
①用于开发新功能时所使用的feature分支
② 用于修正生产代码中的缺陷的bug分支
2.3根据实际开发情况合理命名分支:分支类型_开发者_时间_开发内容
① feature分支:f_yourname_20170416_customLimit
② bug分支:bug_yourname_20170416_customLimit
③ dev分支:dev_yourname_20170416_customLimit
3、git-commit
3.1什么时候commit?
commit在什么时候都可以,但是不建议为了保存代码而commit,每一次commit一定是代表代码开发进行到了某一个阶段,可以在后续开发或者合并代码出现错误的时候可以快速回到这个阶段。
3.2 commit注释
每次提交必须要有提交注释,注释根据本次提交情况,进行简洁描述
3.3 多次提交合并为一次提交(rebase)
① git fetch
② git rebase,rebase的使用方法:
a.更新本地仓库;b.选择origin master;c.commit 合并;d.存在冲突时,必须要解决;e.继续 rebase
4、 Git-push
4.1什么时候push?
① 代码需要提测,并且自己都测试OK了,如果一次性测试通过则可以把master合并到自己的分支,然后push自己的分支,进行提测
② 代码提测了,如果有问题,把问题修改好后,再push自己的分支。
4.2 push流程
- git fetch
- git checkout dev
- git branch -b copy_dev(copy新分支进行合并)
- git merge origin master (存在冲突必须解决)
解决冲突:
a) git reset --HARD HEAD^
b) git lg(查看你的所有提交的历史)
- git checkout dev
- git merge copy_dev
- git branch -d copy_dev
- git push origin dev
5、Git-issue
5.1对需求完全了解后,开发前先整理思路,在git上填写Issues
① 整理思路,快速开发代码
② 方便后续出现线上问题,快速定位
③ 有类似功能开发时,方便别人借鉴,和自己快速回忆
④ 相互学习
5.2 写完Issues后,找有相关开发经验同事评审
5.3 影响范围较大的Issues必须拉上大家一起评审
5.4 issues规范 (别人一看就懂)
① 需求概述
② 难点,解决方案
③ 概要设计
④ 详细设计
6、git-codeReview
6.1 代码开发完毕,自测通过后,提测之前,在git上提merge Requests
① WIP:分支标题
② Issues
6.2 找有相关开发经验人员进行评审
6.3 按照评审人的建议进行修改,修改后自测
7、 Git-merge
7.1 merge流程
① merge之前保证自己的工作区是干净的
② fetch,更新本地仓库
③ 合并master,如果出现merge conflict,找到相关开发人员一起解 决,确保操作正确
④ merge完成后,验证是否成功
7.2 合主干
① 多人在不同分支上开发多个需求,需要同时上线,事先确定各自上线时间
② 别人合主干后,需要再次拉取最新的master进行merge,进行回归测试
③ 上线的代码一定是提测的代码,是完全一模一样,中间如果有过合并代码就要重新提测,早合并代码比较合适
④ merge Request上,需要附带Issue,代码评审人,测试用例