企业官网建设流程全解析

• 包管理器
• 前端
• 开发工具
• CLI

本篇指南围绕 Bower 前端包管理器的 CONTRIBUTING.md 展开，系统讲解社区参与者如何提交 Bug 报告、发起功能请求、走完 Pull Request 全流程，以及拥有提交权限的维护者如何评审变更、合并代码并发布新版本。读完本文，你将掌握一套可直接落地到本仓库的协作与发布实操流程，并了解其背后的测试脚本与发布工具链。

项目背景与贡献入口

Bower 是一个社区驱动的大型开源项目，参与者分布在各个层面。仓库当前版本为 1.8.14（见 package.json），是一个运行在 Node.js 之上的命令行工具，其命令实现集中在 lib/commands 目录下。如果你准备贡献，建议先通读仓库根目录下的 README.md 了解项目定位与基本用法，再回到本指南核对协作规范。

贡献分两类参与深度：

• 日常参与（Casual Involvement）：改进 bower.io 官网、在 Issue 区评论并推动问题走向解决，无需深入核心代码。
• 高影响参与（High-impact Involvement）：直接维护 Bower 客户端本体，包括阅读架构设计文档、对 Issue 进行分流（Triage）、关闭和修复问题。

无论哪一层级，都应当从熟练使用 Issue 跟踪器开始。

使用 Issue 跟踪器的规范

Issue 跟踪器是提交 Bug 报告、功能请求 和 Pull Request 的首选渠道，但必须遵守以下两条限制：

1. 不要把 Issue 跟踪器当作个人技术支持渠道。常规使用问题请到 Stack Overflow 的 bower 标签下提问，严重问题可通过邮件联系团队（本仓库 SECURITY.md 同样建议将关键安全问题直接发邮件而非开 Issue）。
2. 不要在 Issue 中跑题或引战。保持讨论围绕主题，尊重他人观点。

Bug 报告

Bug 报告是社区最直接的价值输入。虽然 CONTRIBUTING.md 将 Bug 报告的详细格式指引放在 Wiki 中，但结合仓库内 test/commands/bower.js 等测试的写法可以看出，Bower 对可复现性的要求很高：测试通过runBin()直接以子进程方式执行bin/bower并断言标准输出，例如验证运行后输出包含Usage:与Commands:。因此一份高质量 Bug 报告应至少包含：

• 复现命令与环境（Node.js 版本、操作系统、Git 版本）；
• 实际输出与预期输出；
• 是否在干净目录下可稳定复现。

功能请求

功能请求（Feature Request）同样受欢迎，但提交者需要先确认自己的想法符合项目范围与目标。CONTRIBUTING.md 明确要求：由你本人来提供有力论据说服项目开发者认可该功能的优点，并尽量提供详细、完整的上下文。也就是说，功能请求不是一句"希望支持 XX"，而是一份有场景、有收益、有实现思路的提案。

从仓库结构可以推断，Bower 的绝大多数功能都会落到 lib/commands（命令层）与 lib/core（核心逻辑层，如依赖解析的 Manager.js、Project.js）之一。如果你希望功能被快速接受，在提案中说明它将落在哪个模块、是否影响现有命令的readOptions解析，会显著提高评审效率。

Pull Request 提交流程

优秀的 Pull Request——补丁、改进、新功能——对项目是巨大帮助。它们应当范围聚焦，避免包含无关提交。请先询问再着手任何重大 PR（实现新功能、重构代码等），否则你可能花费大量时间做了项目开发者并不想合并的工作。同时请遵循项目一贯的编码规范（缩进、准确的注释等）以及测试覆盖等硬性要求。

CONTRIBUTING.md 给出了 10 步标准化流程，务必逐条执行：

1. Fork 并配置远端：Fork 项目后克隆自己的分支，并将原仓库添加为名为upstream的远端：

   # 克隆你的 fork 到当前目录 git clone https://github.com/<your-username>/bower # 进入新克隆的目录 cd bower # 将原仓库关联为名为 upstream 的远端 git remote add upstream https://github.com/bower/bower

2. 同步上游最新代码（如果克隆有一段时间了）：

   git checkout master git pull upstream master

3. 创建主题分支（基于主开发分支）：

   git checkout -b <topic-branch-name>

