版本管理＝给代码装时光机；Subversion 是集中式老派（一台服务器管账），Git 是分布式新派（人人本地全套账本），GitHub 是给 Git 加社交与协作的云平台——2026 年，Git 已经是唯一答案，但对比 SVN 才懂它强在哪。
上游：5-9/5-10 的 DevOps 流水线第一站就是提交代码；6-15 的 GitHub API 只是其一。本机 git --version 就有 2.55——学完立刻能上手。
一、为什么需要时光机
没有版本管理的世界：论文最终版.docx、论文最终版2.docx、论文最终版打死不改版.docx……程序员版：backup_0301.tar.gz。版本管理系统（VCS）三件承诺：
- 历史：任何时刻可回滚（后悔药）；
- 差异：谁哪天改了哪行，一目了然（追责/复盘）；
- 协作：多人同时改，系统帮你合并。
二、Subversion（SVN）：集中式时代
SVN（2000）＝一台中央服务器是唯一账本，开发者检出（checkout）工作副本、改完提交（commit）回中央：
- 简单直观：账本只有一份，不会乱。
- 软肋：断网不能提交（本地没有全套历史）；中央服务器坏了＝所有人的历史都没了（单点故障）；分支要整目录复制（贵，所以大家不敢开分支）。
三、Git：分布式时代
Git（2005，Linus 两周写出）＝每人本地都是全套仓库（含全部历史），中央仓库只是「大家同步的那一份」：
- 快照非差异：SVN 存「文件每次改动的增量」；Git 存「每次提交时整个项目的快照」，没变的文件只存指向上一版的指针——又快又省。
- 分支便宜到随手开：分支＝一个指向某快照的指针，
git branch毫秒级——开分支像呼吸一样频繁正是现代工作流（feature branch、5-10 CI）的前提。 - 离线全功能：commit、看历史、开分支全在本地；推（push）/拉（pull）时才碰远端。
| 维度 | SVN | Git |
|---|---|---|
| 账本 | 中央一份 | 人人一份 |
| 断网提交 | ✗ | ✓ |
| 分支成本 | 目录复制（贵） | 指针（几乎零） |
| 单点故障 | 有 | 无（任意克隆都是备份） |
四、GitHub：Git ＋ 协作平台
GitHub（2008）不是 Git——是托管 Git 仓库并叠加协作功能的云平台： - Pull Request：我的改动请你审查（5-3 的评审环节产品化）——开源协作的标准动作； - Issues/Actions/Wiki：问题跟踪、CI/CD（5-10 的 GitHub Actions）、文档一站化； - 规模（2025 Octoverse）：1.8 亿+ 开发者账号；TypeScript 已是月度贡献者第一的语言——世界最大的代码城。 - 同类：GitLab（自托管强）、Gitee（国内速度快）。
动手 Demo：亲手建一个时光机
# 逐行执行（Windows 自带 git 2.55）
mkdir demo_git && cd demo_git
git init # ① 初始化仓库：出现 .git 目录（账本本体）
echo "第一章 初稿" > book.txt
git add book.txt # ② 暂存：宣告这个文件的改动要记账
git commit -m "第一章" # ③ 提交：拍一个快照
echo "第二章 续写" >> book.txt
git diff # ④ 看未暂存的差异：+第二章 续写
git add . && git commit -m "第二章"
git log --oneline # ⑤ 历史一览：两个快照
git checkout HEAD~1 -- book.txt # ⑥ 时光倒流：拿回上一版的文件
cat book.txt # 只剩第一章 —— 后悔药到手
git checkout HEAD -- book.txt # ⑦ 再回来
看到什么算成功：git log 列出两次提交（各带哈希与信息）；第⑥步后文件真回到第一章——历史与回滚亲眼验证。
读结果：add（暂存）与 commit（快照）两段式是 Git 的核心节奏；每次 commit 的哈希（如 a3f9c2e）就是那台时光机的坐标。
30 秒实验
在任意 Git 仓库（比如本 vault 若是仓库，或上面 demo）跑 git log --oneline | head -5 与 git branch -a——看看历史深度与分支数量。开源大仓库（如用 6-15 的 API 查 CPython）分支常以百计——「分支便宜到随手开」不是修辞。
常见误区
- 「Git 和 GitHub 是一家」——Git 是工具（Linus 写的、离线可用）；GitHub 是托管平台（微软的）；Gitee/GitLab 也能托管 Git。
- 「commit 前必须 add 是多余的」——两段式让你挑选本次快照要包含哪些改动（一半想提交一半不想时特别有用）。
- 「合并冲突是 Git 坏了」——两人改同一行，机器无法替你做主；冲突文件里的
<<<<<<<标记是请人类裁决——协作的必修课不是故障。
自测三问（点击展开）
1. **SVN 与 Git 最本质的架构差别？** 答：SVN 集中式（历史只在中央服务器）；Git 分布式（每人本地全套历史）。 2. **Git 的快照模型强在哪？** 答：存整项目快照＋未变文件复用指针——快、省、分支几乎零成本。 3. **GitHub 的 PR 解决协作中的什么问题？** 答：改动审查与讨论——合并前让他人把关，质量与知识共享双收。- ☑ 6-16 完成 —— 时光机三代：SVN→Git→GitHub
- ☐ 下一节 6-17 开源软件、许可协议
相关笔记
- CI/CD —— 提交后的自动流水线
- API —— GitHub 的窗口
- ⌨️ 编程原理 · 索引 —— 全课路线图