0. 核心概念：Git 的三个空间
理解这三个地方，你就懂了 Git 的一半：
- 工作区 (Working Directory)：你现在的文件夹，你正在写代码、改 Markdown 的地方。
- 暂存区 (Staging Area)：“购物车”。你把想提交的文件先放进来 (
git add)，准备结账。 - 仓库 (Repository)：“历史存档”。提交后 (
git commit)，文件就被永久记录在.git文件夹里了。
1. 常用配置 (一次性设置)
虽然你配过了，但备忘一下：
# 设置名字和邮箱 (这是你的身份证)
git config --global user.name "Chow Ray"
git config --global user.email "[email protected]"
# [你的特殊配置] 强制使用 GPG 签名
git config --global user.signingkey <你的KeyID>!
git config --global commit.gpgsign true
# [你的特殊配置] 指定 GPG 程序路径 (Windows)
git config --global gpg.program "E:\Program Files (x86)\GnuPG\bin\gpg.exe"
2. 日常博客更新 (快乐路径)
这是你 deploy.sh 脚本背后的逻辑：
查看状态 (GPS 导航)
不知道现在改了啥？有些啥文件变了？
git status
- 红色：文件改了，还没进购物车。
- 绿色：文件进购物车了，还没提交。
添加文件 (放入购物车)
# 添加所有变化 (最常用)
git add .
# 或者
git add -A
# 只添加某个特定文件
git add content/posts/my-post.md
提交存档 (结账)
# -m 后面跟的是说明信息
git commit -m "新增了一篇关于 Git 的文章"
# [你的特殊用法] 带 GPG 签名 (如果你全局没开自动签名)
git commit -S -m "带签名的提交"
推送到服务器 (上传)
# 推送到远程仓库 (origin) 的主分支 (master)
git push origin master
拉取更新 (同步)
写博客前必做！ 防止和手机端的修改冲突。
git pull origin master
3. 后悔药 (撤销与回滚)
这是新手最需要的救命药丸。
写错了，还没 add (撤销工作区的修改)
比如你把 config.yml 改乱了，想恢复成上次提交的样子：
git restore config.yml
# 或者旧写法: git checkout -- config.yml
add 错了，想拿出来 (撤出暂存区)
把文件放进购物车了，想拿出来，但不删除文件内容：
git restore --staged config.yml
# 或者旧写法: git reset HEAD config.yml
提交信息写错了，想改 (修补上一次提交)
刚 commit 完发现有错别字，或者少 add 了一个文件，不想多产生一条 commit 记录：
# 1. 修改文件并 git add (如果需要)
# 2. 运行修补命令
git commit --amend -m "这是修正后的提交信息"
彻底回滚 (时光倒流 - 危险 ⚠️)
放弃本地所有修改，强制回到远程仓库的状态（比如脚本跑崩了）：
# 慎用！这会删除你所有未提交的稿子
git reset --hard origin/master
4. 纸片模组 (Submodules) 专用
因为你的 themes/PaperMod 是子模块，这块要专门讲。
第一次拉取带子模块的仓库
如果你换了新电脑，Clone 下来后发现主题文件夹是空的：
# 初始化并拉取子模块
git submodule update --init --recursive
升级 PaperMod 主题 (手动命令版)
如果你不想用小乌龟，想用命令行装 X：
# 1. 更新子模块到远程最新版
git submodule update --remote --merge
# 2. 回到根目录提交这个变化
git add themes/PaperMod
git commit -m "Update theme"
5. 极客查阅 (Log & Diff)
查看提交历史
# 简略版，一行一条，看得很爽
git log --oneline --graph --decorate
# [你的特殊用法] 查看 GPG 签名状态
git log --show-signature -1
查看具体改了什么
# 还没 add 的时候，查看改动
git diff
# 已经 add 了，查看将要提交的改动
git diff --staged
💡 常用命令速查表 (Cheat Sheet)
| 场景 | 命令 | 解释 |
|---|---|---|
| 开始工作前 | git pull | 从服务器拉取最新进度 |
| 看一眼情况 | git status | 现在的状态（红/绿） |
| 保存进度 | git add . | 全部放入暂存区 |
| 确认保存 | git commit -m "xxx" | 提交生成版本号 |
| 上传云端 | git push | 发送到 GitHub |
| 放弃修改 | git restore <文件> | 把文件恢复原状（慎用） |
| 修改上次提交 | git commit --amend | 修正上一次的 Commit 信息 |
| 查看签名 | git log --show-signature | 检查 GPG 签名是否成功 |
🎁 git pull (拉取) 和 git fetch (获取) 有什么不同？
这是一个非常经典，也是最容易混淆的 Git 概念。
用一句工科男能秒懂的公式来解释：
git pull(拉取) =git fetch(获取) +git merge(合并)
1. 通俗易懂的“快递”比喻
想象你在网上买了一堆新书（GitHub 上的更新），寄到了你家楼下的智能快递柜（你本地的 .git 仓库隐藏目录）。
git fetch(获取)：- 动作：你去快递柜看了一眼，确认“哦，货到了，有 3 本书”。
- 结果：你知道有更新了，但书还在柜子里。你家书桌上（你的工作目录）还是原来的样子，没有任何变化。
- 安全性：100% 安全。无论 GitHub 上变成了什么样，都不会影响你正在写的代码。
git pull(拉取)：- 动作：你把书从快递柜里拿出来，直接倒在你的书桌上，并且试图把你正在读的书替换掉。
- 结果：你的工作目录直接变成了最新的样子。
- 风险：如果你书桌上原本就摊着一本书（本地有修改），新书倒下来可能会把旧书压坏，或者混在一起（冲突 Conflict）。
2. 深度技术对比
| 维度 | Fetch (获取) | Pull (拉取) |
|---|---|---|
| 动作对象 | 只更新 .git/ 数据库 | 更新 .git/ + 当前工作文件 |
| 对代码的影响 | 无 (你的代码纹丝不动) | 有 (你的代码会变) |
| 网络操作 | 下载数据 | 下载数据 |
| 是否可能冲突 | 绝不 | 可能 (如果两边都改了同一行) |
| 适用场景 | 想看看别人改了啥，但不想合并 | 确定没问题，同步最新进度 |
3. 在你的博客场景中
场景 A：日常写作（手机写完，电脑接着写）
- 推荐：
git pull。 - 理由：你很清楚手机改了文章 A，电脑上还没动。直接 Pull 下来，接着写，效率最高。你的
deploy.sh脚本里用的就是这个。
场景 B：解决冲突（手机改了 A，电脑也改了 A）
- 推荐：先
git fetch。 - 理由：
- 你运行
git pull报错了，提示冲突。 - 这时运行
git fetch，把远程的变化下载到本地数据库（但不合并）。 - 然后你可以用 TortoiseGit 的“比较 (Diff)”功能，对比一下
origin/master(远程) 和master(本地) 到底哪里不一样。 - 看清楚后，再决定怎么合并。
- 你运行
👨🏻⚖️ PM 的总结
- Fetch 是 “侦察兵”：只看不动，安全第一。
- Pull 是 “搬运工”：连搬带拆，简单粗暴。
对于个人博客，99% 的情况直接用 Pull 没问题；只有当你发现报错了，才需要用 Fetch 来进行“外科手术式”的排查。