4. 补充或更新测试并全部跑通。补丁和功能没有测试不会被接受。修改后运行npm test确认全部通过。仓库在 package.json 中定义的实际测试脚本为：

   # 先跑包清单校验（含 Git 与 SVN 两个来源），再执行 Mocha 全量测试 node test/packages.js && node test/packages-svn.js && mocha --timeout 15000 --reporter spec

   测试基础设施见 test/helpers.js：它提供了TempDir（构造临时目录并支持prepareGit按 tag 提交）、command（按命令名加载并 stub 依赖）、runBin（以子进程执行真实 CLI）等工具，新增测试时复用这些设施即可。

5. 按逻辑块提交，遵循 Git 提交信息规范，并用 Git 的交互式 rebase 在公开前整理提交。

6. 将上游开发分支合入（或 rebase）你的主题分支：

   git pull [--rebase] upstream master

7. 推送到你的 fork：

   git push origin <topic-branch-name>

8. 发起 Pull Request，标题与描述清晰明确。

9. 按要求修订：如果被要求修改后才能合并，使用git commit --amend（多提交 PR 则用 rebase）并强制推送到远端特性分支；也可能被要求 squash 提交。

10. Squash 提交：若被要求压缩提交，执行git rebase -i master，选择保留主要提交、压缩其余提交。

重要声明：提交补丁即表示你同意以项目所用许可证（MIT，见 LICENSE）授权你的工作。

维护者流程

拥有提交权限的维护者，其工作同样有明确流程，覆盖评审、提交与发布三个环节。

评审变更（Reviewing changes）

1. 检查变更是否符合项目范围与理念。
2. 检查变更是否带有必要测试以及规范、有描述性的提交信息。
3. Checkout 该变更并在本地实测。
4. 若变更质量良好且作者没有master提交权限，尽量避免使用 GitHub 的 Merge 按钮：在本地将变更应用到master（必要时可顺手修正作者原提交中的小问题）。
5. 若变更质量良好且由另一位维护者/协作者撰写，给对方一条 "Ship it!" 评论并让对方自行合并。

提交变更（Submitting changes）

1. 所有非平凡的变更都应通过 GitHub Pull Request 提交评审。
2. 变更不得在缺少至少一条来自其他维护者/协作者的 "Ship it!" 评论时合并进master（或其它特性分支）。注意 "Looks good to me" 不等于 "Ship it!"。
3. 尽量避免 GitHub 的 Merge 按钮：在本地将变更 rebase 到master后再推送到 GitHub。
4. 特性分支一旦合并进目标分支，请从远端删除该分支。

发布新版本（Releasing a new version）

发布流程与仓库中的发布工具 publish.js 相互印证，完整步骤如下：

1. 将全部新的功能性变更写入 CHANGELOG.md（该文件当前仅保留 1.8.0 及更早条目，新版本发布时需补充更细条目，详见其首部说明）。
2. 用一条独立提交提升版本号：版本需要同时写入CHANGELOG.md（含日期）与 package.json 的version字段。
3. 该提交信息必须采用v0.0.0格式。
4. 为该版本创建带注释的标签：git tag -m "v0.0.0" v0.0.0。
5. 推送变更与标签到 GitHub：git push --tags origin master。
6. 发布新版本到 npm：npm publish。

需要特别说明的是，Bower 的正式发布并不直接执行npm publish：publish.js 会先校验当前分支必须是master（否则直接退出），然后在临时目录构建生产包、以yarn --production安装依赖，并把node_modules移入lib目录后执行npm pack生成bower-<version>.tgz；最终还需要人工执行npm publish bower-<version>.tgz --tag beta发布预发布版本，再用npm dist-tag add bower@<version> latest将其标记为最新版（见 publish.js）。对应地，package.json 的prepublishOnly脚本会强制开发者使用node publish.js而不是直接npm publish。

小结

Bower 的贡献体系由三个闭环组成：普通参与者通过规范化的 Issue 与聚焦的 PR 贡献代码；维护者通过 "Ship it!" 机制与本地合并保障代码质量；发布者通过带注释标签与专用发布脚本 publish.js 完成版本迭代。无论你处于哪一层级，只要遵循本指南的流程——尤其是"先问再做、测试必过、提交信息规范、变更范围聚焦"这四条铁律——都能高效地参与到这个前端包管理器的演进中来。

• 包管理器
• 前端
• 开发工具
• CLI