上游 · 理解本功能前需先掌握的（0）：
无前置（本功能的认知起点）
下游 · 依赖/承接本功能的（3）：
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
你写文档时是不是存过'报告最终版''报告最终版2''报告最终版改改3'？这些文件名背后是版本混乱的痛。版本控制（version control）就是解决这个问题的系统：它记录每一次修改、允许随时回到任意历史版本，还能多人同时协作而不互相覆盖。Git 就是最流行的版本控制工具，学 GitHub 之前必须先懂它。
历史背景 · 它为什么诞生诞生于 1972-2005
诞生软件规模增长后人工备份版本文件极易出错（改错目录、覆盖文件），需系统化记录文件随时间的变化。1972年SCCS开创源码版本控制，RCS以补丁集实现本地版本管理，CVS为RCS加入网络与并发协作，SVN成为集中式主导，单一中央服务器成为标准。
演进集中式CVCS存在单点故障：服务器宕机或磁盘损坏且无备份即丢失全部历史。分布式DVCS（Git/Mercurial/Darcs）让每个克隆都完整镜像全部历史，任意客户端可恢复服务器，还支持离线提交与多种协作拓扑，最终Git成为主流。
历史教训
工具设计的本质是权衡：集中式便于管控但牺牲容灾，分布式牺牲一致性控制换来自主与鲁棒性。核心需求（安全、可恢复、可协作）决定了架构方向。
功能介绍
版本控制（version control）是一套管理系统，用来追踪文件（尤其是代码）随时间的变化。它像一台'时光机'：每次修改都会被记录成一个快照，你可以随时回到过去任意一个版本，也能看到'谁在什么时候改了什么、为什么改'。Git 是目前最流行的分布式版本控制工具（distributed version control system）——'分布式'意味着每个开发者的电脑上都有完整的项目历史副本，即使没有网络也能独立工作。相比之下，Word 的'另存为备份'只能手动做、容易忘、还占空间；版本控制自动完成这一切，并为团队协作打下基础。它是 GitHub 的地基，先理解它，后面的所有概念都顺理成章。
核心术语
版本控制（version control）：记录文件每次修改的系统Git：最流行的分布式版本控制工具提交（commit）：一次被记录下来的修改快照时光机：对版本控制'可回退历史'的形象比喻分布式（distributed）：每个开发者本地都有完整历史副本
适用场景
- 当你反复保存'最终版'文件，又找不到哪一版是对的时
- 当你改坏了代码想快速退回昨天能运行的状态时
- 当你想查看项目某个功能是什么时候、被谁加上时
- 当你和队友同时改一个项目，又怕互相覆盖时
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 在 GitHub 仓库页面打开任意一个文件，点右上角'History'查看修改历史
- 点某次提交右侧的代码图标，可查看该次改动的具体差异
- 在仓库页面选择不同分支（branch）或标签（tag）切换查看历史版本
⌨️ 命令行 (进阶)
git log # 查看提交历史git diff # 查看当前改动与上次提交的差异git checkout <commit-id> # 回到某个历史版本查看
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 概念升级Git 与 GitHub（Git vs GitHub） | 先理解版本控制思想，才能分清 Git 工具与 GitHub 平台 |
| 概念升级Git 命令行基础（Git CLI Basics） | 版本控制思想落地为 Git 命令行基础 |
| 概念升级代码片段分享：Gists（片段） | gist 是微型 Git 仓库，可 fork/clone，先懂版本控制 |
官方文档
小结
SUMMARY
版本控制是给文件配的'时光机'，记录每次修改、支持随时回退，Git 是其中最常用的工具。理解了这一点，你就有了理解 GitHub 一切功能的基础。下一步：搞清楚 Git 和 GitHub 到底有什么关系。