提交与提交前检查

提交是把暂存区选定的目录树写成一个新的快照,并记录父提交、作者、时间和消息。它不是把工作区“全部保存”。完整结构见 Git 状态模型与提交图。一个好的提交应当有清晰范围、可读消息,并且不混入无关文件。

git commit

git commit

用途:创建提交,并打开默认编辑器填写提交信息。

适用场景:

  • 提交说明比较长,需要写标题和正文。
  • 团队要求提交信息中解释背景、风险或验证方式。

提交信息建议:

  • 第一行写简短主题,例如 fix: handle empty config path。
  • 如果需要,空一行后写更详细的原因、影响和验证。

git commit -m 'message'

git commit -m "message"

用途:用命令行内联消息创建提交。

适用场景:

  • 小改动或说明很短的提交。
  • 自动化脚本或快速本地快照。

示例:

git commit -m "docs: add git cheat sheet notes"

注意点:

  • Windows PowerShell 中单引号和双引号都能表达字符串,但如果消息里包含变量或转义字符,双引号会触发 PowerShell 插值。
  • 提交前仍应先检查 git diff --staged,不要只依赖 commit message。

git commit -am 'message'

git commit -am "message"

用途:把所有已跟踪文件的修改先暂存,然后提交。

适用场景:

  • 已修改的都是 Git 已跟踪文件。
  • 不涉及新增文件。

限制:

  • 不会自动包含未跟踪的新文件。
  • 容易把多个已跟踪文件的无关修改一起提交,执行前建议先看:
git status --short
git diff

提交前检查流程

推荐的最小流程:

git status --short
git diff
git add -- README.md
git diff --staged
git commit -m "type: short message"

说明:

  • git status --short 快速确认改动清单。
  • git diff 看还没暂存的内容。
  • git diff --staged 看即将进入提交的内容。
  • 如果项目有测试、lint 或格式化命令,应在提交前运行对应验证。

修改提交信息或补交文件

如果刚提交完就发现消息写错,或漏暂存了一个文件,可以使用:

git commit --amend

详细说明见 历史改写与故障恢复。如果提交已经推送给别人使用,修改历史前要谨慎。

提交完成检查

  • git diff --staged 中每一行都属于同一个清楚意图。
  • git status --short 没有意外的凭据、缓存、锁文件或大文件。
  • 提交后能用 git show --stat --oneline HEAD 解释该快照做了什么。
  • 项目要求的测试、lint 或文档检查已实际运行,并如实记录结果。