Git基本操作（四）：删除文件

1. 问题场景

项目进行到某个阶段，有些文件不再需要了。你可能会习惯性地直接在文件管理器里删除它，或者用系统命令 rm 删掉。然后一跑 git status，发现 Git 提示有一堆 "deleted" 的改动，但暂存区里却什么也没有，让你一时间有点混乱。这是因为删除操作本质上也是一种修改，Git 需要你明确告知"这个文件要从版本控制中移除"。

2. 核心概念

在 Git 的管理下，文件的删除不是简单地从磁盘上抹去就算完成。Git 会持续比较工作区、暂存区和版本库之间的差异。当你直接在工作区删除一个已经被跟踪的文件时，工作区与版本库之间就出现了不一致：版本库里还有这个文件，工作区却没了。Git 会检测到这个差异并告诉你文件被删除了，但不会自动把它视为一个待提交的修改，除非你通过命令将这个"删除"操作纳入暂存区。

换句话说，删除是一个需要经过 add（或者专用命令 rm）再 commit 的完整变更流程，和新增、修改文件没有本质区别。

3. 核心命令

bash 复制代码

# 从工作区和暂存区中删除文件（正确方式）
git rm <file>

# 提交删除操作，使版本库也删除该文件
git commit -m "remove file"

# 如果误删了工作区文件，从版本库恢复
git checkout -- <file>

git rm 等价于先执行系统删除，再执行 git add <被删除的文件>，它会直接把删除这个动作放入暂存区。而如果你用了系统命令 rm，那就只完成了前半部分，还需要手动 git add 来把删除记录到暂存区。

4. 实战演示

假设仓库中有一个 file_to_delete.txt 文件，已经被跟踪并提交过。

4.1 正确删除流程

bash 复制代码

$ git rm file_to_delete.txt
rm 'file_to_delete.txt'

执行后，用 git status 看一下：

bash 复制代码

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    file_to_delete.txt

删除操作已经放入暂存区，显示为 deleted。接下来提交：

bash 复制代码

$ git commit -m "remove useless file"
[master a1b2c3d] remove useless file
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 file_to_delete.txt

提交完成，版本库中这个文件的历史记录到此为止（当然，你仍然可以通过历史回溯找到它之前的内容）。

4.2 用系统命令误删后如何恢复

假如你直接用系统的 rm 删掉了文件：

bash 复制代码

$ rm file_to_delete.txt

查看状态：

bash 复制代码

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    file_to_delete.txt

Git 发现了工作区的删除，但这次它出现在 "Changes not staged for commit" 下面，说明还没有进入暂存区。如果你确实想删除，就再补一个 git add file_to_delete.txt（或者 git rm）然后提交。但如果这是误删，想恢复文件，就可以使用 Git 提示的第二条命令：

bash 复制代码

$ git checkout -- file_to_delete.txt

执行后文件就回来了，git status 也会干净如初。这个操作的本质是从版本库的最新提交中把文件取回到工作区。

4.3 两种删除方式对比

方式	工作区文件	暂存区状态	是否需要手动 add
`git rm <file>`	删除	已暂存删除操作	否
系统 `rm <file>`	删除	未暂存	是（`git add <file>`）

建议优先使用 git rm，一步到位，避免遗忘 add 而导致提交时漏掉删除操作。但如果你已经习惯用系统命令删除，也完全可以用 git add -u 一次性把所有已经跟踪的文件的删除和修改都暂存起来，效果等同。

5. 注意事项

git rm 会同时删除工作区的文件，如果文件里还有未提交的修改，Git 默认会拒绝执行，以防止数据丢失。如果确定要连修改一起删掉，可以加 -f 强制删除。
如果想保留工作区的文件，只是让它不再被 Git 跟踪（比如不小心提交了一个配置文件），可以使用 git rm --cached <file>。这个命令只会把文件从暂存区和后续的版本控制中移除，但磁盘上的文件依然存在，可以配合 .gitignore 忽略它。
误删恢复的前提是文件在版本库中有过提交记录。如果一个文件从未被 commit，只是新建在工作区，那 git checkout -- 就无法恢复它，因为 Git 根本没有这个文件的"存档"。

6. 要点总结

删除也是一种修改，需要被添加、提交，流程和新增文件完全一致。
推荐使用 git rm 直接在工作区和暂存区同时执行删除，然后 commit 完成整个操作。
如果直接用系统命令 rm 删除了文件，Git 会检测到工作区变化，需要手动 git add 补上暂存。
误删文件后，只要文件曾被提交过，就可以用 git checkout -- <file> 从版本库恢复。
git rm --cached 用于只解除跟踪但保留本地文件，适合清理误提交的配置文件等。

7. 练习题

在仓库中创建一个 test.txt 文件，写入一些内容，然后 add 并 commit。
使用 git rm test.txt 正确删除该文件，观察 git status 的输出，然后提交删除。
再次创建 test.txt 并提交。这次用系统命令 rm test.txt 删除，用 git status 查看状态，然后手动 git add test.txt 将删除放入暂存区并提交。
练习误删恢复：创建一个文件并提交，然后用 rm 删除，再用 git checkout -- 恢复。
尝试 git rm --cached：创建一个文件并提交，然后使用该命令取消跟踪，观察文件是否还在磁盘上，以及 git status 的表现。