- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git commit 教程
解释 git commit 如何生成新的历史节点、怎样写出更有价值的提交信息，以及 amend 适合和不适合的边界。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
一句话理解
git commit 会把暂存区中的快照固定成一个新的提交对象，并把当前分支移动到这个新的历史节点上。
一个好的 commit 不只是“把代码存下来”，而是提供一个清晰检查点，并告诉后来的人为什么这里值得成为一个检查点。
它真正解决的是什么问题
很多人把 commit 当成保存按钮。
这个理解太弱了。
一个高质量提交至少同时提供：
- 可回退的检查点
- 可评审的最小变更单元
- 可 cherry-pick、可回滚的历史颗粒度
- 让团队看懂演进过程的文字说明
所以问题从来不是“有没有提交”，而是“这个提交是否值得存在”。
常见用法
git commit -m "feat: add search dialog"
git commit --amend
git commit -m：把当前 staged 内容写成一个新提交git commit --amend：重写最近一次本地提交
提交前应该先确认什么
执行前先问自己三个问题：
- 暂存区是不是只包含一个逻辑主题？
- 提交信息是不是解释了意图，而不只是描述“改了文件”？
- 这段历史还只在本地，还是已经被别人看到？
第三个问题很关键，因为：
- 本地历史可重写，成本通常不高
- 已共享历史再改写，就会变成协作问题
提交信息怎样更有价值
更好的提交信息通常具备这些特点：
- 具体
- 动词导向
- 与 diff 范围一致
例如：
- 更好：
fix: avoid infinite loading in doc search - 较弱：
update search - 更弱：
misc changes
很多时候，提交信息写不好，并不是因为你不会写句子，而是这次提交本身就过于混杂。
amend 什么时候适合用
git commit --amend 很适合这些情况：
- 刚提交完，发现漏加了一个小文件
- 提交信息写得太模糊
- 想在发起评审前把最近一次提交整理得更干净
它不太适合这些情况：
- 这次提交已经 push 到共享分支
- CI、评审评论或同事已经建立在这段历史上
如果历史还没有共享，amend 是清理最近一次提交最省噪音的方式之一。
一套更稳的提交流程
更推荐这样做：
- 用
git status看状态 - 用
git diff --staged看这次提交真正会包含什么 - 写一个说明意图的消息
- 提交后用
git log --oneline -5看最近历史是否清晰
例如：
git status
git diff --staged
git commit -m "fix: fall back to local search index on timeout"
git log --oneline -5
图例理解
工作区改动暂存区快照当前分支
新提交对象移动后的分支指针可恢复检查点
如果提交结果不对，优先检查 index 是否已经从一开始就错了。
边界与常见错误
git commit不会自动包含所有可见文件改动，它只记录 staged 的内容。- 一个提交里混了重构、修 bug、格式化，后续 review 和 revert 都会更痛苦。
- 本地重写历史通常是低成本整理；已发布历史再改，是协作层面的决定。
如果一条提交信息怎么写都显得模糊，通常不是文字问题，而是这次提交的边界本来就不清楚。
跟着做一遍
目标是感受 staging 和 commit message 一起作用时，历史质量为什么会明显更高。
git switch -c lab/commit-demo # 同时做一个真正修复和一个无关清理动手试
- 先想象把所有改动一次性提交会得到什么 message。
- 然后清空 index，只暂存真正修复的部分。
- 创建一条聚焦提交。
- 再把清理部分单独提交，写第二条更准确的 message。
- 你可以直观看到“一个混乱提交”和“两条清晰提交”的差别。
- 分离后的历史更容易 review。
- 以后要 revert 或 cherry-pick 时，成本也会更低。
- 如果已经 push，再 amend 前先确认分支是否共享。
- 如果 message 很泛，先怀疑 staged diff 是否太大。
- 如果不确定这次 commit 会写入什么，先看 `git diff --staged`。