[Git] 文件删除
文章目录
- 告诉 Git 你删了什么
- 如果是不小心删错了文件(只用了 `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
了。
遇到这种情况,通常有两种可能:
- 你不小心删错了,想恢复这个文件。
- 你确实有意要从项目和版本库中删除这个文件。
如果是不小心删错了文件(只用了 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 [文件名]
命令做了两件事:
- 删除工作区的文件: 它会执行类似系统
rm
的操作,将指定文件从你的项目文件夹里删除。 - 将删除操作添加到暂存区: 它会自动将这个文件的“删除”操作暂存起来,标记为待提交的改动。这就像你在暂存区的清单里写上:“下次提交时,请把
file5
这个文件删除掉。”
操作演示:
假设 file5
还在工作区,并且已经被 Git 跟踪。现在我们想正式地从项目和版本库中删除它。
- 使用
git rm
命令删除文件。
# 使用 git rm 删除 file5
hyb@139-159-150-152:~/gitcode$ git rm file5
rm 'file5' # Git 会反馈它删除了哪个文件
此时,file5
已经从你的工作区消失了。
- 查看
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 已经知道你想要删除这个文件,并且已经把这个“删除”的意图记录到了暂存区,准备下一次提交时执行。
- 提交删除操作: 最后一步,就像提交任何其他修改一样,你需要
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
文件”。
- 再次查看
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 强大的历史记录功能让大部分操作都是可逆的(尤其是在本地仓库)。