拆好任务，别堆大块头
项目一忙起来，有人一口气改十几个文件，提交一个几百行的合并请求（MR），队友一看头都大了。这种“巨无霸”MR审查起来费劲，冲突概率也高。建议把功能拆细，比如做用户登录，就把表单验证、接口调用、错误提示分成几个小 MR，每个聚焦一点，别人看得明白，自己也好改。
写清楚改动原因
很多人写 MR 描述只写“修复问题”或“更新逻辑”，队友根本不知道你动了啥。不妨花一分钟说明背景：比如“为解决移动端按钮点击失效，调整事件绑定方式”。顺手贴个测试链接或截图，别人一眼就懂，省去来回问的时间。
主动标记待处理项
如果 MR 还没完，只是想提前看结构，就标上【WIP】（Work in Progress）；有地方拿不准，直接在代码评论里@对应同事。比如：
// @前端组长：这里动画时长试了 300ms 和 500ms，目前用的短的，你觉得哪个更顺？合并前先同步主干
本地分支太久没更新，一提 MR 就一堆冲突。聪明的做法是提之前先拉一下主干：
git checkout main
git pull origin main
git checkout your-branch
git rebase main用自动检查减负
团队可以配好 CI 规则，比如代码格式、单元测试不过就自动标红。这样人不用盯着缩进和分号，专注看逻辑是否合理。有次同事提交忘了删调试 console，CI 直接拦下，省得大家在评论里反复提醒。
评论别只说“有问题”
审查别人 MR 时，别说“这逻辑不对”，要说清哪一行、什么情况会出问题。比如：“第 42 行，如果用户没权限，res.data 可能为空，直接解构会报错，建议加判断”。对方改起来明确，也不会觉得你在挑刺。
合并后记得清理分支
Merge 完顺手删掉远程分支，避免列表里堆满“login-fix-v1”“login-fix-v2”“login-fix-final”这种历史包袱。本地也可以定期执行：
git branch -d your-branch