企业官网建设流程全解析

• 语言运行时
• 嵌入式
• 物联网
• 编译器

JerryScript 是一款面向物联网与资源受限设备的超轻量 JavaScript 引擎（可在不足 64 KB RAM、200 KB Flash 的设备上运行），其社区协作对补丁质量与法律合规性有着严格的要求。本文以仓库根目录的 CONTRIBUTING.md 为骨架，结合仓库内真实的 DCO 说明、CI 检查脚本与测试入口，系统讲解向 JerryScript 提交代码的完整流程：从补丁拆分、许可证头、DCO 签名、Pull Request 提交，到代码评审与补丁被拒后的应对策略，帮助开发者一次性通过审查并顺利合入主分支。

一、补丁提交流程总览

JerryScript 的贡献流程遵循典型的开源协作模式：开发者完成开发后，通过 GitHub Pull Request（PR）公开提交补丁集（patch set），由社区成员进行代码评审，通过后合入 master 分支，随后进行验证与测试，最终由补丁作者负责该代码在整个生命周期内的维护。

流程中有一条硬性规则：所有补丁必须公开提交（通过 Pull Request）。私下发送给 Maintainers（维护者）或 Committers（提交者）的补丁将不会被受理。同时，作为开源项目，请做好收到反馈与批评的准备——这是每个贡献者都会经历的环节。如果被要求返工，请保持耐心，修改后重新提交。

完整流程可以概括为六个步骤：

1. 缩小补丁范围：以最小的合理粒度提交变更；
2. 保证许可证头合规：每个文件都必须携带 Apache License 2.0 头与项目统一的版权声明；
3. 签署 DCO：在每次提交的 commit message 末尾附加JerryScript-DCO-1.0-Signed-off-by签名行；
4. 提交 Pull Request：通过 GitHub 公开提交补丁；
5. 应对评审反馈：补丁被拒是常态，依据反馈修改后重新提交；
6. 接受代码评审：所有项目成员都可参与评审，最终由 Maintainers 与 Committers 决定合入。

1. 缩小补丁范围（Scope the patch）

较小的补丁通常更容易理解和测试，因此请在合理范围内以最小的增量提交变更。小补丁的优势在于：

• 更不容易产生非预期的副作用；
• 一旦出现问题，定位根因对作者和维护者都更轻松；
• 被接受的概率明显更高。

这一原则与 JerryScript 高度模块化的代码结构（jerry-core、jerry-ext、jerry-math、jerry-port等目录严格分层）相契合——变更范围越聚焦，越容易针对单个模块进行独立验证。

2. 保证许可证头与版权声明合规

任何希望贡献给项目的代码必须以 Apache License 2.0 授权，其他许可证的贡献无法被接受。每个文件开头必须包含如下标准头：

/* Copyright JS Foundation and other contributors, http://js.foundation * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */

除项目统一的版权声明（"Copyright JS Foundation and other contributors, http://js.foundation"）外，不允许添加其他版权声明。唯一例外是引入第三方代码且必须保留其版权声明的情况——而向项目引入第三方代码本身通常就需要强有力的理由。

仓库中的自动校验：项目提供了 check-license.py 自动扫描cmake、jerry-core、jerry-ext、jerry-math、jerry-main、jerry-port、targets、tests、tools目录下所有.c、.cpp、.h、.S、.js、.py、.sh、.tcl、.cmake文件，通过正则校验头格式（check-license.py），不符合的文件会被逐一列出并以非零退出码结束。你可以在提交前本地运行该检查：

python tools/run-tests.py --check-license

3. 用 DCO 为你的工作签名

JerryScript 采用与 Linux 内核相同的 signed-off-by 流程，为每一份收到的补丁建立清晰的信任链。签名是补丁 commit message 末尾的一行简单文字，证明你编写了该补丁，或有权以开源补丁的形式将其提交。签名是补丁被接受的必要条件。

签名格式要求使用真实姓名和邮箱：

JerryScript-DCO-1.0-Signed-off-by: Random J Developer random@developer.example.org

JerryScript-DCO-1.0-Signed-off-by:前缀表示开发者证明其有权将补丁提交并合入项目，即同意 Developer's Certificate of Origin（开发者原创证明）。没有正确签名的代码无法合入主线。

DCO 的核心内容（详见 DCO.md）包含四点认证：

• (a)贡献全部或部分由我创作，我有权依据文件所示的开源许可证提交；
• (b)贡献基于此前已知在适当开源许可证下的工作，我有权在该许可证下（除非被允许使用不同许可证）提交带修改的工作；
• (c)贡献由其他已认证 (a)、(b) 或 (c) 的人直接提供给我，且我未做修改；
• (d)我理解并同意本项目与贡献是公开的，贡献记录（包括我提交的所有个人信息与签名）将被无限期保存，并可在同一开源许可证下重新分发。

仓库中的自动校验：项目提供了 check-signed-off.sh 脚本，其校验逻辑非常严格：

• 严格模式（默认）：取最新提交（merge commit 时取第二个父提交），提取 commit message 去掉空行后的最后一行，必须与JerryScript-DCO-1.0-Signed-off-by: <作者名> <作者邮箱>完全一致，其中作者名与邮箱必须匹配git记录的提交作者（check-signed-off.sh）；
• 宽容模式（--tolerant）：只检查最后一行以JerryScript-DCO-1.0-Signed-off-by:开头，不校验姓名邮箱与作者一致；
• --gh-actions模式：在 GitHub Actions 环境下，若事件为pull_request则执行严格模式，否则（如 push 事件）自动切换为宽容模式。

运行方式：

