检查代码是否干净整洁
在提交合并请求之前，先看看自己写的代码有没有多余的空行、废弃的注释或者临时调试用的 console.log。这些小细节虽然不影响功能，但会让别人读起来很别扭。就像你去朋友家做客，厨房台面上还堆着没洗的碗，哪怕饭菜再香，也会让人觉得不够讲究。
可以顺手格式化一下代码，确保缩进统一，变量命名清晰。如果团队用了 Prettier 或 ESLint 这类工具，运行一遍自动修复，省时又省心。
本地测试跑通再说
别急着点“提交”，先把改动在本地跑一遍。比如你改了个用户登录逻辑，那就真登录一次看看有没有问题。有时候看起来改得挺完美，结果一运行才发现漏了异常处理，或者某个字段没传对。
如果有单元测试，记得运行相关用例。哪怕项目没强制要求写测试，至少把涉及的功能手动试一遍，避免把明显 bug 推到远程分支上。
同步最新主干代码
你开发的时候，主分支可能已经合入了别人的新改动。如果不先拉取最新代码，合并时很容易出现冲突。提前执行：
git checkout main
git pull origin main
git checkout your-feature-branch
git merge main这样能在本地解决冲突，而不是等到合并请求页面上一堆红字等着处理。
写清楚修改说明
别只写“修复问题”或者“更新代码”这种话。别人看你提交时，最想知道的是：你改了啥？为啥要改？有没有影响其他地方？
比如写成：“调整订单状态判断逻辑，修复未支付订单被误标记为已完成的问题。影响范围仅限于订单服务的状态机模块，已验证历史数据不受影响。” 这样 reviewer 一眼就能抓住重点，不用翻半天代码猜意图。
缩小改动范围
一次提交改几十个文件，谁都看不下去。如果你既重构了代码结构，又顺手改了接口字段，还加了新功能，那 review 起来就太累了。尽量把大改动拆成几个小请求，每个聚焦一个目标。
比如先把公共方法抽离出来单独提一个 MR，再基于它实现新功能。这样不仅容易过审，出问题也方便回退。
叫对人来审查
提交之后别干等着，主动@熟悉相关模块的同事。如果改的是支付流程，就找负责这块的人；如果是 UI 调整，让前端同事看看样式有没有错位。别随便扔给组长，他可能正忙着开会，根本没空细看。
有时候顺带说一句“这个改动会影响下单超时时间，麻烦确认下配置是否需要调整”，能帮 reviewer 更快做出判断。