提交应当小而完整

一次提交最好只表达一个意图，例如“增加文章列表”或“修复移动端导航溢出”。它必须能独立说明改了什么，同时尽量保持代码可运行。不要把格式化、功能开发和无关修复塞进同一次提交。

写能回答“为什么”的提交信息

文件差异已经展示“改了哪些行”，提交信息更适合说明目的。可以使用简短动词开头，并在需要时补充原因。

feat: 增加文章阅读页
fix: 避免窄屏下卡片横向溢出
docs: 补充本地启动说明
refactor: 提取重复的日期格式化逻辑

为有风险的工作建立短分支

简单文字修改可以直接在主分支完成；需要数小时、可能推翻或涉及多个文件的改动，适合建立一个短期功能分支。完成并验证后尽快合并，避免长期分支产生难以理解的差异。

提交前固定做一次检查

  1. 运行 git status，确认没有临时文件或隐私信息。
  2. 阅读 git diff，检查真实改动而不是依赖记忆。
  3. 执行与改动相关的测试或构建。
  4. 只暂存属于当前意图的文件，再创建提交。

历史是项目的第二份文档

半年后看到一段陌生代码时，git log 和 git blame 可以告诉我们它在什么背景下产生。可读的提交记录不仅用于回退，也保存了项目决策的来龙去脉。

一个好提交的判断标准：未来的你能否仅凭标题理解它，并且愿意把它单独回退。