Git 禁止先删除1.txt

关于1.txt

"1.txt": 是初始化部署时用于"占位"的文件。因为 Git 不追踪空目录，仅创建空文件夹不会体现在 Git 项目中，所以需要一个占位文件（即 1.txt）来确保该目录能被 Git 纳入版本管理。

问题场景

禁止操作： 禁止直接删除初始化项目同名子文件夹下的 1.txt 文件，导致子文件夹变为空目录。

典型路径示例： 网站项目根路径下的同名子项目目录，例如 aion2-GW/aion2-GW/1.txt。该目录即为代码上传的目标路径。

复现步骤

当该同名子文件夹中仅存在初始化文件 1.txt 时，若删除此文件，子文件夹将变为空目录。此时再尝试上传代码，Git 会报如下错误：

fatal: cannot create directory at 'aion2-GW': Permission denied

问题根因分析

为什么报错是 "cannot create directory" 而非 "cannot create file"？

表面上看，aion2-GW 子目录已存在（只是为空），理应只需在其中新建文件。但实际上，Git 在本次合并操作中需要整体替换该目录（例如远端将其从普通目录变为子模块、或反向转换、或需要重建其 inode），此时的操作并非在已有目录中写入新文件，而是要重建整个目录。

在这种场景下，即使已存在同名空目录，Git 也会将其视为"新建目录"来操作。

Git for Windows 安全策略冲突

从 Git for Windows 2.35.2 版本开始，引入了"可疑所有权"（suspicious ownership）安全检测机制。该机制导致了核心矛盾：

• 克隆仓库初始化部署时，所用身份为 adminweb。
• 后续自动化流程执行 Git 命令时，所用身份为 SYSTEM。
• 安全策略检测到新建的仓库目录所有者与当前操作用户不一致，Git 判定该目录属于"他人"，从而拒绝执行操作，抛出 Permission denied 错误。

总结

问题的根本原因是两个因素的叠加：

1. 空子文件夹被 Git 视为需要重建的新目录（而非已存在的目录）。
2. Git for Windows 的所有权安全策略阻止了不同用户身份（adminweb vs SYSTEM）对同一目录的 Git 操作。

后续改进措施

⚠️ 重要提醒：请所有项目相关人员务必注意！

为避免此类问题再次发生，后续所有新项目的初始化占位文件统一更名为 DO_NOT_DELETE.txt（全大写），以文件名本身作为醒目提示，明确告知使用者切勿优先删除该文件。

• 文件路径： 同名子文件夹下唯一保留 DO_NOT_DELETE.txt，如 aion2-GW/aion2-GW/DO_NOT_DELETE.txt。
• 作用： 与旧版 1.txt 一致，作为 Git 占位文件，确保空目录能被版本管理追踪。
• 警示效果： 大写文件名在日常操作中更为显眼，能有效降低误删风险。