[Git] 文件删除

文章目录

• • • [告诉 Git 你删了什么](#告诉 Git 你删了什么)
    • • [如果是不小心删错了文件（只用了 `rm` 删除）](#如果是不小心删错了文件（只用了 rm 删除）)
      • 如果确实要从版本库中删除该文件（有意删除）
    • 总结：如何处理删除文件

在 Git 里，"删除文件"也被看作是一种 修改 ，需要被版本控制系统追踪和记录。

告诉 Git 你删了什么

如果你只是在你的操作系统文件管理器里，或者在终端里使用 rm 命令删除了一个文件，Git 是会立刻察觉到的。

场景： 假设你的项目里有一个文件 file5，它已经被 Git 跟踪（也就是说，你之前 add 并 commit 过它）。现在你直接用系统的删除命令把它删了：

# 确保 file5 存在于工作区
hyb@139-159-150-152:~/gitcode$ ls
file1 file2 file3 file4 file5 ReadMe

# 使用系统命令删除 file5
hyb@139-159-150-152:~/gitcode$ rm file5

此时，file5 已经从你的工作区消失了。

查看 Git 状态： Git 立刻会发现工作区和它记录的状态不一致了。

hyb@139-159-150-152:~/gitcode$ git status
On branch master
Changes not staged for commit: # 未暂存的修改
  (use "git add/rm <file>..." to update what will be committed) # Git 提示你可以用 git add 或 git rm 来更新暂存区
  (use "git restore <file>..." to discard changes in working directory) # Git 提示你可以用 restore 恢复文件
        deleted: file5 # Git 发现 file5 被删除了！

no changes added to commit # 暂存区没有改动

git status 告诉你，file5 被删除了，而且这个删除操作是"未暂存的"（Changes not staged for commit）。这就像你从办公桌上拿走了文件，但还没告诉仓库管理员（Git）。

此时，Git 版本库中（那个 .git 文件夹里）的历史版本是包含 file5 的，暂存区也是基于上一次提交的状态，认为应该有 file5。只有你的工作区没有 file5 了。

遇到这种情况，通常有两种可能：

1. 你不小心删错了，想恢复这个文件。
2. 你确实有意要从项目和版本库中删除这个文件。

如果是不小心删错了文件（只用了 rm 删除）

这是第二种情况，文件只在工作区被删了。别担心，Git 的强大之处就在于它记录了历史！只要这个文件在你的版本库中存在过（至少在最近一次提交中存在），你就可以轻松恢复它。

命令： git checkout -- [文件名]

这个命令我们刚刚在"撤销修改"中学习过，它能用暂存区或版本库中的文件版本覆盖工作区的文件。在这里，它会用版本库中最新提交的 file5 版本，把它复制回你的工作区。

操作演示：

我们接上面的例子，file5 已经被 rm 删除了，git status 显示 deleted: file5。

# 恢复误删的 file5
hyb@139-159-150-152:~/gitcode$ git checkout -- file5

# 再次查看文件列表，file5 回来了！
hyb@139-159-150-152:~/gitcode$ ls
file1 file2 file3 file4 file5 ReadMe

# 查看 Git 状态，工作区又干净了
hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean

成功恢复了误删的文件！这再次体现了 Git 记录历史的价值。

如果确实要从版本库中删除该文件（有意删除）

这是第一种情况，你确实想把这个文件从项目中移除，并且要把这个"删除"操作记录到版本历史中。仅仅使用 rm 只删除了工作区的文件，Git 并不知道你是有意删除，它只是标记为"工作区文件不见了"。

要告诉 Git 你是有意删除 ，并且要将这个删除操作添加到暂存区，以便下次提交时记录这个删除，你需要使用 git rm 命令。

命令： git rm [文件名]

它的原理： git rm [文件名] 命令做了两件事：

1. 删除工作区的文件： 它会执行类似系统 rm 的操作，将指定文件从你的项目文件夹里删除。
2. 将删除操作添加到暂存区： 它会自动将这个文件的"删除"操作暂存起来，标记为待提交的改动。这就像你在暂存区的清单里写上："下次提交时，请把 file5 这个文件删除掉。"

操作演示：

假设 file5 还在工作区，并且已经被 Git 跟踪。现在我们想正式地从项目和版本库中删除它。

1. 使用 git rm 命令删除文件。

# 使用 git rm 删除 file5
hyb@139-159-150-152:~/gitcode$ git rm file5
rm 'file5' # Git 会反馈它删除了哪个文件

此时，file5 已经从你的工作区消失了。

2. 查看 git status 状态：

hyb@139-159-150-152:~/gitcode$ git status
On branch master
Changes to be committed: # 待提交的修改
  (use "git restore --staged <file>..." to unstage) # Git 提示可以用 restore --staged 撤销暂存
        deleted: file5 # 看！删除操作已经在暂存区里了！

git status 显示 file5 处于 "Changes to be committed" 区域下的 deleted 状态。这说明 Git 已经知道你想要删除这个文件，并且已经把这个"删除"的意图记录到了暂存区，准备下一次提交时执行。

3. 提交删除操作： 最后一步，就像提交任何其他修改一样，你需要 commit 暂存区的删除操作，将它永久记录到版本库中。

# 提交暂存区的删除操作
hyb@139-159-150-152:~/gitcode$ git commit -m"deleted file5"
[master 5476bde] deleted file5 # 生成新的提交
 1 file changed, 0 insertions(+), 0 deletions(-) # 本次提交改动了 1 个文件，没有增删行（因为是删除）
 delete mode 100644 file5 # 看！Git 记录了这个文件的删除模式

提交成功！这个提交就记录了"在此时此刻，我删除了 file5 文件"。

4. 再次查看 git status：

hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean # 工作区和暂存区又干净了

现在，file5 文件已经从你的工作区移除了，并且在 Git 的版本历史中，从这个提交开始，这个文件就不存在了。但是，在这个提交之前的历史版本 中，file5 仍然是存在的，你随时可以回退到之前的版本或者单独拿出之前版本的 file5 文件。

总结：如何处理删除文件

• 如果你只是在工作区 删除了一个已被 Git 跟踪的文件（比如用 rm），git status 会显示为未暂存的删除。
  • 想恢复 它：使用 git checkout -- [文件名]。
  • 想确认删除并提交 ：先使用 git add [文件名] 或 git rm [文件名] (推荐 git rm，一步到位) 将删除操作暂存，然后 git commit。
• 如果你想正式地 将一个文件从项目和版本库中删除，使用 git rm [文件名] 命令。它会删除工作区文件并暂存删除操作，然后你需要 git commit 来记录这次删除。

理解了这两种删除场景及其处理方法，你就能更自如地管理文件，避免误操作的烦恼。删除文件在 Git 里并不可怕，因为 Git 强大的历史记录功能让大部分操作都是可逆的（尤其是在本地仓库）。