diff options
| author | Eltrac Koalar <hi@guhub.cn> | 2020-05-04 08:14:25 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-05-04 08:14:25 +0800 |
| commit | 82628c555ff5e5fae4bc7f45f52dc4070c9e567b (patch) | |
| tree | 2103b9ed48366d81e4a58b54935cfa9915e08512 /docs | |
| parent | 598b269896290406dac0ec85e1530399c082bc52 (diff) | |
🗂 Docs: Project-management.md
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/project-management.md | 61 |
1 files changed, 61 insertions, 0 deletions
diff --git a/docs/project-management.md b/docs/project-management.md new file mode 100644 index 0000000..78289aa --- /dev/null +++ b/docs/project-management.md @@ -0,0 +1,61 @@ +# 项目管理 + +这篇文档记录一些 Miracles 主题在更新维护过程中一些不成文的习惯,写在文档里当作一种规范。 + +## Commit + +在提交 commit 的时候,需要书写 message,通常来说,Miracles 主题所有的 commit message 都应该按照一下格式书写 + +``` +:emoji: <sign>: <summary> +``` + +这里面提到的几个部分不太好直接理解,以下是对他们的解释 + +- `:emoji:`:就是 emoji 字符,应选用和这个 commit 内容有关的 emoji,但主要是为了美观 +- `<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:重复) + |
