确认代码变更的必要性
在发起拉取请求（Pull Request）之前，先问问自己：这次提交真的有必要吗？有时候本地改了几行样式，自认为优化了逻辑，但实际上可能只是重复造轮子。比如前端同事小李曾把按钮颜色从蓝色改成深蓝，结果评审时发现设计稿本来就是这个色值，白忙一场。所以动手前对照需求文档或任务单，确保每行代码都有它的位置。
同步最新主干代码
团队协作中，远程主分支可能已经合入其他人改动。如果长时间不更新本地分支，等到提 PR 时容易出现大量冲突。建议每次开始工作前执行：
git checkout main
git pull origin main
git checkout your-feature-branch
git rebase main这样能提前暴露问题，避免在 PR 里堆一堆无关的合并提交。
清理提交记录
不要让“修复上一个修复”“临时调试”这类提交出现在 PR 中。评审人不需要知道你试错的过程。用 git rebase -i 把多个零散提交整理成逻辑清晰的几个块，比如“新增用户校验逻辑”“调整表单提交方式”。整洁的提交历史能让别人快速理解你的意图。
运行本地测试
不管是单元测试还是集成脚本，跑一遍总没错。后端接口改了一个字段，没跑测试就推上去，结果 CI 流水线卡住，整个团队的合并流程都被拖慢。开发机上花三分钟，能省下大家半小时等待时间。
检查代码风格和格式
项目如果有 ESLint、Prettier 或 Black 这类工具，别跳过它们。一个缩进空格不对的文件，会让自动化检查失败，CI 标红。更尴尬的是被自动机器人评论“请修复格式问题”，来回修改几次特别影响体验。提交前顺手执行一下格式化命令，保持团队风格统一。
写清楚 PR 描述
别只写“修复问题”或者“功能更新”。说明改了什么、为什么改、有没有关联的任务编号。如果是修复 bug，附上复现步骤和截图；如果是新功能，简单描述使用场景。好的描述能让 reviewer 快速进入状态，减少来回沟通成本。
指定合适的评审人
不是所有 PR 都要 @ 全组。后端接口变动找熟悉该模块的人，UI 调整让前端负责人看看就行。乱 @ 一通只会打扰别人工作节奏。如果不确定，可以先私聊问一句“这个改动你方便看下吗”，比直接甩个通知更得体。