类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
小团队经常认为 Pull Request 只是大公司流程，自己直接推 main 更快。短期看确实省事，长期看却容易出现问题：谁改了关键配置没人知道，临时修复没有测试记录，多个改动混在一起无法回滚。一个轻量但清晰的 GitHub Pull Request 流程，可以在不明显增加负担的情况下减少合并事故。
一、PR不是只看代码差异
一个合格 PR 至少要回答四个问题：为什么改、改了什么、怎么验证、有什么风险。代码 diff 只能说明文件变化，不能说明背景。如果维护者半年后回看，只看到一堆提交，很难判断当时的决策原因。
PR 描述不用写成长报告，但要包含关键信息。比如修复登录失败，就写清触发场景、影响范围、验证方式。新增配置项，就说明默认值、兼容性和回滚办法。说明越清楚，Review 越有效。
二、控制PR大小比增加审查人更重要
很多审查低效，不是因为人少，而是 PR 太大。一次改几十个文件，包含重构、功能、样式和依赖升级，审查者很难判断重点。小团队更适合小步提交：一个 PR 只解决一个目标，相关但不必要的整理放到后续。
如果必须做大改动，可以先提交准备性 PR，例如目录调整或类型补充，再提交功能 PR。这样每次审查的认知负担更低，合并风险也更可控。
三、Review时优先看影响面
审查不必纠结所有风格细节。更重要的是看这次改动会影响哪些用户、哪些接口、哪些部署流程。配置文件、认证逻辑、数据库脚本、构建流程、支付或下载入口，优先级通常高于普通样式调整。
对文档和教程仓库，Review 重点则是命令是否可运行、版本是否准确、截图是否对应当前界面、链接是否有效。不同项目的审查重点应不同，不要用同一套清单套所有 PR。
四、合并策略怎么选
GitHub 常见合并方式有：
- merge commit
- squash merge
- rebase merge
小团队如果希望 main 历史干净，常用 squash merge，把一个 PR 压成一个提交。这样回滚时也更容易按 PR 粒度处理。
如果项目强调保留完整提交历史，可以使用 merge commit。rebase merge 历史线性，但对不熟悉 Git 的成员不一定友好。选择哪种方式不重要，重要的是团队统一，不要今天 squash，明天随意 merge。
五、冲突处理不要拖到最后
PR 开久了，main 分支不断变化，冲突概率会增加。开发时间较长的分支，应定期同步 main。冲突处理后，最好重新跑测试，因为冲突解决本身可能引入问题。
如果冲突集中在同一文件，说明多人正在改同一块逻辑。此时比起各自硬合并，更需要先沟通边界，确认谁负责哪部分。Git 能合并文本，不代表业务逻辑一定正确。
六、必要时使用草稿PR
GitHub Draft PR 适合提前展示方向，但暂不请求正式审查。比如重构进行到一半、接口方案需要讨论、想让同事先看结构，都可以用 Draft PR。等功能和测试基本完成，再标记为 Ready for review。
这样可以避免“半成品被误合并”，也能让协作更早发生。对小团队来说，Draft PR 是很好的沟通工具，不必等所有代码写完才暴露问题。
七、合并前的最小检查
小团队可以设一个简单规则：PR 描述完整，至少一人 Review，关键测试通过，冲突已解决，风险点已说明。涉及生产配置、部署脚本、权限和密钥的改动，应由更熟悉该模块的人审查。
这个规则不复杂，但能过滤大部分低级事故。不要把流程做成形式，也不要完全依赖个人记忆。好的 PR 流程，是让重要信息在合并前自然出现。
八、合并后的回看价值
PR 合并后，它会成为项目历史的一部分。后续出现问题时，维护者可以从 PR 找到讨论、测试记录和决策背景。相比直接提交，PR 能把协作过程保存下来。
对站长、小型开发团队和开源项目来说，Pull Request 流程不是负担，而是一种低成本留痕方式。只要控制大小、写清说明、统一合并策略，就能让代码协作稳定很多。
九、PR模板可以降低沟通成本
小团队不需要复杂流程，但可以准备一个简短 PR 模板。模板里放“变更内容、验证方式、风险点、关联 Issue”四项就够了。这样每次创建 PR 时，提交者会自然补全关键信息，审查者也知道从哪里看起。
模板不要写得太长，否则大家会删除不填。真正有用的模板应该让小改动几十秒填完，大改动也能提示提交者说明影响范围。对于文档站或教程仓库，还可以加一项“命令或链接是否已核对”。
十、评论要区分必须修改和建议优化
Review 评论如果不分轻重，会让协作变得疲惫。必须修改的问题包括逻辑错误、安全风险、测试缺失、配置错误、会影响用户的文案错误；建议优化则可以标注为 nit 或 suggestion，避免阻塞合并。
审查者表达越清楚，提交者越容易处理。比如“这里不对”不如“这个路径在 Windows 下会失败，建议使用 path.join”。小团队成员关系熟，也更容易忽略表达边界，但清晰评论能减少误解。
十一、自动检查和人工审查各管一部分
Lint、测试、构建适合交给机器；需求理解、风险判断、用户影响、架构取舍仍需要人工。不要让 Review 变成重复检查格式，也不要因为 CI 通过就跳过人工判断。
一个实用做法是：自动检查负责底线，Review 负责上下文。PR 页面同时保留机器结果和人工讨论，合并决策就更完整。等项目成熟后，再逐步把反复出现的问题沉淀成自动检查，减少人工重复劳动。
十二、合并后不要马上删除所有线索
功能分支可以删除，但 PR 说明、讨论和提交记录要保留。若合并后出现问题，应回到 PR 看当时的验证方式和风险提醒。如果 PR 描述过于简单，排查时就会缺少上下文。
对重要改动，可以在合并后补一句结果记录，例如“已部署到 staging 验证”或“生产发布后未观察到异常”。这类记录不必每次都有，但对高风险发布很有帮助。
