准备删除一个旧 Git worktree（关联工作树）时，很多人会先跑一次 git status。没有待提交修改，似乎就可以放心清理了。
但这里藏着一个容易混淆的问题：“Git 没有报告变化”和“这个目录里没有需要保留的东西”，不是同一句话。
最近整理开发临时目录时，我把注意力从“它有多久没用”转向了“它是否还保存着唯一价值”。为了把判断落到实处，本文在一次性仓库里做了四组隔离实验：被忽略的本地文件、普通未跟踪文件、分支上的独有提交，以及 detached HEAD（分离头指针）上的独有提交。没有拿真实项目试删，也不把实验结果包装成一次生产事故。
最值得记住的结果是：在本次 Git 2.43.0 实测中，普通状态检查看不见的忽略文件，可以随工作树一起被移除；整个过程不需要加 --force。
一、先弄清楚：工作树不是一份独立备份
一个仓库可以挂接多个工作树，让不同分支同时出现在不同目录中。它们共享仓库中的大部分数据，但各有自己的 HEAD、索引等状态。因此，工作树适合并行开发和临时验证，却不能简单理解成互不依赖的完整备份。[1]
清理之前，至少应把三件事分开：
- 目录中的文件：包括已跟踪修改、未跟踪文件，以及被忽略规则隐藏的本地产物。
- 提交与引用：改动是否已提交，提交是否仍有明确的分支或标签承接。
- 目录的使用关系：是否还有编辑器、测试、服务或另一个任务在使用它。
前两件事可以用 Git 辅助核对；第三件事还需要回到创建这个工作树的任务。一次状态检查不可能同时替你回答这三个问题。
二、最容易漏掉的是被忽略文件
Git 的状态命令默认不列出被忽略规则排除的未跟踪文件；需要显式加入 --ignored 才会显示它们。[5]
这在日常开发中很合理。依赖目录、构建输出和本地运行文件不该天天淹没改动列表。问题在于，“不要纳入版本控制”并不等于“随时可以删除”。
比如，一次实验的原始结果、尚未转存的本地导出物，也可能被某条宽泛的忽略规则挡住。Git 不会读取文件内容，再替你判断它能不能重建。
本次实验只使用无敏感内容的演示文件：把 local-output.txt 写进已提交的 .gitignore，再在关联工作树里创建这个文件。
普通检查没有输出：
git status --porcelain=v1 --untracked-files=all
加入忽略项后，文件才出现：
git status --porcelain=v1 --untracked-files=all --ignored=matching
本次真实输出为：
!! local-output.txt
随后，仅在这个一次性实验目录中执行普通的 git worktree remove，命令成功，目录与其中的演示文件一并消失。实验没有使用强制删除参数。
所以，“我没有用强制删除”也不足以证明本地文件受到了完整保护。 这不是让人放弃官方移除命令，而是提醒：命令的保护范围和人的保留需求并不完全重合。
另一个细节也值得留意：--ignored=matching 可能只报告命中规则的整个目录，而不展开里面的每个文件。看到一个忽略目录时，应按其用途检查内容，不能把它当作“只有这一行垃圾”。该选项的显示方式由官方文档明确说明。[5]
三、另外三组实验：文件、提交、分支不是同一层保护
以下结果均来自同一轮 Linux、Git 2.43.0 隔离实验，使用普通关联工作树，无子模块、无后台服务、无远程仓库。
普通未跟踪文件：移除被拦住了
创建未被忽略的 notes.txt 后，状态输出中出现 ?? notes.txt。普通移除命令失败，目录仍然存在。
这与官方文档描述的保护一致：通常只有没有未跟踪文件、没有已跟踪文件修改的干净工作树才能被普通移除命令处理。[1]
正确动作不是看到提示就补上 --force，而是先判断文件应该提交、转存，还是确实可以丢弃。
分支上有独有提交：移除成功，但分支仍在
在一个命名分支中修改文件并提交，主分支没有合入该提交。工作区状态已经干净，普通移除命令仍然成功。
移除后，实验分支仍能找到这个提交，提交对象也仍存在。这说明本次操作删除的是工作树目录，并没有顺便删除那个命名分支。
这个结果同时否定了两种误解：
- 工作树移除成功，不代表改动已经合入主分支。
- 工作树目录消失，也不代表其中所有已提交工作已经立刻丢失。
清理目录和处置分支应当是两个独立决定。不要因为前一步成功，就把后一步也视为默认授权。
分离头指针上的独有提交：对象还在，不等于已经保全
第三种情况更容易制造虚假的安全感：以 detached HEAD 创建工作树，做一个新提交，但不建立分支。状态同样干净，普通移除同样成功。
实验随后确认：提交对象当时仍然存在，但没有任何本地分支包含它。
这里不能夸大成“移除瞬间，提交就永远消失了”。本次结果恰好证明它当时还在。真正需要警惕的是：“现在还能按提交标识找到”，不应被当成一条明确、可持续的恢复路径。
如果这份工作仍有价值，我会在清理之前先为它建立清楚的保留引用，并确认恢复方式，而不是把事后找回交给运气。本文不提供针对未知旧目录的一键补救或批量删除脚本。
四、我的清理顺序：先确认价值，再判断能否移除
下面这些是检查命令，不会执行删除。命令中的目录表示待核验对象；实际使用前，先确认自己选中的是正确工作树。
第一步，看对象身份。
git worktree list --porcelain
核对路径、分支或分离头指针，以及是否存在锁定状态。不要把主工作区、活动工作树和失去目录的旧登记混在一起处理。官方文档区分了这些状态。[1]
第二步，在目标工作树里看文件。
git status --porcelain=v1 --untracked-files=all --ignored=matching
对输出中的改动、未跟踪文件和忽略目录分别判断。只读检查也可能暴露敏感文件名，因此不要不加筛选地把整份输出贴到公开 Issue 或聊天截图里。
第三步，看提交由谁承接。
git rev-parse HEAD git branch --contains HEAD
这两条命令也在本次实验中实际运行过：前者记录当前提交，后者帮助查看包含它的本地分支。它们不等于“已合并证明”，也不替代远程备份检查。
例如，实验分支本身包含当前提交，只说明有这个分支承接；不能据此推断主分支已接受这份工作。如果团队使用压缩合并或重放提交，还应按照实际合入方式核验内容，不仅比较提交标识。
第四步，确认没有仍在使用它的任务。
回到工作树的创建者和用途，检查运行中的测试、开发服务、编辑任务及外部引用。对缺少归属的信息，先保留并标注待判断，不能仅凭“很久没修改”补出一个删除结论。
这四步的目的不是让每个临时目录都获得永久豁免，而是把真正需要保存的少量内容从可重建产物中分离出来。先保全唯一价值，再用工作树自己的移除方式收口；不要先批量删，再讨论恢复。
五、prune 也不是自动判断价值的清洁工
Git 官方文档说明，git worktree prune 清理的是已经缺失工作树所留下的管理信息；对仍然存在、准备结束使用的工作树，应优先使用 git worktree remove。[1]
两者都不能替你判断业务价值。目录已经没了，不代表里面的工作曾被妥善保存；管理登记可以清理，也不代表原文件已经被备份。
因此，我不会把“超过一定天数”直接接成强制移除或全局清扫。时间可以提示该复查了，但不能代替文件、提交引用和活动使用关系的检查。
结论：干净是一种 Git 状态，不是一份丢弃许可
这次实验改变的不是我对 Git worktree 的评价，而是清理前的提问方式。
以前容易问：“它干净吗？”现在更应该问：“需要保留的文件在哪里，提交由什么引用承接，还有谁在使用这个目录？”
如果这些问题都有答案，清理可以很轻。反过来，即使状态输出为空、普通移除也不报错，都不应该把它解释成“没有损失的可能”。
本文为 AI 辅助整理的原创实验与方法分析。四组实验于 2026-09-07 在 Linux、Git 2.43.0 上实际执行；演示仓库随后清理，未删除真实项目资源。官方文档在同日核验，但未对所有 Git 版本、子模块、共享挂载、并发运行与复杂恢复场景逐一测试。文中不披露真实项目身份、目录、账号、配置或内部盘点数据；封面为概念插画，不是 Git 内部结构图。
来源与核验
以下为 Git 官方命令文档，核验日期：2026-09-07。在线文档与本次本地 Git 2.43.0 实验分别标注，不以当前文档替代跨版本实测。
