blob: af1444a7ba41b9d1a2754861467cf0ac37393a6c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
# 项目管理
这篇文档记录一些 Miracles 主题在更新维护过程中一些不成文的习惯，写在文档里当作一种规范。
## Commit
在提交 commit 的时候，需要书写 message，通常来说，Miracles 主题所有的 commit message 都应该按照一下格式书写
```
:emoji: <sign>: <summary>
```
这里面提到的几个部分不太好直接理解，以下是对他们的解释
- `:emoji:`：就是 emoji 字符，应选用和这个 commit 内容有关的 emoji，但主要是为了美观（以 [gitmoji](https://gitmoji.carloscuesta.me/) 为规范）
- `<sign>`：这个 sign 用来提醒用户这个 commit 更新了什么类型的内容，通常用一下的字符替换
- `Add`：顾名思义，用在添加新内容/功能的 commit 里
- `Perf`：这是 perfect 的缩写，通常用于对现有功能进行优化的 commit 里
- `Del`：即 Delete，表示移除了某些内容
- `Docs`：即 Documents，表示对某些文档进行了修改，不涉及主体代码
- `Update`：用于一些无法被归类的 commit，例如：修改版本号
- `<summary>`：意为总结，就是对更新的内容进行简短的阐述，作为摘要
例子：`📐 Perf: 优化了文章盒子的边距`
这就是一个普通 commit message 的组成，通常只适用于 message 的 header 部分，body 部分是可有可无的，除非你觉得 header 无法完整地表达这次 commit 更新的内容，
就可以在 body 里对这次更新内容进行详细地阐述，没有固定的格式，表述清楚即可。
## 版本号
如果你仔细观察 Miracles 主题的 release 页面，或者是每个版本的更新日志，你会看到它们通常是这样的
```
:emoji: Ver.<version_num> <name>
```
- `:emoji`：就是 emoji 字符，通常选用和这次更新**主题**相关的 emoji
- `<version_num>`：版本号，发行版和开发版的版本号有区别
- 发行版：通常只有发行版才会有正式的版本号，类似`1.5.2`，`1` 增加代表一次超大更新(几乎重写的那种吧)，`5`增加代表一次大更新(增加了许多新功能)，`2`增加代表补丁这样的小更新(通常只有修复和优化)
- 开发版：开发版的版本号通常以`v`开头，之后是日期，如果这一天有多次开发版更新，则用`A-Z`来区分，例如：`v20200503A`、`v20191223B`
- `<name>`：这个版本的名字，一般是根据更新内容和这次更新的主题来命名
> 通常来说，开发版的更新不会写入正式的更新日志（change-log.md）
## issue
Miracles 主题有三个自带的 issue 模板，分别是：
- 问题报告（label：问题）
- 想法建议（label：优化）
- 需要帮助（label：求助）
正常来说，这三个模板能满足大多数人的要求，并且如果他们按照模板书写 issue 会让开发者更方便。
满足以下条件的 issue，会被 close：
- 问题已被完美解决（label：解决）
- 问题根本不存在（label：错误）
- 这个想法没有必要（label：拒绝）
- 存在相同的内容（label：重复）
|
