Git 安全协作：从改动检查到可回退提交

Git 最重要的价值不是“把代码传到远端”，而是保留清晰的变更历史。对个人项目和协作项目而言，一次好提交应该能回答：改了什么、为什么改、如何验证、出现问题怎样回退。

一次改动的最小流程

理解当前状态
        ↓
只修改本次目标相关文件
        ↓
检查差异与意外文件
        ↓
运行匹配风险的验证
        ↓
提交一件完整且可说明的事情

开始前可以先查看状态与差异：

git status
git diff

这一步能避免将临时文件、构建产物、无关格式化或他人的未提交修改混入本次工作。

提交应该足够小

“新增客服状态机校验”和“顺手升级全部依赖”不应是同一个提交。前者便于审查与回退，后者会扩大风险面。一个提交只聚焦一个可验证的目标，出问题时才知道该从哪里看。

三个常见保护措施

• 将密钥、本地数据库、日志、构建目录写入 .gitignore；提交前仍要检查，因为忽略规则不是万能保护。
• 修改前先确认当前分支与未提交内容，避免误把实验直接写入稳定分支。
• 不确定的变更先创建临时分支或补充测试，而不是用破坏性命令强行恢复工作区。

发生冲突时

冲突不是简单选择“我的”或“对方的”。先理解两侧改动分别要解决的问题，再合并为满足两者意图的结果；解决后运行测试并复查差异。能编译不代表业务语义已经正确。

提交前检查清单

• 差异中是否没有账号、密钥、私密数据或构建产物？
• 提交信息是否描述了真实意图？
• 自动化测试、构建或最小手工验证是否完成？
• README、接口说明或使用文档是否仍与当前行为一致？

把这些检查固化为习惯，版本历史就会成为项目的安全网，而不是事故后的最后一根救命绳。