语言运行时嵌入式物联网编译器【免费下载链接】jerryscriptUltra-lightweight JavaScript engine for the Internet of Things.项目地址https://gitcode.com/gh_mirrors/je/jerryscript点击查看免费下载JerryScript 是一款面向物联网与资源受限设备的超轻量 JavaScript 引擎可在不足 64 KB RAM、200 KB Flash 的设备上运行其社区协作对补丁质量与法律合规性有着严格的要求。本文以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内真实的 DCO 说明、CI 检查脚本与测试入口系统讲解向 JerryScript 提交代码的完整流程从补丁拆分、许可证头、DCO 签名、Pull Request 提交到代码评审与补丁被拒后的应对策略帮助开发者一次性通过审查并顺利合入主分支。一、补丁提交流程总览JerryScript 的贡献流程遵循典型的开源协作模式开发者完成开发后通过 GitHub Pull RequestPR公开提交补丁集patch set由社区成员进行代码评审通过后合入 master 分支随后进行验证与测试最终由补丁作者负责该代码在整个生命周期内的维护。流程中有一条硬性规则所有补丁必须公开提交通过 Pull Request。私下发送给 Maintainers维护者或 Committers提交者的补丁将不会被受理。同时作为开源项目请做好收到反馈与批评的准备——这是每个贡献者都会经历的环节。如果被要求返工请保持耐心修改后重新提交。完整流程可以概括为六个步骤缩小补丁范围以最小的合理粒度提交变更保证许可证头合规每个文件都必须携带 Apache License 2.0 头与项目统一的版权声明签署 DCO在每次提交的 commit message 末尾附加JerryScript-DCO-1.0-Signed-off-by签名行提交 Pull Request通过 GitHub 公开提交补丁应对评审反馈补丁被拒是常态依据反馈修改后重新提交接受代码评审所有项目成员都可参与评审最终由 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-license3. 用 DCO 为你的工作签名JerryScript 采用与 Linux 内核相同的 signed-off-by 流程为每一份收到的补丁建立清晰的信任链。签名是补丁 commit message 末尾的一行简单文字证明你编写了该补丁或有权以开源补丁的形式将其提交。签名是补丁被接受的必要条件。签名格式要求使用真实姓名和邮箱JerryScript-DCO-1.0-Signed-off-by: Random J Developer randomdeveloper.example.orgJerryScript-DCO-1.0-Signed-off-by:前缀表示开发者证明其有权将补丁提交并合入项目即同意 Developers 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-actions4. 提交 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钩子开发者可以大幅减少流程性错误把精力集中在代码质量本身——这也是项目通过密集评审保持代码质量与焦点这一核心目标所期待的方式。赞分享语言运行时嵌入式物联网编译器【免费下载链接】jerryscriptUltra-lightweight JavaScript engine for the Internet of Things.项目地址https://gitcode.com/gh_mirrors/je/jerryscript点击查看免费下载相关推荐Vim 贡献指南全解从补丁提交、DCO 签名到 runtime 文件与翻译协作Vim 贡献指南全解从补丁提交、DCO 签名到 runtime 文件与翻译协作 Vim 的官方仓库是一个由全球开发者共同维护的开源文本编辑器项目任何形式的补开发工具代码编辑器Velero 代码规范实战指南从 PR 提交流程、Changelog 到 Go 编码与 DCO 签名的完整贡献规范Velero 代码规范实战指南从 PR 提交流程、Changelog 到 Go 编码与 DCO 签名的完整贡献规范 本篇指南系统讲解 Velero 开源项目的云原生灾备存储后端Velero 代码规范与贡献指南从 PR 提交、changelog 到 DCO 签名的完整实践Velero 代码规范与贡献指南从 PR 提交、changelog 到 DCO 签名的完整实践 VeleroVMware 开源的 Kubernetes 备份云原生灾备存储后端上一篇告别繁琐Notepad--错误报告模板自动生成全攻略轻松搞定问题反馈下一篇solidtime服务器资源监控及时发现时间系统性能瓶颈创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 JerryScript 贡献指南：从补丁提交到 DCO 签名的完整实战流程
语言运行时嵌入式物联网编译器【免费下载链接】jerryscriptUltra-lightweight JavaScript engine for the Internet of Things.项目地址https://gitcode.com/gh_mirrors/je/jerryscript点击查看免费下载JerryScript 是一款面向物联网与资源受限设备的超轻量 JavaScript 引擎可在不足 64 KB RAM、200 KB Flash 的设备上运行其社区协作对补丁质量与法律合规性有着严格的要求。本文以仓库根目录的 CONTRIBUTING.md 为骨架结合仓库内真实的 DCO 说明、CI 检查脚本与测试入口系统讲解向 JerryScript 提交代码的完整流程从补丁拆分、许可证头、DCO 签名、Pull Request 提交到代码评审与补丁被拒后的应对策略帮助开发者一次性通过审查并顺利合入主分支。一、补丁提交流程总览JerryScript 的贡献流程遵循典型的开源协作模式开发者完成开发后通过 GitHub Pull RequestPR公开提交补丁集patch set由社区成员进行代码评审通过后合入 master 分支随后进行验证与测试最终由补丁作者负责该代码在整个生命周期内的维护。流程中有一条硬性规则所有补丁必须公开提交通过 Pull Request。私下发送给 Maintainers维护者或 Committers提交者的补丁将不会被受理。同时作为开源项目请做好收到反馈与批评的准备——这是每个贡献者都会经历的环节。如果被要求返工请保持耐心修改后重新提交。完整流程可以概括为六个步骤缩小补丁范围以最小的合理粒度提交变更保证许可证头合规每个文件都必须携带 Apache License 2.0 头与项目统一的版权声明签署 DCO在每次提交的 commit message 末尾附加JerryScript-DCO-1.0-Signed-off-by签名行提交 Pull Request通过 GitHub 公开提交补丁应对评审反馈补丁被拒是常态依据反馈修改后重新提交接受代码评审所有项目成员都可参与评审最终由 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-license3. 用 DCO 为你的工作签名JerryScript 采用与 Linux 内核相同的 signed-off-by 流程为每一份收到的补丁建立清晰的信任链。签名是补丁 commit message 末尾的一行简单文字证明你编写了该补丁或有权以开源补丁的形式将其提交。签名是补丁被接受的必要条件。签名格式要求使用真实姓名和邮箱JerryScript-DCO-1.0-Signed-off-by: Random J Developer randomdeveloper.example.orgJerryScript-DCO-1.0-Signed-off-by:前缀表示开发者证明其有权将补丁提交并合入项目即同意 Developers 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-actions4. 提交 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钩子开发者可以大幅减少流程性错误把精力集中在代码质量本身——这也是项目通过密集评审保持代码质量与焦点这一核心目标所期待的方式。赞分享语言运行时嵌入式物联网编译器【免费下载链接】jerryscriptUltra-lightweight JavaScript engine for the Internet of Things.项目地址https://gitcode.com/gh_mirrors/je/jerryscript点击查看免费下载相关推荐Vim 贡献指南全解从补丁提交、DCO 签名到 runtime 文件与翻译协作Vim 贡献指南全解从补丁提交、DCO 签名到 runtime 文件与翻译协作 Vim 的官方仓库是一个由全球开发者共同维护的开源文本编辑器项目任何形式的补开发工具代码编辑器Velero 代码规范实战指南从 PR 提交流程、Changelog 到 Go 编码与 DCO 签名的完整贡献规范Velero 代码规范实战指南从 PR 提交流程、Changelog 到 Go 编码与 DCO 签名的完整贡献规范 本篇指南系统讲解 Velero 开源项目的云原生灾备存储后端Velero 代码规范与贡献指南从 PR 提交、changelog 到 DCO 签名的完整实践Velero 代码规范与贡献指南从 PR 提交、changelog 到 DCO 签名的完整实践 VeleroVMware 开源的 Kubernetes 备份云原生灾备存储后端上一篇告别繁琐Notepad--错误报告模板自动生成全攻略轻松搞定问题反馈下一篇solidtime服务器资源监控及时发现时间系统性能瓶颈创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考