解读

在国内 CouchDB 岗位的面试中，面试官问“如何提交 PR？”并不是想听你背 Git 命令，而是想确认你是否真正参与过开源或企业级协作流程，是否理解 Apache 基金会（CouchDB 归属 Apache）对 PR 的合规性、许可证、社区礼仪要求，以及能否在国内网络环境下高效完成代码贡献。回答时要体现“流程+工具+规范+沟通”四要素，并突出CLA 签署、issue 关联、commit message 格式、CI 通过、review 响应五个关键检查点。

知识点

1. Apache 基金会贡献协议：**ICLA（Individual Contributor License Agreement）**必须在线签署，否则 PR 会被 apache-bot 自动拒绝。
2. 分支模型：CouchDB 主仓库采用 “main + 版本分支” 模型，所有新功能 rebase 到 main，bugfix 需判断是否能 cherry-pick 到旧版本分支。
3. 提交格式：commit message 必须带 “COUCHDB-XXXX” 前缀，与 JIRA 编号严格一致，否则会被要求 amend。
4. 国内镜像：由于 GitHub 裸连不稳定，国内贡献者通常先用 Gitee 镜像仓库做每日备份，再 push 到 GitHub 提 PR，降低因网络中断导致的重复 CI 触发。
5. 代码风格：Erlang 源码需通过 elvis 检查，JavaScript 需通过 eslint-config-couchdb，PR 页面会实时回写检查结果，失败即无法合并。
6. Review 礼仪：Apache 社区强调 “-1 必须给出技术理由，+1 必须说明测试场景”，国内开发者常因“只点赞不说明”被社区点名提醒。

答案

我实战中的完整流程如下：
第一步，签署 ICLA：在 https://www.apache.org/licenses/icla.pdf 打印签字后扫描，发送给 secretary@apache.org，等待 apache-bot 把我加入白名单，通常 1–2 个工作日可生效。
第二步，认领 JIRA：在 issues.apache.org 找到标有 “beginner” 且状态为 “Open” 的 ticket，评论 “I’m working on this” 防止重复劳动，管理员会把状态改为 “In Progress”。
第三步，本地开发：

• fork apache/couchdb 到个人 GitHub 空间；
• 克隆到本地，**配置 git remote add upstream https://github.com/apache/couchdb.git**，保证后续 rebase 官方主干；
• 新建功能分支，命名规范 feature/COUCHDB-XXXX-brief-desc，例如 feature/COUCHDB-4321-fix-mango-text-index；
• 编码完成后，先 make check 跑完全量测试，再执行 ./dev/run -a 做集成测试，确保 Erlang、Elixir、JavaScript 三端无回归。
  第四步，提交 PR：
• commit message 模板：
  COUCHDB-4321 Fix text index analyzer for Chinese tokenizer
  • 使用 jieba 分词库替代默认 whitespace analyzer
  • 新增 test case: mango_tests_chn.erl
  • 已通过 elvis & eslint 检查
• push 到个人仓库后，在 GitHub 创建 PR，标题必须与 commit message 首行一致，正文填写 “Fixes COUCHDB-4321”，这样 JIRA 会自动关联。
  第五步，持续集成：等待 GitHub Actions 与 Jenkins 双通道绿灯，如遇网络抖动导致 job 失败，可在 PR 评论 “Jenkins retest this please” 重新触发。
  第六步，响应 review：维护者通常会要求补充测试或文档，我习惯在 24 小时内回复，每个 review 点单独回复“Done”并给出 commit hash，保持线程整洁。
  第七步，合并：当至少一名 PMC 成员给出 “+1 with merge flag”，且 CI 全部通过，仓库的 asf-git 机器人会自动 rebase 合并，PR 状态变为 “merged” 后，对应的 JIRA ticket 会自动关闭。

拓展思考

1. 国内公司内网无法直接访问 GitHub，可先在 Gitee 建立组织内部镜像，通过 Jenkinsfile 定义双 push 策略：代码 review 通过后同时同步到 GitHub，实现“内网评审 + 官方贡献”两不误。
2. 若 PR 涉及二进制文件或大体积测试数据，应使用 Git LFS 并提前在 dev@ mailing list 声明，否则会被拒绝合并；国内用户可搭配阿里云 LFS 加速，减少 80% 上传时间。
3. 当功能破坏性较大时，先发 “DISCUSS” 邮件到 dev 列表，征求社区意见，避免直接提 PR 被 -1 打回；邮件标题格式为 “[DISCUSS] Drop support for Erlang/OTP 22”，正文给出兼容性数据与迁移指南。
4. 面试加分项：主动提到曾为中文文档提交 PR，例如修复 “replication” 章节笔误，并附上 CNCF 翻译平台链接，可体现你对国内开发者生态的额外贡献。