一、前言：为什么每个开发者都要学 Git 与 GitHub
如果你写过代码、保存过文档，就会知道一个常见的痛点：
报告_v1.docx
报告_v1_最终.docx
报告_v1_最终_真的不改了.docx
报告_v1_最终_真的不改了_老板说要改.docx
Git 的出现彻底解决了这个问题。它是一套分布式版本控制系统，可以精确记录文件的每一次改动，让你随时回退、对比、分支实验，并与他人无缝协作。
而 GitHub 是目前全球最大的代码托管平台，基于 Git 构建，提供了远程仓库、Pull Request、Issue、Actions、Pages 等一整套协作工具。
简单地说：
- Git = 本地版本管理工具（命令行）
- GitHub = 远端协作平台（网站 + 服务）
两者配合的典型场景就是：本地写代码 → Git 记录改动 → 推送到 GitHub → 团队成员从 GitHub 同步 → 通过 PR 合并代码。你正在看的这篇文章，就是 Hugo + Git + GitHub + Vercel 这条流水线自动构建发布的。
本文将从零开始，按"概念 → 安装 → 命令 → 协作 → 实战"的顺序，逐步带你掌握 Git 与 GitHub 的完整日常用法。
二、必须先理解的 8 个核心概念
在敲命令之前，请把下面这 8 个概念记牢。它们会贯穿你使用 Git 的每分每秒。
1. 仓库（Repository，简称 Repo）
存放你项目文件 + 所有改动历史的目录。一个项目对应一个仓库。
- 本地仓库：你电脑上的
.git目录及其管理的文件 - 远程仓库：托管在 GitHub / GitLab / Gitee 等平台上的副本
2. 工作区、暂存区、版本库（三区模型）
这是 Git 最核心的状态机：
四个区域的作用：
- 工作区：你正在编辑的文件
- 暂存区：已标记"下次要提交"的快照（一个中间层，让你可以精确控制哪些改动进一次提交）
- 版本库：已经提交、永久保存的历史
- 远程仓库：托管在 GitHub / GitLab / Gitee 等平台上的副本，本质是版本库的远端镜像
不理解暂存区是初学者最大的卡点。记住一句话：暂存区是"草稿箱"，版本库是"档案柜"。你可以把多个改动分批放进草稿箱，分多次提交进档案柜。
3. 提交（Commit）
一次提交 = 一个带说明的快照。每次 commit 都有一个全球唯一的哈希值（如 a1b2c3d...），是回退、对比、定位的钥匙。
4. 分支（Branch）
指向某个 commit 的轻量指针。主分支默认叫 main（老项目可能是 master）。分支存在的意义是让你在不影响主线的情况下做实验。
5. HEAD
一个特殊的"指针"，永远指向你当前所在的位置（通常是某分支的最新 commit）。
6. 远程（Remote）
本地仓库对远端仓库的"昵称"，默认叫 origin，可以配多个（如 origin + upstream）。
7. 合并（Merge）vs 变基（Rebase）
把两条分支"合到一起"的两种不同方式：
- merge：保留分支历史，会产生合并 commit
- rebase：把当前分支"接到"目标分支顶端，历史是线性的（更干净，但会改写 commit 哈希）
8. 冲突（Conflict）
两个分支对同一文件的同一行做了不同的修改，Git 会停下来让你手动决定保留哪一方。
三、环境准备：安装 Git 与注册 GitHub
1. 安装 Git
Windows
- 方式 A（推荐）：Git 官网 下载安装包，一路 Next
- 方式 B（包管理器）：
winget install Git.Git - 安装完打开 Git Bash（Git 自带的终端），后续命令都在这里敲
macOS
- 自带 Xcode Command Line Tools：
xcode-select --install - 或 Homebrew：
brew install git
Linux（Debian/Ubuntu）
sudo apt update && sudo apt install git -y
验证安装
git --version
# 输出示例：git version 2.45.0
2. 首次配置：告诉 Git 你是谁
必须配，不然无法 commit：
git config --global user.name "你的名字"
git config --global user.email "你的邮箱@example.com"
邮箱建议用 GitHub 注册邮箱，这样你的 commit 在 GitHub 上会显示头像。
常用配置项：
# 默认分支名（GitHub 新仓库默认是 main，老项目可能是 master）
git config --global init.defaultBranch main
# 中文文件名不转义（Windows 常用）
git config --global core.quotepath false
# 提交时自动转换 CRLF（推荐 Windows 用户）
git config --global core.autocrlf true
# macOS / Linux 用户
git config --global core.autocrlf input
# 漂亮的 log（强烈推荐，后面会介绍怎么配别名）
git config --global alias.lg "log --oneline --graph --decorate --all"
查看所有配置：
git config --list
3. 注册 GitHub 账号
- 打开 github.com → Sign up
- 选用户名（这会是你的个人主页域名的一部分，如
github.com/xxx，慎重） - 邮箱 + 密码 + 验证
- 建议勾选"接收产品更新邮件"（了解新功能）
4. 配置 SSH 密钥（强烈推荐，省去每次输入密码）
第一步：生成密钥
ssh-keygen -t ed25519 -C "你的邮箱@example.com"
# 一路回车，使用默认路径与空密码即可
生成的密钥文件在：
| 文件 | 用途 | 路径（Windows / macOS·Linux） |
|---|---|---|
id_ed25519 | 私钥，留在本地，绝不能泄露 | C:\Users\你的用户名\.ssh\id_ed25519 / ~/.ssh/id_ed25519 |
id_ed25519.pub | 公钥，需要上传到 GitHub | 同目录下的 .pub 文件 |
第二步：把公钥告诉 GitHub
# 查看并复制公钥内容
cat ~/.ssh/id_ed25519.pub
打开 GitHub → 右上角头像 → Settings → SSH and GPG keys → New SSH key → Title 任意，Key 类型选 Authentication，把公钥粘贴进去 → Add SSH key。
第三步：测试连通性
ssh -T git@github.com
# 首次会问是否信任，输入 yes
# 看到 "Hi <用户名>! You've successfully authenticated..." 就成功了
HTTPS vs SSH：HTTPS 每次 push 要输用户名密码（或 PAT），SSH 配置一次永久免密。强烈推荐 SSH。
四、最小工作流：3 条命令搞定本地版本管理
假设你已经在本地有一个项目目录 my-project，想用 Git 管理它。
第 1 步：初始化仓库
cd my-project
git init
执行后目录下会多出一个 .git 隐藏目录，这就是 Git 的"大脑"。
第 2 步：查看状态
git status
这是你最常用的命令之一，随时告诉你"现在哪些文件被改了、哪些被暂存了"。
第 3 步：第一次提交
# 把所有文件加入暂存区
git add .
# 提交到版本库
git commit -m "第一次提交：初始化项目"
到这里，本地 Git 仓库就建好了。完整流程如下：
完整命令行版（可直接复制执行）：
echo "# My Project" > README.md
git init
git add README.md
git commit -m "Initial commit"
git log --oneline # 查看提交历史
五、必须吃透的 12 条核心命令
下面这些命令覆盖 90% 的日常使用，务必熟记。
| 命令 | 作用 | 常用场景 |
|---|---|---|
git status | 查看工作区与暂存区状态 | 任何时候不确定"现在是什么状态" |
git add <file> | 把文件加入暂存区 | 修改后准备提交 |
git commit -m "msg" | 提交暂存区的内容到版本库 | 每次"完成一个小功能" |
git log | 查看提交历史 | 想看过去做过什么 |
git diff | 查看未暂存的改动 | 提交前确认改了什么 |
git diff --staged | 查看已暂存的改动 | 提交前最后确认 |
git restore <file> | 撤销工作区修改（未暂存） | 改错了想回退 |
git restore --staged <file> | 把文件从暂存区撤回到工作区 | add 多了想撤销 |
git reset --hard <commit> | 回退到某个 commit（危险） | 想彻底回到过去 |
git revert <commit> | 新建一个 commit 撤销指定 commit | 已推送的内容要回退 |
git stash | 临时藏起来未提交的改动 | 切分支前不想提交 |
git stash pop | 把藏起来的改动恢复回来 | 切回分支后继续改 |
详细解释与示例
git log：看历史
git log # 完整输出
git log --oneline # 每个 commit 一行（推荐）
git log --oneline --graph --all # 图形化显示所有分支
git log --author="你的名字" # 按作者过滤
git log --since="2026-01-01" # 按时间过滤
git log -p <file> # 看某个文件的全部改动历史
git diff：看差异
git diff # 工作区 vs 暂存区（未 add 的改动）
git diff --staged # 暂存区 vs 版本库（已 add 未 commit 的改动）
git diff main feature # 两个分支的差异
git diff HEAD~1 HEAD # 当前 commit vs 上一个 commit
git add：精确控制粒度
git add file.txt # 单个文件
git add dir/ # 整个目录
git add . # 当前目录下所有改动
git add -p # 交互式：逐个 hunk（代码块）选择是否 add（高级但极好用）
git commit：写好提交说明
好习惯是一行不超过 50 字的祈使句，如：
- ✅
fix: 修复用户登录失败问题 - ✅
docs: 更新 README 安装步骤 - ❌
改了点东西（太模糊） - ❌
Updated some files.（同义反复）
更复杂的多行说明：
git commit -m "feat: 增加用户导出功能" -m "- 支持 CSV 格式" -m "- 修复分页边界问题"
或者用编辑器写：
git commit # 会打开默认编辑器，写完保存关闭即提交
撤销类（重点中的重点）
# 撤销工作区的修改（文件回到上次 add 或 commit 的状态）
git restore file.txt
# 把已 add 的文件撤回到工作区（暂存区取消，但工作区保留）
git restore --staged file.txt
# 修改最后一次 commit（追加改动 / 修改说明）
git commit --amend
# ⚠️ 注意：amend 会改写 commit hash，**只对**未推送的 commit 使用
# 回退到指定 commit（--hard 会丢掉之后所有改动，慎用）
git reset --hard HEAD~1 # 回退 1 个 commit
git reset --hard a1b2c3d # 回退到指定哈希
# 安全回退（已推送到远端时用这个，会产生新 commit 撤销改动）
git revert HEAD
黄金法则：
reset用来操作本地未推送的 commit；revert用来操作已经推送到远端的 commit。
git stash：临时存放
切分支时手头还有改动没提交，又不想带过去污染分支：
git stash # 藏起来
git stash list # 查看藏起来的列表
git stash pop # 恢复并删除 stash
git stash apply stash@{0} # 恢复但不删除（可恢复多次）
git stash drop stash@{0} # 删除指定 stash
git stash clear # 清空所有 stash
六、把仓库推上 GitHub：远程协作入门
1. 在 GitHub 上创建空仓库
- 登录 GitHub → 右上角 + → New repository
- Repository name：
my-project（最好和本地目录同名） - 选 Public（公开，任何人可看）或 Private（私有）
- 不要勾选 “Add a README” / “.gitignore” / “license”（避免和本地冲突）
- 点 Create repository
2. 本地关联远端
cd my-project # 进入你的本地仓库
# 添加远程仓库（SSH 方式，推荐）
git remote add origin git@github.com:你的用户名/my-project.git
# 如果你用的是 HTTPS
# git remote add origin https://github.com/你的用户名/my-project.git
# 查看远程仓库
git remote -v
3. 第一次推送
# 推送 main 分支到 origin
git push -u origin main
# -u 是 --set-upstream 的简写，建立本地分支与远端分支的关联
# 之后只需 git push 即可
4. 后续日常推送
git add .
git commit -m "feat: xxx"
git push # 不再需要写 origin main，因为 -u 已经记住
5. 从远端拉取
git pull # 拉取并自动合并（= git fetch + git merge）
git fetch # 只拉取不合并（更安全，适合先看看远端有什么）
建议：日常用
pull，遇到不确定的远端变更用fetch先看一眼。
七、分支管理：团队协作的核心武器
分支是 Git 区别于其他版本控制系统的灵魂。它让你在不影响主线的情况下自由实验。
1. 分支的直观理解
main 在 B 之后分叉出 feature-login，你在 feature-login 上做了 C/D/E，主线 main 继续往前走到 F/G。等你做完功能后，把 feature-login 合并回 main，历史就合到一起了。
2. 常用分支命令
# 查看所有本地分支
git branch
# 查看所有分支（包括远端）
git branch -a
# 创建分支
git branch feature-login
# 切换到指定分支（旧语法）
git checkout feature-login
# 创建并切换（新语法，推荐）
git switch -c feature-login
# 或：git checkout -b feature-login
# 删除已合并的分支
git branch -d feature-login
# 强制删除未合并的分支（会丢改动，慎用）
git branch -D feature-login
# 重命名当前分支
git branch -m new-name
3. 合并分支
Merge 方式（保留历史）
# 切回主分支
git switch main
# 把 feature 分支合并进来
git merge feature-login
合并后会产生一个合并 commit，完整保留分支历史。
Rebase 方式（线性历史）
# 在 feature 分支上
git switch feature-login
git rebase main
# feature 分支的 commit 会被"重放"到 main 顶端
之后切回 main 做 fast-forward merge，历史就是干净的直线。
何时用哪个：
- 个人本地分支、还没推送：随便 rebase，历史更干净
- 多人共享的远端分支：绝对不要 rebase，会扰乱其他人的本地历史
- 不确定时：用 merge
两种方式的结果对比（同一起点 B，分支 feature 上做了 C/D/E，主线在 B 之后又走了 F）：
4. 冲突解决
当你 merge / rebase / pull 时，两个分支对同一行做了不同修改，Git 会暂停并提示：
CONFLICT (content): Merge conflict in src/app.js
Automatic merge failed; fix conflicts and then commit the result.
打开冲突文件，会看到冲突标记：
<<<<<<< HEAD
console.log("main 分支的代码");
=======
console.log("feature 分支的代码");
>>>>>>> feature-login
手动编辑保留正确内容，删除 <<<< ==== >>>> 标记，然后：
git add src/app.js
git commit # 完成合并
# 如果是 rebase，继续：git rebase --continue
5. 一个推荐的工作流（Git Flow 简化版）
适合个人 / 小团队：
| 分支 | 用途 | 从哪拉 | 合并到 |
|---|---|---|---|
main | 稳定版本 | — | — |
dev | 开发集成 | main | main |
feature/* | 新功能 | dev | dev |
fix/* | 修 bug | dev | dev |
日常节奏：在 feature/xxx 上写功能 → PR 合并到 dev → 稳定后 dev 合并到 main。
八、Pull Request：团队协作的灵魂
Pull Request（PR，GitLab 上叫 Merge Request）是 GitHub 的"代码评审"机制。
1. 典型流程
要点展开：
- Fork 主仓库（在 GitHub 网页上点 Fork）到自己的账号下
- 克隆 fork 仓库到本地：
git clone git@github.com:你的用户名/project.git - 添加上游：
git remote add upstream git@github.com:原作者/project.git - 创建分支：
git switch -c fix-bug - 改代码 →
add→commit→push到自己 fork 的fix-bug分支 - 在 GitHub 上点 Compare & pull request → 写标题和说明 → 创建 PR
- 项目维护者评审（review）→ 讨论 → 同意后合并（merge）
2. 写好 PR 说明
好的 PR 模板：
## 改了什么
- 新增 xxx 接口
- 修复 yyy bug
## 怎么测
1. 启动 xxx 服务
2. 调用 xxx 接口
3. 看到返回 zzz
## 截图 / 日志
（可选）
## 相关 Issue
Closes #123
3. Code Review 基本礼仪
- 对别人的 PR：就事论事、对代码不对人；提问而非命令（“这里我不太理解” vs “这里写错了”）
- 对自己的 PR：保持小颗粒度（一个 PR 只做一件事）；自己先 review 一遍再请求评审
九、撤销与恢复：挽救你的"误操作"
1. 撤销工作区的改动
git restore file.txt # 撤销单个文件
git restore . # 撤销所有改动
2. 撤销暂存
git restore --staged file.txt # 撤销单个文件的暂存
git restore --staged . # 撤销所有暂存
3. 撤销最后一次 commit（未推送）
git commit --amend # 改写最后一次 commit
# 或
git reset --soft HEAD~1 # 撤销 commit 但保留改动在暂存区
git reset HEAD~1 # 撤销 commit 改动回到工作区
git reset --hard HEAD~1 # 撤销 commit 并丢弃所有改动（⚠️ 危险）
4. 撤销已推送的 commit
# 生成一个新 commit 撤销指定 commit 的改动（推荐，保留历史）
git revert a1b2c3d
git push
# 或者直接回退远端分支（⚠️ 危险，会影响其他人）
git reset --hard HEAD~1
git push --force-with-lease
git push --force是危险操作，会覆盖远端历史，可能让协作者的工作丢失。优先用--force-with-lease（如果远端有你不知道的新 commit，会拒绝覆盖）。
5. 找回丢失的 commit
git reflog # 查看所有 HEAD 移动记录（30 天内）
# 找到你想要的哈希，然后
git reset --hard <哈希> # 回到那个 commit
reflog 是 Git 的"后悔药"，大多数丢失的 commit 都能从这里找回来。
6. 恢复误删的分支
git reflog | grep "分支删除前的提交"
git switch -c branch-name <哈希>
十、.gitignore：忽略不该追踪的文件
你不想把 node_modules/、__pycache__/、.env、*.log、dist/ 这些文件提交到仓库。.gitignore 就是干这个的。
1. 创建方式
- 方式 A：仓库根目录创建
.gitignore文件 - 方式 B：
hugo new site等命令会自动生成模板 - 方式 C：GitHub 仓库创建时直接选模板
2. 常用模板（按语言 / 框架）
Node.js
node_modules/
dist/
.env
npm-debug.log*
yarn-debug.log*
yarn-error.log*
Python
__pycache__/
*.py[cod]
*.egg-info/
.venv/
venv/
.env
Hugo
public/
resources/_gen/
.hugo_build.lock
通用建议
.DS_Store # macOS
Thumbs.db # Windows
*.swp # Vim
.vscode/ # VSCode 个人配置（按需）
.idea/ # JetBrains 个人配置（按需）
3. 已经被追踪的文件怎么办？
.gitignore 只对未追踪的文件生效。如果某个文件已经被 git add 过了，需要先取消追踪：
# 从版本库移除但保留本地文件
git rm --cached file.txt
# 然后提交
git commit -m "chore: 从追踪列表移除 file.txt"
4. 一行速记
| 模式 | 含义 |
|---|---|
*.log | 所有 .log 文件 |
/TODO | 根目录的 TODO 文件 |
build/ | 所有 build 目录 |
doc/*.txt | doc 目录下（不递归）的 .txt |
doc/**/*.txt | doc 目录及其子目录的所有 .txt |
!README.md | 否定，不忽略这个 |
十一、GitHub 进阶功能
1. Issue：任务与缺陷追踪
- 任何人都可以在公开仓库提 Issue
- 标题 + 描述 + 标签（bug / enhancement / question / documentation）
- 用
#123在 commit / PR 中引用，会自动建立双向链接 - 在 commit message 写
Fixes #123或Closes #123，合并 PR 后会自动关闭对应 Issue
2. Projects：看板
类似 Trello 的项目看板，可以把 Issue / PR 拖拽到不同列（Todo / In Progress / Done），适合个人任务管理。
3. Wiki：项目文档
仓库内的多页面文档系统，适合写详细文档、API 参考、FAQ。
4. GitHub Actions：自动化 CI/CD
在仓库的 .github/workflows/ 下放 YAML 文件，可以做到：
- PR 触发自动跑测试
- push 后自动部署（你正在看的 Hugo 博客就是这条链路）
- 自动发版、自动发 release notes
示例 .github/workflows/hugo.yml：
name: Deploy Hugo to GitHub Pages
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: peaceiris/actions-hugo@v3
with:
hugo-version: 'latest'
extended: true
- run: hugo --minify
- uses: actions/upload-pages-artifact@v3
with:
path: ./public
- id: deployment
uses: actions/deploy-pages@v4
5. GitHub Pages：免费静态网站
仓库 Settings → Pages → 选分支 → 即可发布静态站点。个人博客 / 项目文档最简方案。
6. Gist：代码片段
适合分享单文件 / 小段代码。
十二、常见坑与最佳实践
1. 提交粒度
- ✅ 一个 commit 只做一件事：修一个 bug / 加一个功能 / 改一处文档
- ❌ 一次 commit 改 50 个文件、跨多个功能
好粒度让你能精准回退、精准 cherry-pick。
2. 不要提交的东西
| 类型 | 例子 | 处理 |
|---|---|---|
| 编译产物 | dist/ build/ public/ | 加 .gitignore |
| 依赖 | node_modules/ vendor/ | 加 .gitignore |
| 敏感信息 | .env config.json 里的密码 | 加 .gitignore |
| IDE 配置 | .idea/ .vscode/（团队统一除外） | 加 .gitignore |
| 系统文件 | .DS_Store Thumbs.db | 加 .gitignore |
| 大型二进制 | 视频、设计稿 PSD | 用 Git LFS |
3. 已经提交了敏感信息？
立刻做两件事：
- 改密码 / 撤销凭证
- 从 Git 历史清除（用
git filter-repo或 BFG Repo-Cleaner）
只在最新 commit 改不够，必须清理历史。如果推到 GitHub 是公开仓库，敏感信息相当于已经泄露。
4. 大文件：用 Git LFS
Git 不擅长管理大型二进制文件（几十 MB 以上）。Git LFS（Large File Storage）会用指针文件替代真实内容，存到独立存储。
git lfs install
git lfs track "*.psd"
git add .gitattributes
git add *.psd
git commit -m "add design files via LFS"
5. 避免 force push 到共享分支
git push --force-with-lease # 安全版：远端没新 commit 才允许
绝对禁止 git push --force 到 main / dev 等多人协作的分支。
6. 别在主分支上直接改
永远在 feature 分支上改，PR 合并。即便是个人项目，也养成这个习惯。
7. commit message 模板
在仓库根目录放 .gitmessage：
# <type>(<scope>): <subject>
#
# body (optional)
#
# footer (optional)
# type: feat fix docs style refactor test chore
配置：
git config commit.template .gitmessage
8. 提速：别名与工具
# 配别名（写到 ~/.gitconfig 也行）
git config --global alias.st status
git config --global alias.co switch
git config --global alias.br branch
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "restore --staged"
之后 git st 就等于 git status。
9. 出错了怎么办？
任何误操作，先 git reflog。它会告诉你 HEAD 走过的每一步，绝大多数情况都能恢复。
十三、推荐学习路径
- 第一周：掌握第 1～6 节命令，足够日常提交、推送
- 第二周：学分支管理与冲突处理
- 第三周：上手一次 PR 流程（哪怕是自己的仓库）
- 第一个月：配置 SSH、
.gitignore、GitHub Actions - 持续练习：用 Git 管理一切文本内容（博客 / 笔记 / 配置文件）
推荐资源
- Pro Git 中文版（官方免费书，最权威）
- Learn Git Branching（交互式可视化练习，强烈推荐）
- Oh Shit, Git!?!（急救手册，英文）
- GitHub Docs（官方中文文档）
十四、速查表（Cheat Sheet）
仓库操作
git init # 初始化仓库
git clone <url> # 克隆远端仓库
git remote add origin <url> # 添加远程
git remote -v # 查看远程
文件操作
git status # 查看状态
git add <file> # 加入暂存区
git add . # 暂存区所有改动
git commit -m "msg" # 提交
git commit --amend # 改写最后一次 commit
git restore <file> # 撤销工作区改动
git restore --staged <file> # 撤销暂存
git rm <file> # 删除文件并暂存
git mv <old> <new> # 重命名文件并暂存
查看历史
git log # 完整历史
git log --oneline # 简洁历史
git log --graph --all # 图形化所有分支
git diff # 工作区 vs 暂存区
git diff --staged # 暂存区 vs 版本库
git show <commit> # 看某次提交详情
分支
git branch # 列出本地分支
git branch -a # 列出所有分支
git branch <name> # 创建分支
git switch <name> # 切换分支
git switch -c <name> # 创建并切换
git branch -d <name> # 删除已合并分支
git branch -D <name> # 强制删除分支
合并
git merge <branch> # 合并分支
git rebase <branch> # 变基
git rebase -i HEAD~3 # 交互式 rebase（改写最近 3 个 commit）
远程
git fetch # 拉取远端（不合并）
git pull # 拉取并合并
git push # 推送到远端
git push -u origin <branch> # 首次推送并建立关联
git push --force-with-lease # 安全强推
撤销与恢复
git reset --soft HEAD~1 # 撤销 commit 改动留暂存区
git reset --mixed HEAD~1 # 撤销 commit 改动回工作区
git reset --hard HEAD~1 # 撤销 commit 并丢弃改动
git revert <commit> # 新 commit 撤销指定 commit
git stash # 临时存放改动
git stash pop # 恢复并删除 stash
git reflog # 查看 HEAD 历史（救命用）
十五、写在最后
Git 的学习曲线前陡后缓：前 2 小时会觉得概念很多、命令记不住；用满一周后会有"豁然开朗"的感觉；用满一个月后你就再也离不开它了。
不要试图一次背完所有命令。先记住 5 条：add / commit / push / pull / status，跑起来再说。其它的查速查表或本文就好。
最后送一句 Git 社区的老话：
“Commit early, commit often, push frequently.” （早提交，多提交，常推送。）
祝你在版本控制的路上少踩坑、多享受。