# 严格检查最新提交的签名 bash tools/check-signed-off.sh # 或通过统一测试入口 python tools/run-tests.py --check-signed-off python tools/run-tests.py --check-signed-off strict # 显式指定严格模式 python tools/run-tests.py --check-signed-off tolerant # 宽容模式 python tools/run-tests.py --check-signed-off gh-actions

4. 提交 Pull Request

开发完成后，通过 GitHub Pull Request 提交补丁。基本操作建议如下（详见后文"GitHub Pull Request 技巧"）：

• Fork 仓库并在本地克隆；
• 将本地仓库与原始上游仓库建立 remote 连接；
• 为你的修改创建独立分支；
• 频繁拉取上游变更保持同步，以降低提交 PR 时的合并冲突概率。

5. 补丁被拒了怎么办？

补丁被拒在开源社区是常态，原因多种多样，不一定是因为代码质量差。正确的做法是：接受反馈、调整代码、再次尝试。请记住，评审的根本目的是通过密集的代码审查保持代码质量与项目焦点。

同时要理解维护者的处境：Maintainers 和 Committers 通常需要处理大量提交，分配给单个响应的精力有限。如果拒绝原因不明确，请主动向维护者询问更多信息；如果你有充分的技术理由不同意反馈，且认为该理由被忽视了，请在回复中花时间透彻地解释你的依据。

6. 代码评审

代码评审不仅限于 Maintainers 和 Committers，项目所有成员都可以参与。成员可以通过评论分享意见，评审遵循以下原则：

• 讨论代码，绝不讨论代码的作者；
• 尊重并认可他人的贡献、建议与评论；
• 倾听并对不同的意见保持开放；
• 互相帮助。

变更通过 Pull Request 提交，只有 Maintainers 和 Committers 可以批准或拒绝 PR（注意：只有 Maintainers 拥有有约束力的评审分）。评审应在合理时间内完成；Maintainers 和 Committers 应让变更保持开放一段时间（至少 1 个完整工作日），以便他人提供反馈。评审时间随复杂度增加而延长。

二、GitHub Pull Request 实战技巧

为让 PR 提交更顺利，官方建议遵循以下工作流：

• ForkGitHub 仓库并在本地克隆；
• 通过添加 remote 的方式，将本地仓库连接到原始上游仓库；
• 为你的编辑创建分支；
• 经常拉取上游变更保持同步，这样提交 PR 时合并冲突的概率更低。

保持分支与上游同步的核心价值在于：JerryScript 的 CI 会执行大量构建与测试（覆盖不同 profile、工具链与特性开关），越是接近上游最新状态，越能减少"本地通过、CI 失败"的情况。

三、自动化：为每个提交自动添加 DCO 行

在每次 commit message 末尾添加 DCO 行很容易被遗忘。官方提供了一个优雅的自动化方案：在本地仓库的.git/hooks目录中添加prepare commit message hook（提交信息准备钩子），脚本如下：

#!/usr/bin/env python import sys commit_msg_filepath = sys.argv[1] with open(commit_msg_filepath, "r+") as f: content = f.read() f.seek(0, 0) if "Signed-off-by" not in content: f.write("\n\nJerryScript-DCO-1.0-Signed-off-by: <Your Name> <Your Email>\n%s" % content) else: f.write(content)

该钩子的工作原理：git commit时，Git 会调用prepare-commit-msg钩子并将暂存的提交信息文件路径作为第一个参数传入。脚本读取已有内容，若其中不包含Signed-off-by，则在文件开头补写 DCO 签名行（签名后的%s会把原内容接在后面）；若已存在则原样保留。请将<Your Name> <Your Email>替换为你的真实姓名与邮箱。

提示：将脚本保存为.git/hooks/prepare-commit-msg（无扩展名）并赋予可执行权限后即可生效。关于 Git Hooks 的更多机制，可查阅 Git 官方文档中的 "Customizing Git - Git Hooks" 章节。

四、提交前的本地自检清单

CONTRIBUTING.md 只规定了流程，而仓库的工具链为流程提供了可执行的自动化保障。提交 PR 之前，建议在本地依次执行以下检查（docs/00.GETTING-STARTED.md 中有完整说明）：

# 1. DCO 签名检查（必做，无签名无法合入） python tools/run-tests.py --check-signed-off # 2. 许可证头检查 python tools/run-tests.py --check-license # 3. 代码格式检查（见 docs/08.CODING-STANDARDS.md） python tools/run-tests.py --check-format # 4. 运行单元测试与 JS 功能测试 python tools/run-tests.py --unittests python tools/run-tests.py --jerry-tests # 5. 查看全部可用检查项 python tools/run-tests.py --help

其中--check-format依赖clang-format（版本不低于脚本要求的CLANG_FORMAT_MIN_VERSION，见 check-format.py），与 docs/08.CODING-STANDARDS.md 中"两个空格缩进、禁止 Tab、行宽不超过 120 字符、禁止尾随空白"等规范相对应。所有检查均通过后，再提交 Pull Request，可显著降低 CI 失败与来回返工的概率。

五、小结

JerryScript 的贡献流程可以浓缩为三个关键词：小补丁、合规头、DCO 签名。任何补丁都必须以 Apache License 2.0 授权、携带项目统一版权头，并在 commit message 末尾附加与作者姓名邮箱一致的JerryScript-DCO-1.0-Signed-off-by签名；提交必须通过公开的 Pull Request 进行，接受全体成员的评审，最终由 Maintainers 与 Committers 决定合入。借助仓库自带的 check-signed-off.sh、check-license.py 与 run-tests.py 检查工具，以及官方推荐的prepare-commit-msg钩子，开发者可以大幅减少流程性错误，把精力集中在代码质量本身——这也是项目通过"密集评审保持代码质量与焦点"这一核心目标所期待的方式。

• 语言运行时
• 嵌入式
• 物联网
• 编译器