Git 使用全教程：从工作区原理、现代分支命令到救命灾难恢复指南

一、问题概述：从概念混淆到版本控制的三大区域模型

Git 与传统集中式版本控制系统（如 SVN）最大的区别在于其分布式的快照存储模型。理解 Git 的关键在于厘清“三大工作区域”：工作区 (Working Directory，物理文件所在)、暂存区 (Staging Area / Index，准备提交的快照索引) 和版本库 (Git Repository / Commit History，持久化存储的节点 DAG 图)。绝大多数 Git 操作本质上都是在这三大区域之间传递与比较数据。

二、最小复现：工作区、暂存区与版本库的状态流转流程

下面的命令行代码示范了代码从修改、暂存、提交到查看历史的标准状态变更流转轨迹：

# 1. 查看当前工作区与暂存区状态

git status

# 2. 将修改从工作区添加到暂存区 (Index)
git add src/index.ts

# 3. 将暂存区快照持久化提交至版本库
git commit -m "feat: 增加用户鉴权模块"

# 4. 查看当前分支的提交拓扑历史
git log --oneline --graph

三、根因分析：现代 Git 命令分离 (git switch / git restore) 的演进

1. 传统 `git checkout` 的重载问题：在过去，git checkout 既承担了切换分支 (git checkout main)、创建分支 (git checkout -b dev) 的职责，又承担了丢弃工作区修改 (git checkout -- file.ts) 的功能。这种兼具分支与文件操作的重载设计极易引发误操作。2. 现代分立命令 (`git switch` 与 `git restore`)：Git 2.23+ 引入了语义更清晰的物理分离命令。切换/创建分支统一使用 git switch（如 git switch main、git switch -c feature/auth）；撤销/重置修改统一使用 git restore（如 git restore file.ts 撤销工作区，git restore --staged file.ts 撤销暂存区）。3. Merge 与 Rebase 的本质差异：git merge 通过创建新的非线性汇合 Commit 保留真实的历史时间线；而 git rebase 通过将当前分支的 Commit 在目标分支基向上逐个重放，保持干净的单干线性历史。

四、推荐方案：团队安全协作规范与高危操作避坑防线

1. 优先使用现代命令：在日常操作中全面拥抱 git switch 与 git restore 替代传统的 git checkout。2. 公开分支严禁 ReBAse：切勿在已推送到公共远程仓库的分支 (如 main/master/release) 上执行 `git rebase`！这会物理改写已共享的提交 Hash，导致团队其他成员的历史断层与提交混乱。3. 安全的强推替代品：必须覆盖远程分支时，使用 git push --force-with-lease 替代危险的 git push --force。如果他人在此期间推送了新代码，--force-with-lease 会安全拒绝覆盖。4. 慎用 git reset --hard：git reset --hard 会物理抹杀工作区所有未提交的修改，且无法通过提交历史直接找回！操作前务必执行 git stash 暂存数据。

五、完整代码：基于 git reflog 的误删分支与硬重置 disaster 救命恢复流程

下面的步骤示范当误执行 git reset --hard 或误删分支时，如何利用 Git 的底层引用日志 reflog 紧急救回代码。

# 场景: 不小心执行了 git reset --hard HEAD~3，丢弃了最近 3 次重要的 Commit！


# 1. 救命第一步: 打印本地绝不丢失的底层引用变动日志 (Reflog)
git reflog

# 输出示例:
# e4a21d8 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
# a1b2c3d HEAD@{1}: commit: feat: 完成核心算法优化  <-- 这是我们丢弃的节点！
# f9e8d7c HEAD@{2}: commit: feat: 增加接口校验

# 2. 方案 A: 通过恢复 Commit Hash 直接将 HEAD 重置会丢失前的位置
git reset --hard a1b2c3d

# 3. 方案 B: 如果误删了本地 feature 分支，基于 Reflog 的 Hash 重新拉出分支
git switch -c recovered-feature a1b2c3d

# 提示: 只要 Commit 曾经被提交过，即使分支被删，它的 Blob 对象在 30 天内仍安全存在于 .git 目录中！

六、常见错误方案

在公共协作分支上执行 git rebase 改写历史；遇到冲突时直接暴力删除冲突标记代码而未进行业务逻辑对齐；在没有暂存未提交修改的情况下直接执行 git reset --hard；误将敏感配置文件 (.env / 私钥) 提交至仓库后仅使用 git rm 删除（敏感信息仍永久保留在历史记录中）。

七、边界条件：冲突解决 (Conflict Resolution) 与 .gitignore 规则失效

遇到冲突时，Git 会在文件中插入 <<<<<<< HEAD、======= 与 >>>>>>> 标记。解决冲突后必须重新执行 git add 将文件标记为已解决，然后再执行 git merge --continue 或 git rebase --continue。若遇到已被版本库跟踪的文件无法被 .gitignore 忽略，必须先执行 git rm --cached <file> 移除版本库跟踪。

八、如何进行仓库健康度检测与清理

运行 git status 确保工作区干净；使用 git branch -d 清理已合并的本地废弃分支；使用 git remote prune origin 清理远程已删除的分支本地引用；对于误提交的大文件或敏感信息，使用 git filter-repo 或 BFG Repo-Cleaner 清理历史。

九、FAQ

问：git pull 和 git fetch 有什么差别？答：git fetch 仅从远程仓库下载最新节点与分支引用，不会改变你本地的工作区；而 git pull 等价于 git fetch + git merge（或者 git pull --rebase 等价于 git fetch + git rebase）。

问：不小心 commit 了敏感密码，该怎么处理？答：如果是刚 Commit 且尚未 Push，使用 git reset --soft HEAD~1 回退提交并将密码从文件中清除；如果已经 Push，必须立即修改线上密码，并使用 git filter-repo 物理擦除历史。

问：git stash pop 和 git stash apply 有什么不同？答：stash pop 在恢复暂存修改的同时会物理删除该 stash 记录；而 stash apply 会恢复修改但依然保留该 stash 记录在列表中。

十、总结

掌握 Git 三大区域模型、拥抱现代 git switch/restore 命令、恪守“公共分支绝不变基”原则，并学会利用 git reflog 救命，是打造高效、安全版本控制工作流的必备能力。