这一篇在干嘛？
Git 允许几十种协作方式，但常用的就三种工作流。这一篇把它们讲透，并给出「向别人的项目贡献代码」的标准动作清单——这在开源世界就是日常。对应《Pro Git》第 5 章。
三种常见工作流
1. 集中式工作流
所有人推拉同一个中央仓库的 main。小团队够用，但人一多，push 冲突频率陡增。
2. 集成管理者工作流（GitHub 的标准姿势）
每个贡献者有自己的公开仓库（fork），项目维护者从各处拉取（pull）贡献：
维护者仓库 ◀── pull ── 你的 fork ── push ── 你的本地一个人（维护者）当唯一网关，历史干净、权限清晰——开源项目几乎都用这个。
3. 司令官与副官工作流
超级大项目（如 Linux 内核）的玩法：司令官只收副官的合并，副官各管一摊收开发者的贡献，多级漏斗。了解即可。
私有团队的分支纪律
即使一个小团队用同一个仓库，也建议遵守：
- main 保持稳定可发布；
- 所有工作在主题分支（feature/fix 分支）上进行；
- 合并前先拉取最新的 main：
git fetch && git rebase origin/main（私有分支可安全 rebase）； - 合并完就删分支。
写好提交信息：别小看这件事
提交信息是给三个月后的你和所有协作者看的。通用格式：
修复登录页在 iOS 输入法弹起时的布局错位
键盘弹起时 window resize 事件未触发重排，导致提交按钮被遮挡。
改为监听 visualViewport resize 并强制重算容器高度。
Fixes #231要点：
- 第一行 ≤ 50 字符，概括这次提交干了什么（祈使句：「修复 xxx」而不是「修复了」）；
- 空一行后写正文：为什么这么改、影响范围；
- 关联 issue（
Fixes #231）。
一条提交 = 一个完整、自洽的改动。别把「改 bug」和「重构」塞进同一条提交。
向开源项目贡献：标准动作
没有 push 权限时（绝大多数情况），流程是：
# 1. 在网页上 fork 项目，得到自己的副本
git clone https://github.com/you/project.git
cd project
# 2. 建主题分支——永远不要直接在 main 上改
git checkout -b fix-readme-typo
# 3. 改代码，多次小提交，写清楚每条提交说明
git commit -a -m "docs: fix typo in README installation section"
# 4. 推送到你的 fork，然后在 GitHub 上发起 Pull Request
git push -u origin fix-readme-typo之后等维护者评审：可能被要求修改——继续在你的分支上提交并 push，PR 会自动更新。
大项目 PR 的隐藏约定
- 提交前跑一遍项目自带的测试与 lint；
- 遵循项目的 CONTRIBUTING.md；
- 如果评审周期较长，rebase 到最新 main 再强推自己的 fork 分支（这是你的私有分支，rebase 合法）。
维护者视角：怎么收别人的贡献
- 邮件补丁流（Linux 内核等）：贡献者用
git format-patch生成补丁，维护者用git am应用。 - 远程拉取流（GitHub）：维护者
git remote add contributor <对方 fork 地址>，git fetch后审查git diff main...contributor/branch，认可则 merge。 - 拿不准的大改动：先用主题分支收着，测试通过再并进 main。
小结
- 三种工作流：集中式（小团队）、集成管理者（开源标配）、司令官（超大型）。
- 私有协作纪律：main 稳定、主题分支开发、合并前 rebase 到最新。
- 提交信息 = 标题行 + 空行 + 为什么；一条提交一件事。
- 开源贡献五步：fork → clone → 分支 → 提交推送 → 发 PR。
学完你会得到：
- 按团队规模选择工作流的判断力
- 一套可直接抄的提交信息模板
- 向任何开源项目提交 PR 的完整流程
自测
自测
- 集成管理者工作流里，为什么贡献者不能直接 push 到主仓库？
- 为什么「永远在主题分支上干活」？直接在 main 上改会有什么隐患？
- 提交信息第一行有什么格式要求？正文应该写「改了什么」还是「为什么改」？
- PR 评审期间项目 main 前进了，你要怎么更新自己的 PR 分支？
git format-patch和git am配合的是哪种协作场景？