提交前先检查改动内容
很多人写完代码就急着提交，结果一不小心把调试用的 console.log 留在了生产代码里。这种情况就像做饭忘了关火，后患无穷。每次提交前用 git diff 看一眼实际修改了哪些行，能避免不少低级错误。
特别是团队协作时，别人可能正等着你的接口对接，你提交了一堆无关的日志或临时变量，对方还得花时间分辨哪些是有效改动。
写清楚提交信息
别再写“修复问题”或者“更新代码”这种让人摸不着头脑的信息了。好的提交信息应该像快递备注：“修复用户登录跳转异常”、“调整订单页面按钮样式”。这样几个月后再翻记录，自己都能快速定位到当时的修改意图。
推荐格式：开头用动词简要说明操作，比如 fix、update、add，接着描述具体对象和目的。例如：
fix: 用户登出后 token 未清除导致误判登录状态小步提交，别堆大包
一次提交解决五个问题，听起来效率很高，其实隐患很大。万一其中一个功能出问题，回滚都难。就像搬家时把所有东西塞一个箱子，找件衣服得翻完整个家。
建议把关联性强的改动分成独立提交。比如新增用户注册功能，可以拆成：add: 注册表单前端结构，add: 注册接口调用逻辑，fix: 表单校验提示样式。每一步都清晰可追溯。
留意文件编码和换行符
有时候你在 Windows 上改的代码，提交到 Linux 服务器运行就报错。很可能是换行符不一致导致的。Git 默认会自动转换换行符，但如果项目成员使用不同系统，最好提前统一配置。
可以在项目根目录加 .gitattributes 文件明确规则：
* text=auto
*.sh text eol=lf
*.bat text eol=crlf这样能减少因环境差异引发的莫名错误。
分支管理别混乱
直接在 main 分支上改代码，改到一半被叫去修紧急 bug，结果两边都卡住。合理的做法是按功能或任务开独立分支。比如开发新支付模块就创建 feature/payment-alipay 分支，修短信发送问题就切 hotfix/sms-fail 分支。
完成后再通过 Pull Request 合并进主干，既方便审查，也降低出错风险。
提交前跑一遍测试
哪怕只是改了一个按钮颜色，也可能意外影响到其他组件。如果项目里有自动化测试脚本，顺手执行一下。没有的话，至少手动点开相关页面看看有没有明显异常。
曾经有个同事只改了 CSS 类名，忘了同步 JS 里的选择器，导致上线后购物车加不了商品。这类问题完全可以在提交前发现。