贡献

所有贡献者都应遵守 Hummingbot 仓库中使用的代码规范。以下列出了相关准则。

工作流程¶

使用 GitHub 界面复刻仓库，并将其克隆到本地机器。

git clone https://github.com/{user_github_handle}/hummingbot.git

将 Hummingbot 仓库添加为上游远程仓库，并获取上游数据：

git remote add upstream https://github.com/hummingbot/hummingbot.git
git fetch upstream

创建本地分支，需遵循以下命名规范：

基于远程 upstream 的 development 分支，创建并切换到名为 feat/[分支名称] 的新本地分支。

git checkout -b feat/[branch_name] upstream/development

向你的分支提交更改，并确保只进行相关的修改。如果你发现自己在做不相关的更改，请为这些更改创建一个新分支。每个提交前缀如下所示：

提交信息规范：

当你完成修改后，就可以开始将代码合并到主仓库中了。第一步是将上游的变更变基（rebase）到你的分支中。

git pull --rebase upstream development

这将启动变基过程。你必须先提交所有更改才能执行此操作。如果没有冲突，该操作会将你的所有更改重新应用到上游更改之上，从而形成优秀、干净、线性的提交历史。

如果存在冲突的更改，Git 会在变基过程中中途报错并暂停，以便你解决冲突。解决方式与处理合并冲突相同：检查 Git 提示在两个历史记录中都被修改过的文件，并选择你想要保留的版本。请注意，这些更改将出现在你的拉取请求中，因此应尽可能整合上游的更改。

你通过 git add 来标记已解决的文件——在变基过程中不要创建新的提交。

从你的派生仓库和分支向主仓库的开发分支发起一个清晰的拉取请求（pull request），详细说明你所做的具体更改以及该功能将带来什么。拉取请求越清晰，你的更改就能越快被合并进此仓库。

请务必勾选允许维护者编辑选项，以便 Hummingbot 团队在需要时能将 development 分支的更新同步到你的分支。

Creating a pull request

如果开发团队要求修改，你应该在你的分支上继续提交更多更改以响应这些要求，然后从变基开始重复此流程。

当你再次回到这里时，请发表评论请求进一步审查，会有人再次查看你的代码。如果已满足要求，代码将被合并；否则，请重复该流程。

如果你想让你的贡献被评审、合并进官方 Hummingbot 代码库，并包含在持续的月度发布中，你需要获得一个提案的批准。

请按照“提案”页面上的说明，在相应的 Snapshot 子空间中创建新提案。确保你至少拥有 200,000 HBOT 来创建新连接器提案，或拥有 1 HBOT 来创建拉取请求提案。投票期为 7 天，HBOT 持有者将决定是否接受或拒绝你的提案。

一旦 PRP 获得批准，你的代码将由 QA 团队进行测试，若通过所有测试，技术评审 DAO 将对代码进行评审。

修复评审人提出的所有修改意见，解决测试人员发现的问题，并将修复作为一个单独的新提交推送。

一旦拉取请求经过评审并被接受，将由 Hummingbot 开发团队成员将其合并。

注意

测试非常重要。如果你的拉取请求包含新的、可测试的行为，请提交相应的测试。更多信息请参见单元测试覆盖率。

拉取请求中包含的所有更改必须达到至少 80%的单元测试覆盖率。但是，某些组件不在此验证范围内（例如所有 UI 组件）。

要在本地计算机上计算差异覆盖率，请在运行所有测试后执行 make development-diff-cover。

这有助于你组织开发流程。

如果你遵循了所有这些准则并做出了良好的更改，你的代码应该能够顺利合并。