关于引擎的研发协作流程

代码风格

引擎项目配置了 eslint 和 stylelint，在每次 git commit 前都会检查代码风格，假如有报错，请修改后再提交。（严禁 -n 提交）

测试机制

每次提交代码前，务必本地跑一次单元测试，通过后再提交 MR。

假如涉及新的功能，需要补充相应的单元测试，目前引擎核心模块的单测覆盖率都在 80%+，假如降低了覆盖率，将会不予以通过。

跑单测流程：

  1. 项目根目录下执行 npm run build

  2. 只改了一个包，比如 designer，则在 designer 目录下，执行 npm test

  3. （or）改了多个包，则在根目录下执行 tnpm test

commit 风格

几点要求：

  1. commit message 格式遵循 ConvensionalCommits
    关于引擎的研发协作流程 - 图1
  2. 请按照一个 bugfix / feature 对应一个 commit，假如不是，请 rebase 后再提交 MR，不要一堆无用的、试验性的 commit

好处：从引擎的整体 commit 历史来看，会很清晰，每**个 commit 完成一件确定的事，changelog 也能自动生成。**另外，假如因为某个 commit 导致了 bug，也很容易通过 rebase drop 等方式快速修复。

发布机制

日常迭代先从 develop 拉分支 feat/whatever，然后自测、单测通过后，提交 MR 到 develop 分支，由发布负责人基于 develop 拉 release/1.0.z 分支~

分支用途：

  • main 分支，最稳定的分支，跟 npm latest 包的内容保持一致

  • develop 分支，开发分支，拥有最新的、已经验证过的 feature / bugfix，Pull Request 的目标合入分支

  • release 分支，发布分支，一般从 develop 拉出来进行发布，可以发布 npm beta 包，紧急发布可以直接从 main 拉分支做 hotfix

发布周期暂时不固定，按需发布~