前端开发规范指南

分支管理规范

主代码分支 custom-zjrc
发布代码分支 release-{版本号}

1. 每个版本开发功能，基于最新的主分支，创建 feat/{版本号}分支，如 feat/1.10。
2. 可以在 feat 分支上直接提交内容，如果当前开发的功能内容较多且会影响别人，则需要基于 feat 分支创建功能点分支 feat/{版本号}-{功能名字/禅道 ID}，如 feat/1.10-sofams 或 feat/1.10-zentao-666。
3. feat 分支需要保证每次提交的内容都是可以运行、打包的，不会影响其他人使用、部署、测试、联调。
4. 在功能点分支开发、联调且自测完成后，提 PR 到 feat/{版本号}分支。同样 feat 分支会在相关时间点提 PR 到主分支。
5. 提测后，bug 修复若改动较少可以直接在 feat 分支提交，若改动较大，则在 fix 分支（fix/{禅道 ID}例如 fix/zentao-777）提交后再提 PR。测试完成后，feat 分支会合并至主分支，同时主分支会创建对应的 release 分支。
6. 版本发布后，若还有问题要提交，则基于 release 分支创建 hotfix 分支，如 hotfix/zentao-888，测试通过后提 PR 到 release 分支，合并后需将 release 分支再次提 PR 到主分支。
7. 若遇特殊情况，下一迭代已经开始，前一迭代尚未结束，则扔需在主分支切新 feat 分支开发。版本发布后，rebase 主分支。

功能开发并自测通过后

• 自走查一遍后提 PR，并提交 code review
• 将对应的冒烟用例执行完毕后（在测试环境），提交测试

代码提交规范

Git Commit

当前每次 git commit 需要满足以下格式：

<类型>: <主题或禅道 ID>

说明

• feat: 新增功能
• fix: 修复bug
• 主题(Subject)要简明扼要的说明，如果有禅道 ID，则只需要写禅道 ID
• 禅道 ID 需要区分是任务还是 bug，对应 feat 还是 fix

示例

feat: 特别牛牪犇的功能
feat: zentao-1111
fix: zentao-1000

提 PR 说明

提 PR 需要保证已经 rebase 或 merge 过最新的目标分支。

提 PR 有两个选项， 是否压缩提交 和 是否删除源分支

• feat 合并至 feat，不压缩、删源
• feat 合并至 主分支，压缩、删源
• X 合并至 release 分支，不压缩、删源
• release 合并至 主分支，不压缩、不删源
• 不同仓库（例如内外网）之间的同步分支合并到主分支，不压缩、不删源
• 其他情况，压缩、删源