本章你会学到什么

• 理解 Git 的核心概念：工作目录、暂存区、提交历史、远程仓库
• 跑通一套最小工作流：从初始化到推送的完整闭环
• 区分 Git 和 GitHub 各自的角色
• 掌握日常最常用的命令
• 学会写清晰的提交信息
• 了解基本的"救命"操作——改坏了怎么撤回

这一章的定位

从第一章开始，这本书会系统地讲解版本控制的原理、Git 的每一个核心概念、以及团队协作的完整工作流。但在那之前，本章先帮你建立"手感"——让你在不理解所有底层细节的情况下，先跑通最常用的操作。

这不是要跳过理解，而是先让你知道"大概长什么样"，再回头学"为什么是这样"。有了直观体验之后，后面读概念会快得多。

Git 不是什么

在讲 Git 是什么之前，先澄清几个常见误解。

Git 不是网盘。网盘存的是文件，Git 存的是文件的变化历史。你每一次修改、删除、新增，Git 都会记录下来，而且可以回溯到任意一个历史状态。

Git 也不是"高级另存为"。另存为是手动复制文件，每次都要自己管版本号。Git 自动管理这些——每次提交就是一个带说明的历史节点，不需要你手动命名 v2_最终版_修改2.md。

GitHub 也不是 Git 本体。Git 是运行在你电脑上的版本控制系统，GitHub 是一个建立在 Git 之上的托管平台，提供网页界面和协作功能。你可以完全不用 GitHub 照样用 Git，但加上 GitHub 就能备份、协作和分享。

四个层次

Git 管理的东西可以分成四个层次。搞清楚这四个层次，后面就不容易乱。

工作目录就是你正在编辑的真实文件夹。你打开 Typora 写文档、改代码，改的就是工作目录里的文件。

暂存区是一个中间区域。你用 git add 把工作目录中的修改放进暂存区，告诉 Git "这些改动我打算提交"。暂存区让你精确控制每次提交包含哪些文件——不是所有修改都必须一起提交。

提交历史是 Git 的核心。每次你执行 git commit，Git 就在工作目录的状态上拍一张快照，附上你的说明和时间戳，永久保存。这些快照串联成一条时间线，你可以随时往前翻看。

远程仓库是存放在服务器（比如 GitHub）上的仓库副本。它和你的本地仓库可以互相同步：你推送本地提交到远程，也从远程拉取别人的提交到本地。

这四个层次之间的关系是：你在工作目录里编辑，选性地把修改放进暂存区，把暂存区的内容提交为一个新的历史节点，然后把历史节点推送到远程仓库备份。

最小工作流

Git 的日常使用可以简化为一个循环：

查看状态 → 暂存修改 → 提交记录 → 同步远程

对应的核心命令：

git status
git add .
git commit -m "说明你做了什么"
git pull
git push

这不是"入门玩具"，是很多开发者每天都在用的主干动作。后面学的所有高级功能，都是在这个基础上的扩展。

从零跑通一遍

假设你有一个文档项目文件夹，里面有几个 Markdown 文件和一些图片。现在要把它纳入 Git 管理。

初始化仓库

cd my-project
git init

git init 只做一件事：在当前目录下创建一个 .git 隐藏文件夹。这个文件夹就是 Git 存储所有版本信息的地方。此时你的文件还没有被跟踪——Git 知道这个仓库的存在，但还没有记录任何东西。

查看状态

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md
        chapters/
        images/

git status 是你最应该养成习惯的命令。它告诉你哪些文件是新的、哪些被修改了、哪些已经暂存、哪些还没被 Git 跟踪。

暂存并提交

$ git add README.md
$ git commit -m "docs: add project README"

git add README.md 把 README.md 放进暂存区。git commit 把暂存区的内容打包成一个历史节点，-m 后面的是你对这次提交的说明。

如果你有多个文件要提交，可以逐个 add，也可以一次性 add 所有修改：

$ git add .
$ git commit -m "docs: add initial project structure with chapters and images"

git add . 会把当前目录下所有修改过的文件放进暂存区。方便，但你要清楚自己改了什么——用 git status 和 git diff 先检查。

连接远程仓库

如果你有 GitHub 账号，可以创建一个远程仓库来备份和同步：

$ git remote add origin https://github.com/yourname/your-repo.git

这告诉 Git："以后推送和拉取，默认用这个地址。"

推送到远程

$ git push -u origin main

-u 设置跟踪关系——以后直接 git push 就行，不用再指定远程和分支名。

到这里，从初始化到推送的完整闭环就跑通了。

Git vs GitHub：各自负责什么

两者的职责边界很清晰。

Git 负责的是版本控制本身：记录修改历史、创建分支、合并分支、比较差异、回滚。这些操作全部在你的电脑上完成，不需要网络。

GitHub 负责的是托管和协作：在服务器上存储你的仓库，提供网页界面浏览代码和历史，提供 Issues（任务追踪）、Pull Requests（代码审查）、Actions（自动化）等协作工具。

简单说：Git 是引擎，GitHub 是平台。类比的话，Git 像是文字处理软件，GitHub 像是基于这个软件的协作文档平台。

日常最常用的命令

以下是你最值得先练熟的命令：

命令	作用	什么时候用
git status	查看当前状态	随时，养成习惯
git add <file>	把文件放进暂存区	准备提交前
git add .	把所有修改放进暂存区	确认改动后
git commit -m "..."	提交暂存区的内容	一个阶段完成后
git log --oneline	查看简短提交历史	想回顾做了什么
git diff	查看未暂存的具体修改	提交前检查
git diff --staged	查看已暂存的修改	提交前最后确认
git restore <file>	撤销工作区的修改	改错了想恢复原样
git restore --staged <file>	把文件从暂存区移出	add 错了想撤回
git pull	拉取远程最新内容	开工前
git push	推送本地提交到远程	收工前

