请看这张照片！ git会那么傻吗？ Git 无法取消链接某些文件，但只有 git.exe 持有该文件的句柄。 （权限没问题 - 完全控制） 请问，这个问题有安全的解决方案吗？ 我的 Git 版本是 1.9.5-preview20141217
【问题讨论】：
git的用户无权删除它...
Git 2.19（2018 年第三季度）改进了包文件的文件描述符管理，并避免了“Unlink of file... failed. Should I try again?”错误消息。
参见Kim Gybels (dscho) 的commit 12e73a3（2018 年 7 月 9 日）。
（由 Junio C Hamano -- gitster -- 合并于 commit 562413e，2018 年 8 月 2 日）
gc --auto: 自动打包前释放打包文件
“
git gc --auto”在生成“git repack/prune”之前打开包文件的文件描述符，这会扰乱不希望进程处理由另一个进程打开的文件的 Windows。
教
gc --auto发布包文件在自动打包存储库 以防止在删除它们时出现故障。
还教测试“使用 auto-gc 获取不会锁定”来抱怨 当它不再触发存储库的自动打包时。
这解决了Git for Windows issue "Unlink of file XXX failed. Should I try again?"，与PR 1769。
另一项改进：在 Git 2.34（2021 年第四季度）中，运行命令 API 已更新，因此调用者可以在生成可能触发 auto-gc 的命令之前轻松询问打开的文件描述符以关闭包文件。
参见commit c4dee2c、commit 5a22a33、commit 28d04e1、commit 3322a9d（2021 年 9 月 9 日）和commit 7e44ff7、commit 957ba81（2021 年 9 月 8 日）Johannes Schindelin (dscho)。
(由Junio C Hamano -- gitster -- 合并于commit c042ad5，2021 年 9 月 20 日）
c4dee2c085:在产生子进程的地方关闭对象存储签字人：约翰内斯·辛德林
在许多情况下，当我们生成可能触发重新打包的子进程时，我们首先明确关闭对象存储（以便
repack进程可以删除.pack文件，否则在 Windows 上是不可能的，因为只要文件仍在使用就无法删除）。我们现在尽可能使用
run_command()API 的新close_object_store位，以进一步延迟关闭对象存储。
这使得代码更易于维护，因为现在更明显的是，我们只因为那些子进程而释放那些文件句柄。
【讨论】：
我遇到了这个问题并通过命令解决了它：git gc 上面的命令删除临时和不必要的文件（垃圾收集器）：https://stackoverflow.com/a/26229658/532575
【讨论】：