这一篇在干嘛？
前一篇讲了协作的「道」，这一篇讲 GitHub 这个平台怎么「用」：个人主页与仓库页各区块是什么、Issue 和 PR 怎么配合、参与别人的项目和运营自己的项目分别怎么做。对应《Pro Git》第 6 章。
账号与 SSH 配置
注册账号后先做两件一劳永逸的事：
- 加 SSH 公钥：Settings → SSH and GPG keys → New SSH key，粘贴
~/.ssh/id_ed25519.pub的内容。之后仓库地址一律用git@github.com:user/repo.git形式，push 不用输密码。 - 配头像和名字：PR 评审里一张头像带来的信任感，远超默认灰色小人。
HTTPS 方式推送则用 Personal Access Token（Settings → Developer settings）代替账号密码。
读懂一个项目页面
- README 区：项目是什么、怎么装、怎么用——你的项目 README 写不好，等于把访客挡在门外。
- Code 页的分支/标签下拉：快速切换到某个分支或版本。
- Issues：bug 报告与功能讨论，相当于项目的问题工单系统。
- Pull requests：待评审的代码贡献。
- Actions：CI/CD 流水线执行记录。
Issue：先聊清楚再动手
发现 bug 或想提功能，第一动作是搜现有 Issue（可能已有人报过），没有再新建。写 Issue 的要点：
- 标题一句话说清现象；正文给出最小复现步骤、期望行为 vs 实际行为；
- 环境信息（操作系统、版本号）贴全；
- GitHub 支持 Markdown 和
@用户名提及，问题报给别人时@一下。
Pull Request：贡献的正式通道
PR 不只是「请求合并代码」，更是一个评审与讨论的对话空间：
- fork → clone → 建主题分支 → 提交 → push（上篇的五步）。
- 在 GitHub 上从你的分支向目标仓库发起 PR：写清楚解决了什么问题、怎么验证的，关联 Issue（
Closes #12）。 - 维护者评审：行内评论、提修改意见。
- 你按意见继续提交 push，PR 自动纳入新提交；全部通过后维护者点合并。
提高 PR 通过率的三件小事
- PR 范围尽量小：一次只解决一个问题；
- 描述里给出测试/截图证明它真的能用；
- 对评审意见就事论事地回应，别带情绪。
管理自己的项目
运营自己的仓库时，几个实用功能：
- 合并方式：Merge commit（保留全部历史）、Squash and merge（把分支上乱七八糟的小提交压成一条）、Rebase and merge（线性并入）。个人项目选 Squash 最省心。
- 分支保护：Settings → Branches 给 main 加保护，禁止直接 push、要求 PR 评审通过——防止手滑搞坏主干。
- 模板：仓库里放
.github/ISSUE_TEMPLATE.md和PULL_REQUEST_TEMPLATE.md，让所有贡献格式统一。 - 通知管理：Watch 分三档——All（全部）、Participating（与我相关的）、Ignore，参与开源多了记得收窄，不然邮箱爆炸。
组织（Organization）
团队协作用组织而不是个人账号：组织下建多个仓库，成员按 Team 分组授权（比如前端团队只管前端仓库），权限三层只读/读写/管理员，账号新进退出只动团队关系，仓库权限自动继承。
小结
- 装机四件套：SSH 公钥、头像、Token、通知策略。
- Issue 先搜索再新建，写清复现步骤与环境。
- PR = 代码 + 对话：小改动、说清验证方式、持续响应评审。
- 自己的项目：Squash 合并、分支保护、Issue/PR 模板。
- 团队协作用 Organization + Team 分层授权。
学完你会得到：
- GitHub 页面各区块的功能地图
- Issue 与 PR 的标准写法
- 一套个人项目/开源项目的运营清单
自测
自测
- HTTPS 推送时用什么替代账号密码？
- 提 Issue 前应该先做什么？为什么？
- Squash and merge 解决的是什么问题？什么场景最受益？
- 为什么 main 分支要开保护？
- Watch 的 Participating 模式会收到哪些通知？