前 9 个是日常最高频的命令，建议优先熟练掌握。

提交信息怎么写

提交信息的核心目的是：让你（或别人）以后看到这条记录时，能快速知道这次提交做了什么。

一个简单有效的格式：

类型: 简短描述

常用类型：

• docs — 文档相关
• fix — 修复 bug 或错误
• chore — 杂项（整理文件、调整目录结构等）

示例：

• docs: add chapter 1 draft
• fix: correct formula in section 3.2
• chore: reorganize chapter folders

避免写没有信息量的消息，比如 update、change、123、final。这些消息在你回看历史时毫无帮助。

改坏了怎么办

这是新手最担心的问题，也是 Git 最有价值的场景之一。

情况一：文件改了，还没 add，想恢复原样

$ git restore README.md

文件恢复到上次提交的状态，你的修改被丢弃。

情况二：add 了，但还没 commit，想撤回

$ git restore --staged README.md

文件从暂存区移出，但修改还在工作目录里。

情况三：刚 commit 完，发现提交信息写错了

$ git commit --amend

这会打开编辑器让你修改最近一次提交的信息。如果只是想改信息，不影响提交内容，这是最安全的方式。

情况四：想看某个文件到底改了什么

$ git diff README.md

逐行显示你的修改，绿色是新增，红色是删除。提交前用 git diff 检查一遍，能避免很多低级错误。

情况五：想回看提交历史

$ git log --oneline

显示所有提交的简要列表——哈希值和提交信息。想看某次提交的详细内容：

$ git show <提交哈希>

这些操作覆盖了日常绝大多数"救命"场景。更复杂的撤销操作（如回退多个提交、找回已删除的分支）会在第三章详细讲解。

什么时候需要分支

到目前为止，你所有的工作都在一条直线上——每次提交都是在上一次的基础上继续。这在简单场景下没问题，但当你需要同时做两件不同的事时，直线就不够用了。

分支解决的就是这个问题。它让你创建一条独立的工作线，在这条线上做修改不会影响主线。比如你想尝试重写某一节，但不想破坏当前版本——建一个分支就行。

最基本的用法：

$ git checkout -b experiment/rewrite-section-3

这会创建一个叫 experiment/rewrite-section-3 的新分支，并切换过去。你在上面做的所有提交都不会影响 main。

分支的详细用法（创建、切换、合并、解决冲突）会在第四章完整讲解。这里你只需要知道：分支存在，它是安全的，你随时可以创建和删除。

文档工作为什么适合用 Git

很多人以为 Git 只是程序员工具。实际上，文档工作和 Git 的契合度很高，因为文档有几个特点：反复修订、章节移动、图片替换、措辞调整、内容扩充、偶尔需要回滚到某个旧版本。

尤其是教材、知识库、教程这类内容——你不是在维护一个"最终成品文件"，而是在维护一个持续演化的文本系统。每次修订都是一次提交，每个版本都可以回溯，这正是 Git 擅长的场景。

GitHub 上最先该学会什么

如果你刚开始用 GitHub，以下几件事优先级最高：

• 创建仓库：仓库是项目的容器，理解这一点比记住具体按钮位置更重要
• 看 README：README 是项目的首页说明，不是摆设
• 推送本地仓库：让 GitHub 成为你的备份和同步节点
• 浏览提交历史：网页端也能看到完整的修改记录

Pull Request、Issues、Actions 这些功能很重要，但不需要在第一天就学。先把本地的版本控制闭环跑稳，再接触平台协作功能会轻松很多。

实操练习

在阅读后续章节之前，建议动手做一遍以下练习。Git 的手感来自操作，不是阅读。

# 1. 创建一个练习目录
mkdir git-practice
cd git-practice
git init

# 2. 创建一个文件并提交
echo "# My Practice Repo" > README.md
git add README.md
git commit -m "docs: add initial README"

# 3. 修改文件再提交
echo "This is my first Git repo." >> README.md
git add README.md
git commit -m "docs: add description to README"

# 4. 查看历史
git log --oneline

# 5. 修改文件但不提交，然后用 diff 查看
echo "Adding a new line." >> README.md
git diff

# 6. 撤销刚才的修改
git restore README.md

# 7. 确认文件已恢复
git diff

如果你跑完了这 7 步，Git 对你来说就已经不是纯概念了——你亲手创建过仓库、提交过修改、查看过历史、撤销过改动。

本章小结

Git 是版本控制系统，它跟踪文件的变化历史，让你可以随时回溯到任意一个历史状态。GitHub 是建立在 Git 之上的托管和协作平台。

Git 管理的内容分四个层次：工作目录（你编辑的地方）、暂存区（提交前的准备区）、提交历史（所有版本快照的记录）、远程仓库（服务器上的备份副本）。

日常最小工作流是 git status → git add → git commit → git pull / git push。这条循环覆盖了绝大多数个人项目的日常需求。

改坏了不用怕：git restore 撤销工作区修改，git restore --staged 取消暂存，git commit --amend 修改最近的提交信息，git diff 检查具体改动，git log --oneline 回看历史。

下一步

下一章会回到原点，解释一个根本性的问题：版本控制到底在解决什么问题？理解了这个，后面所有概念都会更自然。