摘要
本文主要讲解Git 提交需遵循相应规范。Pull Request 方面，一个 PR 专注一件事。信息填写中，Title 分仅含一个 commit 和多个 commit 的情况；Content 也有要求。还有其它规范，如连接 issue，pr 完成后要妥善处理，以保证代码提交的高效与规范。
开发统一使用git进行版本管理，使用git submodule实现代码模块化。在使用git进行提交和push等操作时需要遵循以下规范。
一、提交规范
-
禁止提交到master分支、develop分支和其他稳定版本分支。
-
一个独立的操作应该checkout为一个独立的分支，避免在一个分支里进行不相关的操作。
-
提交信息要简明扼要，描述清楚操作内容。
提交信息模版:
<操作>(模块): <提交说明>
<详细说明>
其中, <操作>,模块,提交说明为必填且要描述清楚本次提交的目的。
错误示例:
fix(设备管理): 修复bug
正确示例:
fix(设备管理): 修复设备上线状态未同步的问题
操作必须为以下选项:
| 操作 | 含义 |
| feat | 新的功能 |
| fix | 修复bug |
| docs | 文档相关 |
| style | 代码格式调整 |
| refactor | 代码重构,非bug修复或新的功能。 |
| perf | 性能优化 |
| test | 测试相关 |
| build | 构建相关 |
| ci | CI相关 |
| chore | 无关紧要的变更 |
| revert | 回退提交 |
使用Idea时,建议安装 Git Commit Template
https://plugins.jetbrains.com/plugin/9861-git-commit-template 插件。在提交时:
也可以下载通灵义码：然后再提交代码的时候只需要动动手指，也能生成符合要求的git信息
二、Pull Request规范
2.1 概述
pull request（以下用pr代称） 需要严格遵循以下原则：
-
一个 pr 只围绕一件事
-
信息填写规范
-
其它规范
-
pr完成后处理
2.2 一个PR只围绕一件事
一个 pr 应该只负责一件事，这遵循设计模式中的单一职责原则
如何定义一件事：
-
处理了一个 issue
-
解决了一个bug
-
新增了一个组件或功能
-
重构代码实现了某一个目的
一个 pr 可以包含多个 commit，但要注意尺度，保证 pr 不要过大
2.3 信息填写
2.3.1 Title
1.Pr 仅包含一个 commit
直接使用 Github 默认填写的信息，即 Title 为 commit msg 的 subject 部分，Content 为 commit msg 的 body 部分
2.Pr 包含多个 commit
描述清楚这个 Pr 所做的事情，格式：[名词]+动词+名词+[形容词]+[名词]
例如：
-
修复 Collapse 组件无法展开的问题
-
Collapse 组件添加 top 属性
-
新增 Message 组件
-
删除 Message 组件 color 属性
-
修改 Message 组件 top 属性单位为 rpx
注意英文单词左右添加一个空格方便阅读
动词建议从下列选项中选取：
-
新增（组件、属性、API）
-
修改
-
修正
-
删除
2.3.2 Content
如果 title 已经描述清楚了此次 pr 的目的，则 Content 可以留空，否则应该对此次 pr 进行详细的描述.
2.4 其它规范
连接 issue
如果这个 pr 解决了某个 issue 提出的 bug 或者 feature，则应在 pr 中将此 issue 关联起来
在 pr 描述中 使用如下关键字可将 issue 关联起来：
-
close
-
closes
-
closed
-
fix
-
fixes
-
fixed
-
resolve
-
resolves
-
resolved
示例： close #756
然后在下图中设置关联issue：
关联 issue 的好处：
- 可以在 issue 界面快速跳转到这个 pr，查看修复的情况
- 在该 pr 被合并进 master 分支后，对应 issue 会被自动 close。所以连接了 pr 的 issue 不需要手动 close
pr完成后处理
每一个PR被merged（合并）后，应删除提交的临时分支，避免仓库在处理大量pr后，残留大量分支。
什么问题都可以评论区留言，看见都会回复的
如果你觉得本篇文章对你有所帮助的，把“文章有帮助的”打在评论区
多多支持吧！！！
点赞加藏评论，是对小编莫大的肯定。抱拳了！
