拉取请求前要做什么
在团队协作开发网站时，提交代码不能图快直接往主分支推。很多人一写完功能就急着发拉取请求（Pull Request），结果被同事打回来重改。其实，有几个关键步骤做扎实了，能省下不少来回沟通的时间。
确认你的分支是最新的
在你开始改代码之前，先确保自己的本地分支和远程的主分支（比如 main 或 develop）同步。如果别人已经合并了新代码，而你还在旧基础上改，后面很容易冲突。执行下面命令更新：
git checkout main
git pull origin main
git checkout your-feature-branch
git merge main这样能提前发现并解决冲突，而不是等到发 PR 才暴露问题。
把代码跑一遍
别以为本地看着没问题就能交。比如你加了个新页面，样式看着正常，但可能 JS 报错影响其他功能。把项目完整启动一次，走一遍相关流程，尤其是你改动的部分。如果是 Vue 或 React 项目，记得用 npm run build 构建一下，看是否报错。
检查代码格式和规范
很多团队用了 ESLint、Prettier 这类工具。如果你的代码缩进是两个空格，别人是四个，或者引号不统一，CI 流水线会直接挂掉。提交前运行一遍：
npm run lint
npm run format顺手把警告也处理了，别留 console.log 或注释掉的代码，显得不专业。
写清楚提交信息和 PR 描述
别只写“修复问题”或“更新代码”。别人看你 PR 时，得知道你改了啥、为啥改。PR 标题简洁明确，比如“修复用户登录页按钮点击无效”。描述里可以写：
- 问题背景：比如“用户反馈点击登录按钮无响应”
- 解决方案：比如“发现事件绑定丢失，重新绑定 click 事件”
- 测试方式：比如“本地启动后点击按钮，跳转正常”
如果涉及设计变更，附个截图更直观。
自己先 Review 一遍
提交前，把自己当成 reviewer 看一遍 diff。有没有误删文件？有没有改到不该动的配置？比如不小心把 .env 文件提交上去了，那可就出大事了。GitHub 上打开你的 PR 页面，逐行看看改动，像查bug一样过一遍。
这些动作看起来花时间，其实每步也就几分钟。做得勤快点，PR 被快速通过的概率高得多，队友看了也舒服，合作自然顺畅。