跳到主要内容
版本：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 页面。