贡献指南

    kratos 使用 github issue 来管理问题。 如果您希望提交 bug 报告或帮忙修复bug时，请先确保已经搜索过已有的 issues 和 pull requests 并且阅读了我们的 常见问题。

    提交 bug 报告时，请使用我们提供的 issue 模板，清楚地描述遇到的问题和复现方式，如果方便最好是可以提供一个最小复现仓库。

    为了准确的区分用户提出的需求是否是大多数用户的需求或合理需求，通过提案流程，向社区征集意见，社区采纳的提案将作为新功能实现。 提案流程为了尽可能的简单，流程中包含 proposal feature 和 PR 三个阶段，其中 proposal feature 为 issue，PR 为具体的功能实现。为了方便社区正确的理解提案的需求，proposal issue 中需要详细的描述功能的需求，和相关的参考资料或文献。当大多数社区用户赞同这个提案时，将会创建一个 feature issue 关联 proposal issue，feature issue 中 需要详细的描述功能的实现方式，以及功能演示，作为最后功能实现的参考，当功能实现完毕后，将会发起合并请求关联 proposal issue 和 feature issue，合并完成后，关闭所有 issue。

    • 首先请 fork 项目到自己的 github 账户中
    • 然后基于 main 分支 创建一个新的功能分支，并以功能命名如 feature-log
    • 编写代码
    • 提交代码到远端分支
    • 在 github 中提交 PR 请求
    • 等待 review 后合并到 main 分支

    注意在您提交 PR 请求时首先保证代码使用了正确的编码规范，并有完整的测试用例，提交 PR 的信息中最好关联相关的 issue，以减轻审核人员的工作负担。

    遵循 来规范化 commit message

    提交的 commit 类型主要有以下几种

    主要类型

    • fix 修复 bug
    • feat 新增功能
    • deps 依赖修改
    • break 不兼容修改

    其他类型

    • docs 文档修改
    • refactor 重构
    • test 测试用例
    • chore 日常工作，如文档修改，示例等
    • ci 构建脚本

    scope

    • transport
    • examples
    • middleware
    • config
    • cmd
    • etc.

    description

    用简短的话语清晰的描述提交的代码做了什么事

    补充说明，用于描述原因、目的、实现逻辑等可以省略

    • 当存在不兼容(breaking change)更新时，需要描述原因以及影响范围
    • 关联相关的 issue，如 Refs #133
    • 可能涉及到的文档更新和其他模块的更新的 PR 关联

    examples

    需要引起关注

    包含全部结构

    release 时可以使用 命令生成 release 说明，工具会筛选出来从上一次 release 到现在的所有提交信息，然后根据提交的分类不同，主要汇总成以下几类

    • Breaking Change
    • Dependencies
    • Ohters