ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Brave browser-laptop 贡献指南:从 Issue 分诊到 Pull Request 合并的完整实战手册

Brave browser-laptop 贡献指南:从 Issue 分诊到 Pull Request 合并的完整实战手册 桌面应用【免费下载链接】browser-laptop[DEPRECATED] Please see https://github.com/brave/brave-browser for the current version of Brave项目地址https://gitcode.com/gh_mirrors/br/browser-laptop点击查看免费下载本篇技术指南基于 BraveMuon 版桌面浏览器开源仓库 browser-laptop 的 CONTRIBUTING.md 编写系统梳理了该项目的社区协作流程如何以非代码方式参与Issue 分诊、文档维护、翻译本地化、如何搭建开发环境并提交合格代码、以及从分支创建、提交信息规范、Pull Request 审核到 Issue 关闭的完整链路。读完本文你将掌握一套可直接套用于该仓库乃至同类开源桌面应用项目的贡献规范与实操命令并理解其测试、风格、质量门禁背后的仓库级实现细节。仓库背景一个以 Muon 为基础的桌面浏览器browser-laptop 是 Brave 早期面向 macOS、Windows、Linux 的桌面浏览器实现基于 MuonBrave 对 Electron 的分叉构建。从 README.md 可以看到该仓库目前已标记为弃用DEPRECATED新版基于 brave-core 的代码位于独立仓库但在当前仓库内贡献流程、测试规范与风格指南仍完整保留可作为了解 Electron 系桌面应用工程化与开源协作模式的参考。仓库的核心工程结构与本文贡献流程相关的部分包括package.json —— 定义npm脚本测试、Lint、Flow、构建与依赖docs/tests.md —— Webdriver / 单元测试编写与运行规范docs/style.md —— Aphrodite 内联样式与 BEM 命名规范docs/translations.md —— 基于 Transifex 的本地化流程test/lib/brave.js —— 测试辅助方法自定义 Webdriver IO 命令所在文件COMMIT_TEMPLATE —— 提交信息模板。如何参与贡献不止写代码这一条路文档明确指出Brave 欢迎各种形式的贡献即使一行代码不写也能产生巨大影响You can make a huge impact without writing a single line of code。参与途径主要有四类1. 帮助分诊TriageIssue最简单易入手的贡献方式是在 Issues 中帮助维护人员整理问题复现验证检查问题是否仍然存在修复完成后 Issue 可能未被及时关闭补充复现步骤若缺少清晰的复现步骤帮助记录并文档化识别重复判断是否为重复 Issue并在对话中分享被重复的原 Issue 链接。2. 更新文档文档的重要性被项目放在很高优先级可改进的方向包括完善 README.md 中的安装与运行说明使其更清晰、更及时补充或更新 Wiki 中的排障Troubleshooting与指纹保护Fingerprinting Protection等专题内容推动文档的多语言化——目前项目文档全部为英文多语言方案仍有待提出。3. 帮助翻译本地化项目的所有文案首先以英语en-US编写再由真人翻译为其他语言。当前许多语言缺失或翻译不完整。完整的入门指引见 docs/translations.md其核心流程为在 Transifex 平台注册账号并加入brave-laptop项目团队在 brave-laptop 翻译项目页点击 Join team可指定自己擅长的语言也可申请项目尚未提供的语言由项目贡献者审批通过后即可开始翻译。从仓库源码看本地化实现方式为字符串以tokenNameValue形式存放在app/extensions/brave/locales/en-US下的.properties文件中camel-case 格式JSX 中通过data-l10n-id属性引用JavaScript 中通过 js/l10n.js 的locale.translation(tokenNameHere)获取翻译值菜单与右键菜单条目还需在 app/locale.js 中登记。翻译文件通常在发布cut a release时统一拉取回仓库。4. 编写代码环境搭建基础说明见 README.mdWindows 用户需参考专门的 Windows 构建指南卡住时可查阅排障 Wiki 页面环境跑通后优先从标记为good first bug的 Issue 入手。起步准备账号、Fork 与代码风格插件在动手改代码前完成三件事注册 GitHub 账号并确保你的问题在 Issues 中已有对应 ticket若不存在则新建提交 ticket 时请包含 Brave 版本、操作系统和复现步骤Fork 仓库到自己的 GitHub 账户为编辑器安装 Standard 风格插件由于项目对 JavaScript 采用 Standard 风格安装对应插件可保证代码风格一致。这一点在 package.json 中有实现层面的呼应——lint脚本正是standard --verbose | snazzy即用 Standard 检查并以 snazzy 输出格式化结果。修改代码分支、提交与质量门禁创建分支与组织提交克隆仓库到本地后新建独立分支建议使用描述性名称例如fix-fullscreen-issue按逻辑单元提交commit in logical units如需整理可在开 PR 前用git rebase -i压缩squash提交提交信息使用 GitHub 自动关闭关键字auto-closing keywords并让正文足够描述性。文档给出了规范示例Add contributing guide This is a first pass at a contributors guide so now people will know how to get pull requests accepted faster. Fix #206仓库中还提供了 COMMIT_TEMPLATE 作为提交信息模板包含Auditors:审核人与Test Plan:测试计划两个占位字段与文档要求的 PR 元信息审核人、测试步骤形成呼应。测试是硬性要求文档强调新功能及大多数 Pull Request 在被接受前必须编写新的测试。例外情况包括尚无测试覆盖的代码区域的微调、纯文本改动、构建配置变更以及因测试套件限制而无法测试的内容。文档给出的本地测试运行方式是在两个独立终端分别执行npm run watch-test # 终端 1持续监听并重建测试 bundle npm test # 终端 2运行测试对应的实现细节在 package.json 中watch-test为cross-env NODE_ENVtest webpack --watch测试模式下的 webpack 监听构建test为cross-env NODE_ENVtest mocha test/**/*Test.js以 mocha 运行 test 目录下所有*Test.js文件。仓库的测试体系详见 docs/tests.md要点包括测试框架为mocha多数 Webdriver 测试基于WebdriverIO Spectron拉起真实浏览器运行测试文件位于顶层test目录文件名以Test.js结尾如 test/navbar-components/urlBarTest.js运行全部测试npm run test仅运行单元测试npm run unittest按名称过滤子集npm run test -- --grep^tabs匹配以 tabs 开头的测试描述调试时可设置BRAVE_TEST_COMMAND_LOGS1开启命令级详细日志或在测试中调用yield this.app.client.debug()暂停执行以便打开 DevTools 检查。测试运行的基础配置见 test/mocha.opts--ui tdd、--timeout 600s、--reporter spec、--check-leaks、--require babel-register、--recursive。单元测试还需要--globals chrome,DOMParser,XMLSerializer见 package.json 的unittest脚本因为测试环境需要模拟浏览器全局对象。Flow 类型检查与风格指南Flow提交前必须确保类型检查通过npm run-script flow。项目鼓励为新增与既有代码补充更多 Flow 类型注解package.json 中flow脚本为flow; test $? -eq 0 -o $? -eq 2风格进行样式改动时必须遵循 docs/style.md 中的规范——项目使用Aphrodite将内联样式与组件同文件存放colocate命名遵循BEM 风格camelCase、块/元素/修饰符分别用block、block__element、block_modifier表达并通过aphrodite/no-important引入以避免全局!important。pre-push 质量门禁从 package.json 可以看出仓库在 git 层还配置了pre-push钩子push 前会自动运行lintStandard 检查与pre-push-tests即npm run unittest可通过环境变量NO_PUSH_TESTS跳过。这意味着提交虽可随意但推送前必须通过 Lint 与单元测试——这是将贡献规范落到自动化的重要实现证据。提交 Pull Request从自检到合并提交前的自我检查清单文档列出了提交 PR 前应确认的事项是否已手动测试新改动是否一次修复多个 Issue若是考虑拆分为多个独立 PR是否包含测试项目同时有单元测试与 Webdriver 测试若涉及设计或布局改动是否有 mock-up 提供改动是否与之一致若改动影响 session会话/状态是否包含测试步骤还应考虑手动测试一次升级场景。每个 Pull Request 应包含的内容描述性标题——会被用于发布说明release notes简短的改动摘要所修复 Issue 的引用修复的测试步骤如适用设计相关改动建议附带截图。审核流程提交 PR 后应按流程为 PR 打上标签并指定审核人reviewers若无相应 GitHub 权限Brave 成员会代为处理。PR 需满足审核人指南Reviewer guideline才会被接受。员工Brave 成员的附加职责将被修复的 Issue 指定到某个milestone通过Assignees字段标记负责人通过Reviewers字段标记至少一名其他员工或贡献者合并前确保 PR 获得批准若存在需要特别测试的内容为 Issue 标记QA/test-plan-specified——尤其是涉及 session store 文件升级的场景必须标记这是给 QA 的明确信号提醒其格外关注遵循 PR 审批流程。关闭 Issue 与持续分诊Issue 关闭规则Issue 应恰好在修复代码落地到 master 时关闭不早不晚为 Issue 添加其发布版本对应的milestone——通常是下一版本若当前版本代码已冻结则为次小版本因重复或无效等原因未修复而关闭的 Issue应移除 milestone 标记后续问题应新建 follow-up Issue而非重开原 Issue除非原 Issue 对应的代码被回滚。分诊工作中的实用技巧无效 bug 应关闭并打上invalid标签或添加评论说明若无权限需要时积极向 Issue 提出索取更多细节为 Issue 添加合适的标签查找重复 Issue 并将其相互链接为包含多个相关 Issue 的工作领域创建跟踪trackingIssue对重要事项加以标注以引起额外注意完善复现步骤测试后若问题模糊评论 Could not reproduce测试开放的 Pull Request例如git fetch origin pull/1234/head:pr-1234 git checkout pr-1234长期积极分诊者可向 bbondy 申请写权限确保 Issue 名称清晰易懂避免 Brave is broken 这类模糊标题首个评论最好包含清晰的问题描述与用户影响强烈建议索取截图、复现步骤与更多信息若发现重复 Issue礼貌告知发起者如何关注父 Issue 的进度若带 milestone 可附 ETA。结合仓库源码的深度解读贡献流程背后的实现支撑CONTRIBUTING.md 描述的规范并非空中楼阁其背后有明确的仓库实现支撑贡献流程环节文档要求仓库实现依据代码风格编辑器安装 Standard 插件package.json 的lint: standard --verbose \| snazzy测试编写新功能必须带测试docs/tests.md、test/mocha.opts、test目录下大量*Test.js文件类型检查npm run-script flow必须通过package.json 的flow脚本与flow-bin依赖推送门禁推送前保持代码可合入package.json 的pre-push钩子lint unittest提交信息使用 auto-closing 关键字与描述性正文COMMIT_TEMPLATEAuditors / Test Plan 占位本地化文案先英文本地化docs/translations.md、js/l10n.js、app/locale.js样式规范遵循风格指南docs/style.mdAphrodite BEM这套规范文档 npm 脚本 git 钩子的组合构成了该仓库可落地的质量保障闭环Standard Lint 保证语法与格式、Flow 保证类型安全、mocha/Webdriver 测试保证行为正确、pre-push 钩子保证坏代码无法轻易推送、PR 审核清单保证设计与会话场景得到人工确认。即使该仓库已被弃用这套流程模式对任何 Electron 系桌面应用项目的协作治理仍有直接的借鉴价值。结语从 Issue 分诊、文档与翻译到分支提交、测试编写、PR 审核与 Issue 关闭browser-laptop 的贡献流程覆盖了一个开源桌面项目的全部协作环节且每个环节都有明确的规范文本与仓库级实现支撑。如果你希望参与同类开源项目本文梳理的规范 → 实现 → 门禁结构可以直接作为参考模板如果你需要深入该仓库docs/tests.md、docs/style.md、docs/translations.md 与 COMMIT_TEMPLATE 是最值得继续研读的四个文件。赞分享桌面应用【免费下载链接】browser-laptop[DEPRECATED] Please see https://github.com/brave/brave-browser for the current version of Brave项目地址https://gitcode.com/gh_mirrors/br/browser-laptop点击查看免费下载相关推荐如何用TagStudio实现标签式文件管理零门槛快速上手指南如何用TagStudio实现标签式文件管理零门槛快速上手指南 照片翻了半天找不到你可能只是缺了标签 五千张照片堆在几个文件夹里想找去年春天那张翻半天也未桌面应用Kubernetes 社区贡献指南从首个 Issue 到 Pull Request 合并的完整实战路径Kubernetes 社区贡献指南从首个 Issue 到 Pull Request 合并的完整实战路径 本文以 Kubernetes 社区官方贡献指南为主体教程文档知识库NautilusTrader 贡献指南从 Issue 到可合入 Pull Request 的完整实战流程NautilusTrader 贡献指南从 Issue 到可合入 Pull Request 的完整实战流程 本篇技术指南完整解析 NautilusTrader金融科技后端上一篇Standard Open Arm从SO-100到SO-101开源机械臂如何实现成本降低30%与性能提升40%下一篇OpenCode技术深度解析开源AI编程助手架构与高级配置指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表