4、Git基本工作流程：工作区、暂存区、本地仓库的概念与关系
Git作为分布式版本控制系统的核心，其日常操作围绕三个关键区域展开：工作区（Working Directory）、暂存区（Staging Area/Index）和本地仓库（Local Repository）。理解这三者之间的流转关系，是掌握Git一切高级操作的基础。许多初学者在刚接触Git时，常常混淆commit与add的作用，或者不清楚status输出信息的含义，根源就在于没有建立起这三个区域的清晰心智模型。本章将深入剖析这三个区域的概念、职责与协作机制，并通过核心命令的实战演示，帮助你构建起对Git工作流的系统性认知。
上图清晰地展示了Git三大区域之间的流转关系。工作区是你直接编辑文件的目录，暂存区是一个中间缓冲区，用于汇总你希望纳入下一次提交的变更，而本地仓库则保存着所有历史提交的永久快照。下面我们将逐一深入每个区域，并掌握与之对应的核心命令。
4.1 核心原理：三个区域，三种状态
Git的设计哲学中，文件在任意时刻都处于以下三种状态之一：已修改（Modified）、已暂存（Staged）和已提交（Committed）。这三种状态恰好对应了三个区域。
- 工作区（Working Directory）：即你电脑上能看到的项目文件夹。这里存放着从仓库中检出的实际文件。当你用编辑器修改代码时，文件就处于“已修改”状态，但这些改动尚未被Git跟踪。
- 暂存区（Staging Area）：这是一个位于
.git目录下的索引文件（Index），可以理解为一张“待提交清单”。当你执行git add后，Git会将工作区中文件的当前快照（而非文件本身）写入暂存区。此时文件处于“已暂存”状态，表示你已确认这些改动。 - 本地仓库（Local Repository）：位于
.git目录中，是Git的核心数据库。当你执行git commit时，暂存区中的快照会被永久性地打包成一个提交对象，存入仓库。此时文件处于“已提交”状态，意味着该版本已被安全保存。
关键认知：暂存区保存的是文件快照，而不是文件差异。这意味着每次git add都会记录该文件在那一刻的完整内容。如果你在add之后又修改了文件，那么工作区中的新改动不会自动出现在暂存区，需要再次add才能更新快照。
4.2 核心命令操作流程与判断方法
掌握四个核心命令——status、add、commit、log——是驾驭Git工作流的第一步。下面通过一个标准操作流程来理解它们的作用。
4.2.1 查看状态：git status
git status是使用频率最高的命令，它告诉你工作区和暂存区的当前状态。通过它，你可以判断文件处于哪种状态，以及下一步应该执行什么操作。
# 查看完整状态
git status
# 查看简洁状态（每个文件一行，更紧凑）
git status -s输出信息通常分为两部分：Changes to be committed（已暂存）和 Changes not staged for commit（已修改未暂存）。如果存在未跟踪文件（Untracked files），也会单独列出。
4.2.2 暂存变更：git add
git add将工作区的改动添加到暂存区。你可以添加单个文件、多个文件或整个目录。
# 添加单个文件
git add index.html
# 添加多个文件
git add src/app.js src/utils.js
# 添加当前目录下所有改动（包括新增、修改、删除）
git add .
# 添加所有以 .js 结尾的文件
git add *.js风险提示：使用git add .时需格外小心。它会将所有改动（包括你可能不想提交的临时文件、日志文件等）全部加入暂存区。建议养成先git status查看，再精确添加文件的习惯。
4.2.3 提交快照：git commit
git commit将暂存区的快照永久保存到本地仓库。每次提交都需要附带一条清晰的提交信息，说明本次改动的目的。
# 提交并附加信息（推荐方式）
git commit -m "feat: 添加用户登录功能"
# 提交时跳过暂存区（仅对已跟踪文件有效，不推荐新手使用）
git commit -am "fix: 修复首页样式错乱"提交信息规范建议遵循Conventional Commits约定，例如：feat（新功能）、fix（修复）、docs（文档）、refactor（重构）等。
4.2.4 查看历史：git log
git log用于查看提交历史。它展示了每次提交的哈希值、作者、日期和提交信息。
# 查看完整日志
git log
# 查看简洁日志（每个提交一行）
git log --oneline
# 查看最近5条提交
git log -5
# 以图形化方式查看分支合并历史
git log --graph --oneline --all4.3 实战场景：一次完整的迭代开发流程
假设你正在开发一个电商网站，需要新增“购物车”功能。以下是一个典型的操作闭环，展示了三个区域如何协同工作。
| 步骤 | 操作 | 命令 | 区域变化 |
|---|---|---|---|
| 1 | 创建新文件 cart.js 并编写代码 |
touch cart.js + 编辑 |
工作区出现未跟踪文件 |
| 2 | 查看当前状态 | git status |
看到 cart.js 在 Untracked 列表 |
| 3 | 将新文件加入暂存区 | git add cart.js |
文件变为已暂存状态 |
| 4 | 修改已有的 app.js 引入购物车模块 |
编辑 app.js |
工作区中 app.js 变为已修改 |
| 5 | 再次查看状态 | git status |
看到 cart.js 已暂存，app.js 已修改未暂存 |
| 6 | 将 app.js 也加入暂存区 |
git add app.js |
两个文件均处于已暂存状态 |
| 7 | 提交本次改动 | git commit -m "feat: 新增购物车功能" |
快照存入本地仓库，工作区和暂存区清空 |
| 8 | 查看提交历史 | git log --oneline |
看到最新提交记录 |
在这个流程中，你可能会遇到一个常见问题：在步骤6之后，你又修改了cart.js，但忘记重新add。此时执行commit，提交的将是暂存区中旧版本的cart.js，而工作区中的新改动仍然处于“已修改”状态。这就是为什么在提交前务必执行git status确认所有期望的改动都已暂存。
经验建议：在每次commit之前，养成执行git diff --cached的习惯。该命令会显示暂存区与本地仓库之间的差异，让你在提交前最后确认一遍即将保存的内容。
4.4 常见误区与总结复盘
理解三个区域后，许多初学者的困惑便迎刃而解。以下是几个高频误区，需要特别留意。
- 误区一：认为
commit会保存工作区所有改动。实际上，commit只保存暂存区中的内容。未add的改动不会被提交。 - 误区二：混淆
git add与git commit的作用。add是“挑选”改动，commit是“打包”改动。前者可以多次执行，后者每次生成一个不可变的版本。 - 误区三：忽略
git status的输出。很多人在提交后才发现漏掉了文件，或者提交了不该提交的文件。频繁使用status是避免此类问题的有效手段。 - 误区四：滥用
git commit -am。该命令会跳过暂存区，直接提交所有已跟踪文件的改动。对于新增的未跟踪文件无效，且容易误提交不需要的改动。建议在完全理解其行为后再使用。
总结来看，Git的基本工作流程可以概括为：在工作区修改 → 用git add挑选改动到暂存区 → 用git commit将暂存区快照固化到本地仓库 → 用git log查看历史。这个循环构成了日常开发的基础。理解三个区域的状态流转，不仅有助于避免操作失误，更是后续学习分支管理、远程协作、版本回退等高级功能的基石。建议你在本地练习时，每执行一步操作就运行git status观察状态变化，直到形成肌肉记忆。