你每天敲
git add .的时候，有没有想过——这个命令远比你想象的要强大得多？在多数人的认知里，git add不过是个“把文件放进暂存区”的工具。但事实上，它能让你做到的事情远超于此：按代码块精确暂存、拆分混合修改、强制添加被忽略的文件、用交互式界面管理整个暂存过程……
如果你对
git add的理解还停留在git add .和git add <文件名>这两个命令上，那这篇文章就是为你准备的。
一、理解git add：它到底在做什么？
在深入具体用法之前，先搞清楚一个根本问题：git add到底在做什么？
git add命令将工作目录中的内容添加到暂存区域（或称为“索引”）中，以备下一次提交。它在你工作目录和Git 暂存区之间起着至关重要的桥梁作用。
Git 的版本控制模型包含三个核心区域：
工作区（Working Directory）：你实际编辑文件的地方
暂存区（Staging Area / Index）：准备提交的更改的“候选清单”
本地仓库（Local Repository）：已提交的永久历史记录
git add的本质：将工作区的更改“搬”到暂存区。它让你可以有选择地决定哪些文件和更改将被跟踪并提交。git commit默认只查看暂存区域，因此git add用于精心编排下一次提交快照的确切内容。
Git 允许在提交前多次执行git add命令。但需要注意的是，它仅在运行 add 命令时添加指定文件的内容；如果要在下一次提交中包含后续更改，必须再次运行git add将新内容添加到索引中。
📌核心概念：
git add不是“复制”文件，而是“记录快照的引用”。Git 在内部保存的是文件的哈希值和元数据，而不是完整复制一份文件。这就是为什么 Git 仓库可以高效地管理成千上万个文件版本。
二、基础用法：每天都在用的那些命令
2.1 暂存单个文件
bash
git add index.html
将指定的单个文件添加到暂存区。
2.2 暂存多个特定文件
bash
git add file1.txt file2.js file3.py
一次暂存多个指定的文件。
2.3 暂存当前目录下所有更改（最常用）
bash
git add .
暂存当前目录下所有已修改和新增的文件。这是绝大多数人最常用的命令，但也是最危险的命令之一——它会一股脑地把当前目录下的所有改动全部暂存。
2.4 暂存整个项目的所有更改
bash
git add -A
暂存整个项目中的所有更改，包括新增、修改和删除。与git add .的区别在于：.add只作用于当前目录及子目录，-A作用于整个仓库。
2.5 仅暂存已跟踪文件的更改
bash
git add -u
仅添加已跟踪文件的更改（修改和删除），不包括新增的未跟踪文件。这在你想提交对已有文件的修改、但不想把新文件也一起提交时非常有用。
2.6 使用通配符匹配文件
bash
git add '*.js'
添加所有符合特定模式的文件。上例将添加所有.js文件。
2.7 添加指定路径下的所有更改
bash
git add :/path/to/directory/
使用:/{path}语法，可以递归地添加指定目录及其子目录中的所有更改。
三、撤销操作：add 错了怎么办？
这是每个开发者都会遇到的情况：不小心git add了不该 add 的文件，或者把本应分两次提交的改动一起 add 了。
3.1 使用git restore --staged（Git 2.23+，推荐）
bash
# 撤销单个文件的暂存 git restore --staged <文件名> # 撤销所有暂存的文件 git restore --staged .
git restore --staged会将文件从暂存区移除，但保留工作区中的所有修改。换句话说，文件回到“已修改但未暂存”的状态。
如果你同时还想丢弃工作区的修改，可以省略--staged参数：
bash
git restore <文件名>
⚠️警告：这个操作无法撤销，修改的数据将永久丢失。
3.2 使用git reset（所有 Git 版本通用）
bash
# 撤销特定文件的暂存 git reset HEAD <文件名> # 撤销所有暂存 git reset HEAD .
git reset与git restore --staged效果相同，都是将文件从暂存区移除。HEAD指向当前分支的最新提交，git reset HEAD <文件>的意思是把暂存区重置到最新提交的状态——也就是把该文件“踢出”暂存区。
3.3 使用git rm --cached
bash
git rm --cached <文件名>
将文件从暂存区中删除，但保留在工作区中。这个命令的特殊之处在于，它适用于移除已被 Git 跟踪但你想停止跟踪的文件（比如不小心 add 了配置文件）。
3.4 三种撤销方式的对比
| 命令 | Git 版本要求 | 效果 | 适用场景 |
|---|---|---|---|
git restore --staged | 2.23+ | 从暂存区移除，保留工作区修改 | 现代 Git 首选 |
git reset HEAD | 所有版本 | 从暂存区移除，保留工作区修改 | 旧版 Git 兼容方案 |
git rm --cached | 所有版本 | 从暂存区移除，停止跟踪该文件 | 移除不该被跟踪的文件 |
📌核心原则：撤销
git add只会将文件移出暂存区，不会影响工作区中已修改的文件内容。如果你已经 commit 了，需要用git revert或git reset --hard来处理——但那是另一篇文章的话题了。
四、交互式暂存（git add -i）：把多个命令集合在一起
当你面对大量文件变更，想精细地管理暂存过程时，git add -i是绝佳选择。
运行git add -i或git add --interactive，Git 会进入一个交互式终端模式：
text
$ git add -i staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb *** Commands *** 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp What now>
这个界面以非常不同的视图显示了暂存区状态——暂存的修改列在左侧，未暂存的修改列在右侧。命令区域提供了 8 个功能选项：
| 命令 | 功能 |
|---|---|
1或s | 查看状态（status） |
2或u | 暂存文件（update） |
3或r | 取消暂存（revert） |
4或a | 添加未跟踪文件（add untracked） |
5或p | 补丁模式（patch）——暂存文件的一部分 |
6或d | 查看暂存内容的差异（diff） |
7或q | 退出（quit） |
8或h | 帮助（help） |
实际使用示例：
暂存文件时，输入2或u，Git 会显示所有文件并询问你要暂存哪些：
text
What now> u staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb Update>> 1,2
输入1,2后，选中的文件前面会出现*标记。按回车确认，这些文件就被暂存了。
取消暂存类似，使用3或r命令。查看改动则使用6或d命令进入 diff 模式。
💡交互式暂存的最大优势：将多个命令集合在一起，每个功能都以交互形式展现，降低了搞错几率的可能性。
五、补丁模式（git add -p）：精确到代码块的终极控制
如果说git add -i是文件级别的精细控制，那git add -p（patch 模式）就是代码行级别的“手术刀”。
git add -p会将工作区中的更改逐个代码块（hunk）展示，并询问你是否要将其添加到暂存区。这意味着你可以在同一个文件中选择性地暂存部分修改，而跳过另一些修改。
5.1 基本用法
bash
git add -p <文件名>
如果不指定文件名，Git 会逐个展示所有有更改的文件。
5.2 交互选项
在补丁模式下，Git 会显示每个代码块（hunk）的差异，然后等待你的决策：
| 选项 | 含义 | 使用场景 |
|---|---|---|
y | 暂存此代码块（yes） | 这个改动是你想要的 |
n | 跳过此代码块（no） | 这个改动不想提交 |
s | 拆分代码块（split） | 一个 hunk 包含多个逻辑改动 |
e | 手动编辑代码块（edit） | 精确到行级别的控制 |
q | 退出（quit） | 不想继续了 |
? | 帮助 | 查看所有选项 |
5.3 实战场景：拆分混合修改
假设你在app.js中同时做了两件事：
修复了一个 Bug（第 10-15 行）
添加了一个新功能（第 50-60 行）
但你只想先提交 Bug 修复，新功能想单独放一个提交。
bash
git add -p app.js
Git 会先显示 Bug 修复的代码块，你输入y暂存它。然后显示新功能的代码块，你输入n跳过它。
bash
git commit -m "fix: 修复登录按钮点击无响应问题" # 此时暂存区只有 Bug 修复 git add -p app.js # 再次进入，这次暂存新功能 git commit -m "feat: 新增用户头像上传功能"
一个文件，两次提交，逻辑完全独立。
5.4 高级技巧：手动编辑代码块
如果某个 hunk 里混杂了你想要和不想要的行，可以用e手动编辑。Git 会打开编辑器让你修改 hunk 的内容——删除不想暂存的行，只保留需要的部分。
📌核心价值：
git add -p让你告别“一锅端”提交的尴尬，是追求“原子化提交”的必备工具。
六、高级用法：你可能不知道的git add冷门选项
6.1 强制添加被忽略的文件（-f）
默认情况下，git add不会添加被.gitignore忽略的文件。但如果确实需要强制添加，可以使用-f选项：
bash
git add -f <被忽略的文件>
⚠️谨慎使用：强制添加被忽略的文件通常意味着.gitignore配置需要重新审视。
6.2 添加空文件（--intent-to-add）
bash
git add --intent-to-add <文件名>
将未跟踪的文件添加到暂存区，即使文件本身是空的。这在你计划在后续工作中创建文件时非常有用——相当于提前告诉 Git “这个文件我准备要了”。
6.3 查看将暂存的内容（--dry-run）
bash
git add --dry-run .
预览哪些文件会被暂存，但不实际执行添加操作。在不确定git add .会添加什么时，先用这个命令看一眼。
6.4 添加指定类型的更改
bash
git add --all . # 添加所有类型的更改 git add --update . # 仅添加已跟踪文件的更改
--all等同于-A，--update等同于-u。
七、最佳实践：用好git add的几条黄金法则
7.1 提交前先git status
在使用git add之前，先运行git status查看工作区和暂存区的文件状态，确保将正确的更改添加到暂存区。
7.2 用git diff确认改动
bash
git diff # 查看工作区 vs 暂存区的差异 git diff --staged # 查看暂存区 vs 上一次提交的差异
提交前用git diff --staged确认暂存区的内容就是你真正想提交的。
7.3 小而专注的提交
将相关更改分组到不同提交中。例如：
bash
# 第一次提交：只包含功能代码 git add src/feature/ git commit -m "feat: 添加用户认证功能" # 第二次提交：只包含测试代码 git add test/feature/ git commit -m "test: 添加用户认证测试"
7.4 用git add -p代替无脑git add .
当一个文件包含多个逻辑上独立的改动时，使用git add -p按 hunk 暂存，而不是一次性全部 add。
7.5 谨慎添加大型二进制文件
对于大型二进制文件（如图片、视频等），谨慎使用git add。这类文件会占用大量存储空间，Git 并不擅长处理它们。考虑使用 Git LFS 替代。
八、一张图总结
text
┌─────────────────────────────────────────────────────────────────────┐ │ git add 完整能力图谱 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 基础文件操作 │ │ │ │ git add <文件> │ git add . │ git add -A │ git add -u │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 交互式暂存 (git add -i) │ │ │ │ 1:状态 │ 2:暂存 │ 3:撤销 │ 4:添加未跟踪 │ 5:补丁 │ 6:差异 │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 补丁模式 (git add -p) - 终极精确度 │ │ │ │ y:暂存此块 │ n:跳过 │ s:拆分 │ e:手动编辑 │ q:退出 │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 撤销操作 │ │ │ │ git restore --staged │ git reset HEAD │ git rm --cached │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ 高级选项 │ │ │ │ -f 强制添加 │ --intent-to-add 空文件 │ --dry-run 预览 │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘
写在最后
git add远不止git add .那么简单。
从基础的git add <文件名>，到文件级的git add -i交互式暂存，再到代码块级的git add -p补丁模式——控制粒度越来越细，对提交质量的控制力越来越强。
用好这些能力，你的提交历史将不再是“一锅端”的混沌状态，而是逻辑清晰、原子化的高质量提交序列。而这，正是一个专业开发者与普通用户的本质区别。
下次你再敲git add的时候，想想这篇文章——你手里握着的不是一把锤子，而是一整套精密的工具箱。🔧