Git 从入门到进阶：分支、合并、撤销与救命命令

这篇文章目标是让你对 Git 有稳定的“心智模型”：知道文件改动在 工作区/暂存区/提交历史之间怎么流动；知道分支与合并在 PR 里发生了什么；出错时知道怎么自救。

先把图看懂：三个区域 + 两条命令链路

你可以把 Git 当成一条流水线：

• 工作区：你改文件的地方
• 暂存区：你挑选“这次要提交哪些改动”
• 提交历史：一次次提交组成的版本记录

对应到命令就是两条“搬运”路径：

• 工作区 → 暂存区：git add
• 暂存区 → 提交历史：git commit

分支到底是什么（以及 HEAD 是什么）

• 提交（commit）：一次“快照”，包含内容与父提交引用。
• 分支（branch）：本质是一个“指向某个提交的指针”（比如 main 指向提交 D）。
• HEAD：你当前所在位置的指针。通常指向某个分支（也可能直接指向某个提交，叫 detached HEAD）。

当你提交一次，当前分支指针与 HEAD 会一起向前移动。

日常工作流：从 main 拉分支到合并

1) 克隆与初始化（一次性）

git clone <repo-url>
cd <repo>
git status

建议先把默认分支更新到最新：

git checkout main
git pull

2) 开分支（每个需求一个分支）

分支名推荐能看懂用途，比如 feat/xxx、fix/xxx、docs/xxx：

git checkout -b docs/git-advanced

3) 提交：小步提交 + 写清楚信息

先看改动：

git status
git diff

只把“这次要交付的部分”加入暂存区：

git add <file>

提交信息建议遵循 Conventional Commits（很多项目会有 commit-msg 校验）：

git commit -m "docs: add git advanced guide"

4) 推送与提 PR

git push -u origin docs/git-advanced

PR 里建议写清楚：

• 为什么要改（背景/问题）
• 改了什么（要点列表）
• 怎么验证（本地如何跑、截图/录屏）

保持分支最新：fetch、pull、rebase 怎么选

三个词先翻译成人话：

• git fetch：只“下载更新”，不动你的工作区
• git pull：等于 fetch + merge（会产生一次合并提交，取决于配置）
• git rebase：把你的提交“挪到最新主线后面”，让历史更线性

常见做法（更稳，不容易误操作）：

git fetch origin
git rebase origin/main

如果项目明确要求 merge 方式（或你不熟 rebase），可以用：

git pull origin main

撤销与修复：分清“有没有 push”

这部分是最容易踩坑的：push 前你可以改历史，push 后尽量不要改历史（除非团队明确允许强推）。

1) 加错文件到暂存区（还没 commit）

git restore --staged <file>

2) 改乱了文件，想丢弃工作区改动（还没 add）

git restore <file>

3) 提交信息写错或漏文件（还没 push）

git commit --amend

4) 已经 push 了想“撤回效果”（推荐 revert）

不要轻易 reset --hard 再强推。更安全的是 revert（反向提交）：

git revert <commit-sha>

它会生成一个新提交来“抵消”旧提交，历史可追踪。

5) 救命命令：reflog（找回丢失的提交）

如果你误操作了 reset/rebase 导致提交看不到了：

git reflog

在 reflog 里找到你想恢复的 HEAD@{n} 或提交 SHA，再回退过去（谨慎使用）：

git reset --hard <sha>

冲突处理：一次就做对

冲突不是“坏事”，只是 Git 不知道你该选哪一边。

1. 先 git status 看哪些文件冲突。
2. 打开冲突文件，处理 <<<<<<< / ======= / >>>>>>> 标记。
3. 处理完后标记为已解决并提交：

git add <conflict-files>
git commit

提交前检查清单（建议照着过一遍）

• git status 干净或只包含你想提交的改动
• 提交信息能读懂：做了什么、影响哪里（例如 feat: / fix: / docs:）
• 如果你改了很多文件：确认每个改动都属于同一个 PR 主题
• PR 描述里写清楚动机、改动点、验证方式；UI 变更带截图/录屏