KnowForge/Apache Thrift 简体中文

如何贡献

师成师成· 更新于 2026-09-28· 阅读 11 分钟· 0 次阅读
登录后可跨设备保存划线和私人笔记登录

如何参与贡献

感谢您有兴趣为 Apache Thrift 项目做出贡献！关于为什么贡献以及如何贡献的信息，请参阅 Apache 软件基金会（ASF）网站。特别是，我们建议您通过以下链接了解 Apache 的贡献方式：

GitHub pull requests

这是提交更改的首选方式。当您通过 GitHub 提交 pull request 时，会触发 Appveyor 和 Travis 上的持续集成（CI）构建系统，在多种 Linux 和 Windows 配置上构建您的变更并运行所有测试套件。请遵循以下要求以确保 pull request 顺利通过：

  1. 所有重要变更都需要一个 Apache Jira THRIFT Issue 工单。诸如修正错别字或编译器警告之类的琐碎变更则不需要。

  2. 所有 pull request 应针对每个问题只包含一个提交，否则我们会要求您将其压缩（squash）。

  3. 如果 pull request 有对应的工单，其标题必须以 Jira THRIFT 工单标识符开头，例如：

    THRIFT-9999: 示例 pull request 标题

  4. 代码变更的提交信息必须遵循以下格式（偏离该格式的提交不会被合并）：

    THRIFT-9999: [summary of fix, one line if possible]
Client: [language(s) affected, comma separated, for example: "cpp,erl,perl"]

操作步骤：

  1. 在你的 GitHub 账户中 fork 一份 http://github.com/apache/thrift

  2. 将你 fork 的仓库克隆到你的开发环境中。

  3. 为你的修改创建一个分支（最佳实践是使用 issue 编号作为分支名，例如 THRIFT-9999）。

  4. 修改源码以加入改进/缺陷修复，并且：

    • 请记住为所有提交的更改提供测试！
    • 使用测试驱动开发（TDD）：在应用修复该缺陷的更改之前，先添加一个能够复现该缺陷的测试。
    • 确认你遵循了 Thrift 编码规范（你可以运行 make style，它可以确保某些语言的格式正确）。
    • [可选] 通过向 Travis CI 和 AppVeyor 添加 GitHub 服务钩子，验证你的更改在其他平台上也能正常工作。你可以利用这种方法在你自己的账户中运行 Thrift 的 CI 任务，从而在更改公开之前先行检查。每一个进入 Thrift 的 GitHub 拉取请求都会对你的更改运行完整的 CI 构建和测试套件。

  5. 将你的更改压缩（squash）为单个提交，以保持整洁的变更历史。

  6. 将更改提交并推送到你的分支（请使用 issue 编号和描述作为提交标题，例如 “THRIFT-9999: make it perfect”，并在描述的下一行注明受影响的语言）。

  7. 使用 GitHub 创建一个从你的分支指向 apache:master 的拉取请求。请确保 Jira 工单编号位于拉取请求标题的开头，与提交标题保持一致。

  8. 等待其他贡献者或提交者（committer）评审你的新增内容，并等待 CI 构建完成。

  9. 等待提交者提交你的补丁。如有必要，你可以向 Apache Thrift 邮件列表 发送邮件来提醒提交者。

如果你想在本地构建项目

关于 Windows 系统，请参阅 CMake README 中的详细说明。

关于 Windows 原生 C++ 构建，请参阅 WinCPP README 中的详细说明。

关于 Unix 系统，请参阅 Docker README 中的详细说明。

如果你想评审尚未处理的 issue……

  1. 评审 GitHub 拉取请求积压列表。代码评审对所有人开放。
  2. 评审 Jira issue 跟踪器。你可以搜索与你感兴趣或正在使用 Thrift 的语言相关的工单，例如使用 Jira 搜索（Issues -> Search For Issues）查询 project = THRIFT AND component in ("Erlang - Library") and status not in (resolved, closed)，即可找出所有未解决的 Erlang 库相关 issue。

如果你发现了一个缺陷……

  1. 先检查该问题是否已存在于 Jira 问题跟踪器 中。
  2. 如果没有，请在 Jira 问题跟踪器中创建一个工单，描述你所提议的变更。
  3. 通过 GitHub pull request 方式贡献你的代码变更：

通过补丁贡献

要从本地目录中的更改创建补丁：

git diff > ../THRIFT-NNNN.patch

然后等待贡献者或提交者（committer）审查你的更改，并等待某位提交者应用你的补丁。这不是提交更改的首选方式，而且会给提交者带来额外的工作量，因为他们必须替你创建拉取请求。

关于拉取请求的 GitHub 操作指南

有时提交者可能会要求你在拉取请求中执行某些操作。以下是一些帮助你完成这些要求的示例。这些示例假设你正在处理 Jira 问题 THRIFT-9999。你还应该熟悉上游（upstream）仓库的概念。

压缩你的更改

如果你还没有提交拉取请求，或者你还没有对现有的拉取请求进行变基（rebase），那么你可以把所有提交压缩成一个提交。这能让提交者的工作更轻松。如果你在 GitHub 上的拉取请求包含多个提交，你就应该这样做。

  1. 使用命令 git log 确定你从开始以来做了多少次提交。
  2. 使用命令 git rebase -i HEAD~N，其中 N 是提交的数量。
  3. 在第一行保留 “pull”。
  4. 将其他所有行从 “pull” 改为 “fixup”。
  5. 这样你的所有更改就都在一个提交中了。

如果你已经有一个待处理的拉取请求，由于你更改了提交历史，你需要进行“强制推送（force push）”来覆盖它：

git push -u origin THRIFT-9999 --force

关于 squash 的更详细说明可以参见 Git Ready。

对你的拉取请求进行 rebase

如果你的拉取请求与 master 存在冲突，就需要进行 rebase：

git checkout THRIFT-9999
git rebase upstream master
  (resolve any conflicts, make sure it builds)
git push -u origin THRIFT-9999 --force

修复错误的合并

如果您的拉取请求中包含并非由您提交的提交，那么您应当使用以下方法来修复分支中错误的合并：

git checkout master
git pull upstream master
git checkout -b THRIFT-9999-take-2
git cherry-pick ...
    (pick only your commits from your original pull request in ascending chronological order)
squash your changes to a single commit if there is more than one (see above)
git push -u origin THRIFT-9999-take-2:THRIFT-9999

此操作会按顺序将你的提交应用到当前 master 分支上，然后将它们压缩为一个提交，接着将你本地的 THRIFT-9999-take-2 强制推送到远端的 THRIFT-9999（代表你的拉取请求），用这个新提交替换掉所有旧提交。

AI 生成的内容

ASF 生成式工具使用指南是一份很好的总结，同时也概述了使用生成式工具可能带来的问题。出于本文所述的原因，并且为了让评审者一目了然，如果适用，我们强烈建议在提交和拉取请求中使用 Generated-by:（如所链接的 ASF 来源所推荐）或 Co-Authored-By:（被广泛采用的通用惯例，例如此处和此处）声明。

评论

登录后参与评论

正在加载评论…