第二章：Git核心概念——工作区、暂存区、本地仓库、远程仓库
说实话，我见过太多新手在Git上栽跟头了。
他们往往一上来就敲 git add、git commit，却搞不清这些命令到底在操作什么。结果呢？代码丢了、分支乱了、提交历史一塌糊涂。嗯，我自己刚入行时也踩过这些坑。
所以这一章，咱们先把Git的四个核心区域搞清楚。说白了，你只要理解了这四个区，Git就没什么神秘的了。
2.1 四个核心区域
Git的整个工作流程，其实就是代码在这四个区域之间流转：
| 区域 | 位置 | 作用 |
|---|---|---|
| 工作区（Working Directory） | 你电脑上看到的文件夹 | 你实际编辑代码的地方 |
| 暂存区（Staging Area / Index） | 藏在 .git/index 里 |
临时存放你准备提交的改动 |
| 本地仓库（Local Repository） | .git 目录 |
保存所有已提交的历史版本 |
| 远程仓库（Remote Repository） | GitHub、GitLab 等服务器 | 团队协作的共享代码中心 |
我习惯把这四个区想象成一条流水线。你想想看：
- 工作区就是你的工作台，你在这敲代码、改文件
- 暂存区是质检台，你把改好的代码先放上去检查一下
- 本地仓库是成品仓库，质检通过后正式入库
- 远程仓库是总仓库，大家共享的版本中心
核心要点：代码必须经过「工作区 → 暂存区 → 本地仓库 → 远程仓库」这条路径，才能被Git完整管理起来。
2.2 工作区与暂存区的关系
这两个区的关系，我经常用「拍照」来比喻。
工作区是你正在摆拍的场景，暂存区是相机取景框。你调整好姿势（修改代码），然后按下快门（git add），画面就被暂存到取景框里了。但注意，这时候照片还没洗出来。
来看个实际例子：
# 1. 在工作区修改文件
echo "Hello Git" > readme.txt
# 2. 查看状态——Git告诉你文件被改了
git status
# 输出：Changes not staged for commit: modified: readme.txt
# 3. 把改动加到暂存区
git add readme.txt
# 4. 再看状态——文件已经进入暂存区
git status
# 输出：Changes to be committed: modified: readme.txt看到区别了吗？git status 的输出会明确告诉你文件在哪个区。我个人习惯每次提交前都跑一遍 git status，确认一下哪些文件要提交。这个习惯帮我避免过好几次误提交。
小技巧：如果你只想暂存某个文件的部分改动，可以用 git add -p。它会逐块询问你是否要暂存，非常灵活。我在重构大文件时经常用这个。
2.3 暂存区与本地仓库
暂存区准备好了，下一步就是提交到本地仓库。
# 把暂存区的改动提交到本地仓库
git commit -m "feat: 添加readme文件"这个操作相当于把取景框里的画面正式洗成照片，存进相册里。每次提交都会生成一个唯一的 commit ID（一串40位的SHA-1哈希值），你可以随时通过这个ID回到当时的版本。
我曾经犯过一个错误：连续改了十几个文件，然后一次性 git add . 全部暂存，最后只提交了一次。结果后来要回滚某个功能时，根本分不清哪个改动对应哪个功能。
避坑指南：我曾经因为一次提交塞了太多改动，导致同事review代码时崩溃。后来我养成了「一次提交只做一件事」的习惯。功能开发、bug修复、重构，都分开提交。这样回滚时也干净利落。
2.4 本地仓库与远程仓库
本地仓库是你自己的版本历史，远程仓库是团队的共享中心。它们之间通过 push 和 pull 来同步。
# 把本地提交推送到远程
git push origin main
# 拉取远程的最新代码
git pull origin main这里有个关键点：远程仓库不是本地仓库的备份。它们是两个独立的仓库，通过「引用」来建立联系。每个本地仓库都保存着远程仓库的「快照引用」，也就是 origin/main 这样的远程分支指针。
我见过有人把远程仓库当成U盘来用——每次改完代码就push，完全不提交到本地。这其实绕过了Git的版本管理机制。正确的做法是：先在本地提交，确认没问题了再push到远程。
2.5 四个区域的完整流转图
下面这张图展示了代码在四个区域之间的完整流转路径：
2.6 常见操作与区域对应关系
理解了四个区域，再看Git命令就清晰多了。我整理了一张对照表：
| 操作 | 影响区域 | 说明 |
|---|---|---|
git add |
工作区 → 暂存区 | 把工作区的改动放入暂存区 |
git commit |
暂存区 → 本地仓库 | 把暂存区的内容正式提交 |
git push |
本地仓库 → 远程仓库 | 把本地提交推送到远程 |
git pull |
远程仓库 → 本地仓库 + 工作区 | 拉取远程代码并合并到工作区 |
git fetch |
远程仓库 → 本地仓库 | 只拉取，不合并到工作区 |
git reset |
本地仓库 → 暂存区 / 工作区 | 撤销提交或暂存 |
git checkout |
本地仓库 → 工作区 | 切换分支或恢复文件 |
我的建议：刚开始用Git时，每次操作前先想想「我现在在操作哪个区？下一步要去哪个区？」。想清楚了再敲命令，能避免90%的误操作。
2.7 一个完整的实战场景
最后，咱们用一个完整的场景把四个区域串起来。假设你要给项目加一个新功能：
- 工作区：打开编辑器，修改
app.js和style.css - 暂存区：用
git add app.js style.css把这两个文件放入暂存区 - 本地仓库：用
git commit -m "feat: 添加用户登录功能"提交到本地仓库 - 远程仓库：用
git push origin feature/login推送到远程仓库
你看，整个过程就是代码在四个区之间「旅行」。每一步都有明确的目的地，每一步都有对应的命令。
我记得有一次，团队里有个新人直接在工作区改了代码，然后问我「为什么我改了代码，别人看不到？」。我告诉他：你只是在工作台上摆弄了一下，还没拍照（暂存）、没洗照片（提交）、没寄出去（推送），别人当然看不到。
这个比喻他一下就懂了。
本章小结：
- 工作区是你写代码的地方
- 暂存区是提交前的「质检台」
- 本地仓库是你的私人版本历史
- 远程仓库是团队的共享中心
- 代码必须按「工作区→暂存区→本地仓库→远程仓库」的顺序流转
下一章，咱们聊聊Git的分支模型。分支是Git最强大的功能之一，也是很多人容易搞混的地方。到时候我会分享一些我在分支管理上的实战经验。