上游 · 理解本功能前需先掌握的（1）：
下游 · 依赖/承接本功能的（3）：
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
如果说版本控制是'时光机'，那提交（commit）就是给时光机按下的'拍照键'。每次你认为代码到了一个值得纪念的状态，就提交一次。没有提交，就没有历史、没有回退点，前面学的版本控制全部落空。
历史背景 · 它为什么诞生诞生于 2005
诞生早期VCS（RCS/CVS/SVN）以增量差异存储数据，易损坏且重命名处理麻烦。Git改用快照存储：提交对象包含根树指针、作者信息、提交信息及父提交指针；所有内容先经SHA-1校验再存储，无法察觉的损坏会被Git发现，保障大型分布式项目的完整性。
演进commit从"记录变更"升华为"协作单元"：GitHub以提交为最小审查对象，PR的Commits/Files Changed标签页呈现提交累积效果；提交信息成为代码评审与回滚的沟通载体，配合SHA-1不可变性、签名提交（GPG）等增强可信度。
历史教训
数据存储方式决定系统能力的上限：快照+内容寻址带来完整性校验与隐式重命名；提交信息是写给未来协作者的文档，好的历史记录本身就是团队资产。
功能介绍
提交（commit）是 Git 的核心操作：官方定义是'提交会记录你对一个或多个文件的修改'，它把你当前所有已暂存的改动打包成一个历史快照。每个提交都会被分配一个唯一 ID，称为 SHA（Secure Hash Algorithm，一串 40 位的十六进制字符），用来精确指认某一次修改。提交时必须写一条提交信息（commit message），说明这次为什么改——好的信息是对未来自己和队友的交代。提交还有一个关键特性：它总是依附于某一个分支（branch），提交到哪个分支就记录在哪个分支上。Git 通过提交串成一条条历史线，版本控制的一切功能都从'拍好每一次快照'开始。
核心术语
提交（commit）：记录一次文件修改的历史快照SHA：Git 分配给每个提交的唯一标识符提交信息（commit message）：解释'为什么这样改'的说明文字暂存区（staging area）：add 与 commit 之间的中间区域依附分支：提交总是记录在某个特定分支上
适用场景
- 当你完成一个功能、修好一个 bug，想打个'检查点'时
- 当你想让代码修改能被追溯、能安全回退时
- 当你担心改坏代码、想给可运行状态留个保险时
- 当你提交后发现写错信息、需要修改提交信息时
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 在仓库文件页编辑文件后，页面底部填写提交信息并点击 'Commit changes'
- 点击仓库页面 'Commits' 标签查看全部提交历史与 SHA
- 点击某个提交进入详情页，查看它改动了哪些文件、每行怎么改的
⌨️ 命令行 (进阶)
git add README.md # 把文件加入暂存区git commit -m "添加 README 说明文档" # 提交并写提交信息git log --oneline # 查看简洁提交历史（含短 SHA）git commit --amend -m "修正提交信息" # 修改最近一次提交的信息
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 前置依赖Git 命令行基础（Git CLI Basics） | git add/commit 是核心命令，先学基础命令再谈提交 |
| 概念升级分支（Branch） | commit 是分支的内容，理解提交后才理解分支 |
| 包含从属标签（Tag） | tag 标记某个 commit 作为历史节点 |
| 流程承接推送与拉取（Push & Pull） | push 把本地 commit 推送到远程 |
官方文档
小结
SUMMARY
提交是版本控制的'拍照键'，每次记录一组改动并打上唯一 SHA 和说明信息。养成'完成一件事就提交一次'的习惯，你的代码就有了完整保险。下一步：学会用分支在安全的岔路上搞开发。