小张上周在 GitHub 上看到一个自己天天用的工具库，发现文档里有个错别字。他顺手改了，点下「Edit」再提交，结果页面跳出来一堆报错：‘You don’t have permission to push to this repo’。他愣住了——原来，不是点个按钮就能‘贡献代码’的。
开源不是‘随便改，随便发’
真正的开源项目，尤其是活跃项目，都有明确的协作流程。这不是为了设门槛，而是让代码稳定、可追溯、有人负责。就像你去别人家修水管，得先打招呼、问清哪根是进水哪根是出水，不能抄起扳手就拧。
典型流程，四步走实操
第一步：Fork 到自己名下
打开项目主页（比如 https://github.com/axios/axios），右上角点「Fork」。这会在你的 GitHub 账号下生成一个一模一样的副本，比如 https://github.com/yourname/axios。这是你自己的‘施工区’，爱怎么改都行。
第二步：本地克隆 + 新建分支
把你的 Fork 克隆下来，别直接动 main 分支：
git clone https://github.com/yourname/axios.git
cd axios
git checkout -b fix-typo-in-readme分支名别写 ‘my-fix’ 或 ‘update’，用具体动作+目标，比如 fix-typo-in-readme 或 add-error-handling-to-upload，别人一眼看懂你在干啥。
第三步：改代码 + 提交 + 推送到你的远程分支
改完保存，加到暂存区，提交，再推上去：
git add README.md
git commit -m "docs: fix typo in installation section"
git push origin fix-typo-in-readme注意提交信息开头带类型，比如 docs:、fix:、feat:，很多项目靠这个自动归类变更。
第四步：发起 Pull Request（PR）
回到你 GitHub 上的 fork 页面，会看到一个绿色按钮「Compare & pull request」。点进去，填标题（别只写‘fix’）、描述（说明改了什么、为什么改、是否影响其他功能），然后提交。这时，原项目的维护者就会收到通知，审核你的改动。
顺手记两件事
• 大多数项目根目录有 CONTRIBUTING.md，点开它，里面写着他们偏好的格式、测试要求、甚至代码风格——花两分钟读完，能省掉 90% 的来回修改；
• 别急着关 issue。如果你的 PR 是为了解决某个已存在的 issue（比如 #1234），在 PR 描述里写上 Closes #1234，合并后系统会自动关掉那个 issue。
贡献不一定要写代码。修文档、补例子、翻译 README、帮新用户解答问题……这些都在开源协作的‘贡献流程’里，而且往往是新手最容易上手的入口。