skip to content
月与羽

Git 工作区

/ 9 min read

View more blogs with the tag git

三个工作区域

区域别名主要作用相关命令
工作区 (Working Directory)-实际编辑和修改文件的地方，是项目在本地文件系统中的直接视图。git status, git checkout -- <file>
暂存区 (Staging Area)索引 (Index)标记下一次提交要包含哪些文件变更的快照，它是一个位于 .git 目录中的文件。git add, git reset HEAD <file>, git status
Git 仓库 (Repository)本地仓库永久存储项目所有版本历史记录和元数据的地方，位于 .git 目录中。git commit, git push, git pull, git clone, git log

如何善用 Git 暂存区

场景 / 目标推荐操作 / 命令操作说明与带来的价值
1. 构建原子性提交
(将不同逻辑的修改分开提交)		git add <specific_file>
git commit -m "..."
(针对不同文件重复此流程)		操作说明：不使用 git add .，而是明确指定要提交的文件。例如，先 git add feature.js 提交新功能，再 git add bugfix.js 提交 Bug 修复。

带来的价值：
✅ 提交历史清晰：git log 记录整洁，每个提交都有单一、明确的意图。
✅ 便于代码审查：审查者可以逐个提交进行审查，焦点集中，效率更高。
✅ 易于问题定位与回滚：可以精确地 revert 或 reset 某个特定的提交，而不会影响到其他不相关的修改。
2. 提交前最后确认
(避免误提交调试代码或不必要的修改)		git diff --cached
(或 git diff --staged)		操作说明：在 git commit 之前，运行此命令。它会显示暂存区和最新版本库之间的差异，也就是你即将提交的内容。这是提交前的“安全检查”。

带来的价值：
✅ 防止误提交：有效避免将 console.log、临时文件、或未完成的修改错误地提交到版本库。
✅ 确保提交信息准确：通过预览，可以确保你的提交信息与实际修改内容完全匹配，避免文不对题。
3. 从暂存区移除文件
(add 错了文件，想撤回)		git reset HEAD <file>操作说明：当你不小心 git add 了一个不想提交的文件时，此命令可以将该文件从暂存区移回工作区。注意：工作区的修改会被保留，只是撤销了 add 操作。

带来的价值：
✅ 提供“反悔”机会：是 git add 的逆向操作，让你在提交前可以灵活地调整暂存区的内容，非常安全。
✅ 精细化控制：结合 git add <file> 使用，可以自由地组合你想要提交的文件集合。
4. 部分文件暂存
(一个文件内的修改想分多次提交)		git add -p <file>
(或 git add --patch <file>)		操作说明：这是暂存区的“高级玩法”。Git 会将指定文件的修改拆分成多个“块”（hunk），然后交互式地询问你是否要暂存每一块（输入 y 或 n）。

带来的价值：
✅ 极致的精细化控制：即使在一个文件里，也能将不同逻辑的修改（如：新功能代码 + 代码格式优化）分离开，实现真正的原子性提交。
✅ 保持提交的纯粹性：确保每一次提交都只包含一个逻辑单元的修改，即使这些修改在物理上位于同一个文件中。
5. 查看工作区状态
(快速了解哪些文件被修改、暂存或未跟踪)		git status
(或 git status -s / git status --short)		操作说明：这是你与暂存区沟通的“仪表盘”。它会清晰地列出：
- Changes to be committed (已暂存的文件)
- Changes not staged for commit (工作区已修改但未暂存的文件)
- Untracked files (未跟踪的新文件)

带来的价值：
✅ 全局概览：让你对当前项目的所有文件状态一目了然，是执行任何 Git 操作前的第一步。
✅ 指导下一步操作：根据 git status 的输出，你可以清楚地知道下一步应该 git add 哪个文件，或者 git checkout 哪个文件来丢弃修改。
6. 比较工作区与暂存区
(查看还未 add 的修改内容)		git diff操作说明：此命令显示工作区和暂存区之间的差异。换句话说，它告诉你“你已经修改了什么，但还没有告诉 Git 要提交这些修改”。

带来的价值：
✅ 回顾未暂存的修改：在你决定 git add 之前，可以用它来快速回顾一下自己都做了哪些改动。
✅ 与 git diff --cached 形成互补：git diff 看“未上车的”，git diff --cached 看“已上车待发车的”。两者结合，你对所有修改的掌控力就非常强了。

文件的状态变化

git status 检查当前文件状态 git add Untracked /Unmodified - → Staged git commmit - Staged → Unmodified git commit : Staged → Unmodified git commit- a 已跟踪文件 暂存并提交 git commit -amend 追加到上一次提交 git rm 从工作区和暂存区同时删除 git rm --cached 暂存区删除 工作区保留 git mv mv + git rm + git add 三合一，一步到位。 git restore <file> 放弃工作区的修改。 git restore --staged <file> 放弃暂存区修改，工作区修改不变 git diff 比较工作区与暂存区 git diff --staged 比较暂存区与仓库

git status -s

输出示例

 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt
 D docs/old.md
D  test/test_helper.rb
R  config.yml -> config.yaml
!! .env
简写 (-s)颜色提示完整 git status 输出含义与解读
M红色Changes not staged for commit
modified: <file>		未暂存的修改。文件在工作区被修改 (Y=M)，但暂存区是干净的 (X= )。
M 绿色Changes to be committed
modified: <file>		已暂存的修改。暂存区有修改 (X=M)，且工作区和暂存区一致 (Y= )。
A 绿色Changes to be committed
new file: <file>		已暂存的新文件。文件是新添加的且已暂存 (X=A)。
??红色Untracked files

<file>		未跟踪的文件。这是个新文件，Git 尚未开始管理它，它既不在暂存区也不在任何提交中。
MM绿 & 红Changes to be committed (绿色区)
Changes not staged for commit (红色区)		暂存区和工作区都有修改。一个版本被 add 进暂存区 (X=M)，之后工作区又有了新的修改 (Y=M)。
D红色Changes not staged for commit
deleted: <file>		工作区已删除。文件在工作区被删除 (Y=D)，但删除操作未通知 Git (未暂存)。
D 绿色Changes to be committed
deleted: <file>		已暂存的删除。文件通过 git rm 删除，该删除操作已暂存 (X=D)。
R 绿色Changes to be committed
renamed: <old> -> <new>		已暂存的重命名。文件通过 git mv 重命名，该操作已暂存 (X=R)。
!!灰色/默认(默认不显示，需用 --ignored)被忽略的文件。文件匹配了 .gitignore 规则，Git 会假装看不见它。