技术如何改变医疗行业

体分三行：

• 【标题行】 必填, 描述主要修改类型和内容。
• 【主题内容】 描述为什么修改, 做了什么样的修改, 以及这么做的思路等等。
• 【页脚注释】 放 Breaking Changes 或 Closed Issues

其中 type 是 Commit 的类型，可以有以下取值：

• feat：新特性
• fix：修改 bug
• refactor：代码重构
• docs：文档更新
• style：代码格式修改
• test：测试用例修改
• chore：其他修改, 比如构建流程, 依赖管理

其中 scope 表示的是 Commit 影响的范围，比如 ui，utils，build 等，是一个可选内容。

其中 subject 是 Commit 的概述，body 是 Commit 的具体内容。

例如：
 

如何做好代码 Review

2.1. 第一招：什么时候发起 Review

在代码 Review 上，Author 需要意识到：Reviewer 的时间是昂贵的。因此在正式邀请 Reviewer 发起代码 Review 前，Author 有几项需要注意的点，这些都能提高代码 Review 的效率，节省 Reviewer 的时间。

2.1.1. MR (Merge Request)

也称为 PR（Pull Request）， MR 是我们进行代码 Review 的地方，它记录着代码的具体改动，参与者具体的讨论过程。好的 MR 应该做到以下几点：

• 单一：一个 MR 应该只解决一个单一的问题，无论是修复一个 bug，还是实现一个新 feature。Author 应该避免一个 MR 包含不同意图的代码改动。单一的 MR 能帮助 Reviewer 快速地了解代码改动的动机，能有针对性地进行 Review。
• 短小：MR 应该尽量地小，比如一个 feature 引入了较多的改动，需要考虑是否可以拆成独立的几块实现，分开提 MR，比如接口定义、接口实现、逻辑对接等拆分开。
• 详细: 这里说的详细是指 MR 应该尽可能地详细描述它的背景和动机，可以是在 MR 的描述中详细体现，也可以是连接到具体 issue 或 tapd 单中。需要达到的目的是，其他人翻开一个 MR 能知道当时做这个改动的背景以及动机。

2.1.2. Commit Message

之前翻看了不少现存的项目代码，看到不少的 Commit Message 写得比较简单，例如一连串的 "update", "fix"，从这些 Commit Message 中完全看不出做了什么改动，想想如果之后想要定位之前的某个改动，该从哪里下手。

目前 Commit Message 规范比较常见的有 Angular 团队的规范，并由此衍生出了 Conventional Commits Specification，可以参照此 Specification 约定 Commit Message 格式规范。

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!