团队规范系列之 git 规范
最近一周的工作重心就是在梳理团队规范,在写的过程也查缺补漏了不少知识,剔除掉关于公司场景的部分就有了这一系列的文章,预计写四部分:
Git 规范
Git 作为现在最流行的分布式管理工具,基本上是每个团队的必备,下面就从分支和提交这两部分展开
什么是分支
分支就是把你的工作从开发主线上分离开来,以免影响开发主线,假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了 50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
分支如何命名
分支按照类型可以分为以下几种
分支名称 | 命名 | 说明 |
---|---|---|
主分支 | master | 主分支,所有提供给用户使用的正式版本,都在这个主分支上发布 |
开发主分支 | develop | 开发分支,永远是功能最新最全的分支 |
功能分支 | feature-* | 新功能分支,某个功能点正在开发阶段 |
发布版本 | release-* | 发布定期要上线的功能 |
修复发布版本分支 | bugfix-release-* | 修复测试 bug |
紧急修复分支 | bugfix-master-* | 紧急修复线上代码的 bug |
开发流程示例
下面就以一个产品从最初到发布上线为例子,讲解 git 流程
初始化
第一步,初始仓库的信息,同时创建develop
分支
开发新功能
开发人员在develop
分支开发新的功能,包括:新特性与 Bug 修复
如果并行开发多个需求,可以创建 feature 分支
,命名规则为feature-分支创建日期-新特性关键字
,例如:feature-20190919-i18n
开发完成之后将 feature 分支合并到 develop 分支,最后删除 feature 分支
什么时候使用 feature
- 开发一个独立的新特性(完成时,需合并到 develop 分支)
- 技术研究与尝试(若失败,可随时删除 feature 分支)
- 提前实现下一个版本需要开发的特性(可不在本次迭代中发布)
准备发布版本
如果 develop 分支上的功开发完毕
- 建 release 分支(发布分支)命名规则:release-分支创建日期-待发布版本号,例如:
release-20190919-v1.0.0
- 对 release 分支的版本号进行修改(之后提交一次)
- 通知测试人员测试
修复问题
开发人员在 release 修复问题,此时禁止开发新功能,只对 bug 进行修复
最终发布
经过测试没有发现问题,或者问题已经全部修复,这个时候
-
将 release 分支同时合并到 master 分支与 develop 分支
- 通知测试,进行主分支测试
- 如果没问题,进行下一步,如果有问题回到 release
-
删除 release 分支
-
构建应用到服务器
commit 规范
目前开源社区主要应用是规范是Angular Git Commit Guidelines
它由下面几部分组成:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
type
本次 commit 的类型,诸如 bugfix、docs、style 等
完整的类型如下:
名称 | 描述 |
---|---|
feat | 添加新特性 |
fix | 修复 bug |
docs | 仅仅修改了文档 |
style | 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑 |
refactor | 代码重构,没有加新功能或者修复 bug |
perf | 增加代码进行性能测试 |
test | 增加测试用例 |
chore | 改变构建流程、或者增加依赖库、工具等 |
scope
本次 commit 波及的范围
subject
简明扼要的阐述下本次 commit 的主旨
有几点需要注意:
- 首字母不要大写
- 结尾无需添加标点
body
主体内容,我们需要把本次 commit 详细的描述一下,比如此次变更的动机等,不能超出 72 个字符
为什么需要
- 它可能是用来修复一个 bug,增加一个 feature,提升性能、可靠性、稳定性等等
- 它如何解决这个问题? 具体描述解决问题的步骤
- 是否存在副作用、风险?
footer
描述下与之关联的 issue 或 break change,在公司项目中基本忽略即可