type
status
date
slug
summary
tags
category
icon
password
git merge
git rebase
Git开发规范
Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作。
分支命名
1、master 分支
master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性， master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
2、develop 分支
develop 为开发分支，始终保持最新完成以及bug修复后的代码，一般开发的新功能时，feature分支都是基于develop分支下创建的。
feature 分支
- 开发新功能时，以develop为基础创建feature分支。
- 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module
release分支
release 为预上线分支，发布提测阶段，会release分支代码为基准提测。当有一组feature开发完成，首先会合并到develop分支，进入提测时会创建release分支。如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
hotfix 分支
分支命名: hotfix/ 开头的为修复分支，它的命名规则与feature分支类似。线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支
常见任务
增加新功能
修复紧急bug
测试环境代码
生产环境上线
日志规范
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。
而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的Commit messages可以达到3个重要的目的：
- 加快review的流程
- 帮助我们编写良好的版本发布日志
- 让之后的维护者了解代码里出现特定变化和feature被添加的原因
目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：
Commit messages的基本语法
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
具体格式为:
- type: 本次 commit 的类型，诸如 bugfix docs style 等
- scope: 本次 commit 波及的范围
- subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点：
- 使用祈使句，是不是很熟悉又陌生的一个词
- 首字母不要大写
- 结尾无需添加标点
body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
footer: 描述下与之关联的 issue 或 break change
Type的类别说明：
- feat: 添加新特性
- fix: 修复bug
- docs: 仅仅修改了文档
- style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
- refactor: 代码重构，没有加新功能或者修复bug
- perf: 增加代码进行性能测试
- test: 增加测试用例
- chore: 改变构建流程、或者增加依赖库、工具等
Commit messages格式要求
- 作者:ZhouZhou
- 链接:https://zzzero.site/article/4576ed99-e466-49ce-b55d-a9350654716e
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。