跳到主要内容
版本:1.2.0

贡献流程

贡献workflow

1、fork工程。

2、从 fork 工程的 develop 分支 创建改动分支。

3、提交变更需要遵循 commit规范

4、大改动需要创建一个 Issue 说明本次PR详情,遵循Issue规范

5、创建一个 pull request (PR) 指向 develop 分支,遵循PR规范

具体事项

commit规范

1、email 和 GitHub 的 email 一致

2、commit log 需要保持简练、规范,要求格式如下:

<type>: <description>
  • type 类型:
    • wip - Work in Progress,表示工作正在进行中,尚未完成。
    • release - 用于标识发布版本的提交。
    • feat - Feature,表示引入了新的功能或特性。
    • fix - 修复bug,表示修复了程序中的错误或缺陷。
    • polish - 对代码进行细节的改进和优化,不影响功能。
    • docs - Documentation,表示修改了文档。
    • style - 代码风格的调整,通常不涉及功能修改。
    • refactor - 重构,表示对代码结构进行调整,但不影响功能。
    • perf - Performance,表示性能优化的提交。
    • test - 测试相关的提交,可能是新增测试或者修复测试。
    • workflow - 工作流相关的修改。
    • ci - Continuous Integration,持续集成配置的修改。
    • chore - 一些零碎的任务,不属于上述分类的其他修改。
    • types - 类型定义相关的修改。

Build - 构建过程的修改。

  • description 描述:
    • 总结性描述本次改动

Issue规范

选择合适的Issue类型进行录入:

https://github.com/didi/xiaoju-survey/issues/new/choose

PR规范

🌀NOTE:一个PR不要过大,按照功能拆分成独立PR。

1、提交变更

保持fork的工程代码内容最新

fork工程的分支需要和github主仓库保持一致:

多个commit合并成一个

  • 应保持有效commit数量,merge --squash 仅保留一个commit
  • commit信息应能反映当前 commit 的内容,不能随意描述: 查看 commit规范
git merge --squash feature/xxx --allow-unrelated-histories

git commit -m 'feat: xxxxx'

2、创建PR

指定到主repo的develop分支

PR描述规范

Title: 功能/优化格式:

[Feature]: xxx

bug修复格式:

[Fix]: xxx

Description: 详细列出修改点,若有需要补充截图

改动原因:// 为什么要改

改动内容:// 详细描述改了什么

改动验证:// 怎么验证的

Issue:// issue链接

测试要求

(待补充)

常见问题

签署CLA

在首次向 didi/xiaoju-survey 提交 Pull Request 时,会提示需要签署,以保证你的代码可以被合入。

1、查看 Pull Request 中的 Check 部分,找到 license/cla,并点击右侧 Details,进入 CLA 网站:

2、请阅读协议内容后单击 Sign in with GitHub to agree,页面将跳转回 Pull Request 页面。