项目规范征求建议

[cutekibry]

项目规范

规范约束并不强制，有疑惑情况下自行决定。

Commit 规范

参照约定式提交 v1.0.0-beta.4 和约定式提交 v1.0.0 的规范。若二者冲突，以 v1.0.0-beta.4 为准。

Header 不超过 50 个字符，Body 不超过 72 个字符。1 个汉字视为 2 个字符。

美术素材更新使用 feat 类型。

不能向 main 分支直接提交 commit。

具体选用 feat、fix、refactor 的区别，可以参照 Git Commit Message 這樣寫會更好，替專案引入規範與範例。

分支命名规范

分支命名遵循 [type]-[yyyymmdd]-[description] 格式。

其中，type 是修改类型，yyyymmdd 是创建分支时的日期，description 是分支简述。

PR 规范

标题必填，说明选填。

由于人手不足，所以允许不经过 Code Review 的代码直接合并 PR 到 main 分支。如果这么做，在合并前请认真检查。

合并到其他分支则需要原分支所有者同意。

版本号规范

版本号遵循 v[major].[minor].[patch] 格式。其中：

• major 表示里程碑更新，如果有重大更新才可能增加。一般地，在游戏上线、游戏退出 Early Access 状态时再加 1。
• minor 表示功能更新，包括视觉上的更新、关卡更新、机制更新等。
• patch 表示补丁更新，仅修复 Bug 而不影响功能。
  • docs、refactor、style 等不视为补丁更新，故不应当更新。
• 当 major 更新时后二者置 0，当 minor 更新时 patch 置 0。

发布规范

应当通过合并 Release-please bot 维护的 Release PR，让 bot 自动发布。

一般在有一定修改后再发布新版本，不需要每次合并一个小 PR 就发布一次。

发布前必须检查版本号是否满足规范。若不满足规范，必须通过下列方式更新版本号。

方法一：使用脚本（推荐）

在 Windows 的 Git bash 或 Linux 的 Bash 环境下，切换到根目录，运行 release.sh：

bash release.sh [major].[minor].[patch]

脚本会自动创建一个用于更改版本号的分支，并打开浏览器进入提交合并该分支到 main 分支的 PR 的页面，确定提交即可。

合并 PR 后 Release-please bot 会自动更新维护的 Release PR 的版本号。

方法二：手动更新

新建一个名为 chore-[date]-release-[major].[minor].[patch] 的分支，仅提交一个空 commit，commit 信息为：

chore: release [major].[minor].[patch]

Release-As: [major].[minor].[patch]

在 Windows 的 Git bash 或 Linux 的 Bash 环境下，你可以输入 Bash 命令：

git commit --allow-empty -m "chore: release [major].[minor].[patch]" -m "Release-As: [major].[minor].[patch]"

提交合并该分支到 main 分支的 PR，合并 PR 后 Release-please bot 会自动更新维护的 Release PR 的版本号。

Issue 规范

暂无。

[cutekibry]

自己随便写的，不合适的可以改

[ligen131]

如果要同步更新 web 端 https://ligen131.github.io/equal_to_p/ 的内容提交时带上 tag 像这样 v1.0.2 即可

后面研究下怎么在 release 里自动附上 actions 构建的文件并同步更新 web 端