Git空目录保留：一个约定俗成的技巧
你是否遇到过这样的困扰：本地项目里明明有个空目录，提交到Git仓库后，同事拉取代码时却发现这个目录“消失”了？这背后其实是一个Git的设计逻辑问题。
为什么 Git 默认不保留空目录
简单来说，Git的核心是跟踪文件内容的变化，而不是目录结构本身。一个目录，只有当它里面至少包含一个被Git追踪的文件时，才会在版本历史中被“看见”。如果目录空空如也，那么在克隆或检出代码时，Git就会认为这个目录没有存在的必要，从而不会创建它。
这直接导致了一些典型的“坑”：比如git status对空目录视而不见；团队协作时，远程仓库的目录结构似乎少了一层；更常见的是，在CI/CD流水线中构建项目时，突然报错No such file or directory，因为某个脚本预设的路径根本不存在。
用 .gitkeep 是最直接的约定做法
社区给出的解决方案既简单又巧妙：在需要保留的空目录里，放置一个名为.gitkeep的空文件。这个文件本身没有任何特殊含义或功能，它纯粹是一个“占位符”。一旦你通过git add .gitkeep将其纳入版本控制，Git就会因为这个文件的存在而将整个目录结构一并保留下来。
这个名字已经成为一种心照不宣的约定，看到它，开发者就能立刻明白这个目录是故意被保留为空的。
具体操作时，有几点需要注意：
- 创建文件：在目标空目录下，使用
touch .gitkeep（Linux/macOS）或type nul > .gitkeep（Windows CMD）命令即可。 - 检查忽略规则：务必确认项目的
.gitignore文件没有将.gitkeep这类文件排除在外。如果存在类似*.keep或.git*的规则，需要添加!.gitkeep来显式放行。 - 文件内容：保持为空，0字节就行，无需任何额外操作。
批量处理多个空目录时慎用 find -empty
当项目中有多个空目录需要处理时，你可能会想到用find命令一键搞定。比如：
find . -type d -empty -exec touch {}/.gitkeep \;这个命令虽然方便，但隐藏着风险：
- 它会递归地扫描所有子目录，包括
.git、node_modules这类你绝对不想碰的目录。更安全的做法是限定搜索范围，例如find ./src -type d -empty ...。 -empty参数的判断标准是“目录下既没有文件也没有子目录”。如果目录里存在像.DS_Store这样的隐藏文件，它就不会被判定为“空”，从而被命令跳过。- 最佳实践是，在执行前先用
find . -type d -empty命令预览一下结果，确认无误后再进行实际操作。
.gitignore 方案看似灵活，实际更易出错
除了.gitkeep，还有一种流传的方案：在空目录里放一个.gitignore文件，内容写成：
# 忽略此目录下的所有文件 * # 但不忽略这个 .gitignore 文件本身 !.gitignore
理论上，这也能让Git跟踪该目录。但问题在于，这个.gitignore文件是真正生效的。这意味着，未来如果你想在这个目录里添加一个真正的配置文件（比如config.json），它会被自动忽略，除非你回头去修改那个.gitignore文件的内容。
这无疑增加了不必要的维护负担。与.gitkeep相比，这种方案语义模糊：它到底是想说“这个目录目前为空，但结构需要保留”，还是“这个目录未来也只允许特定文件存在”？
说到底，保留空目录的需求，核心往往只是需要一个清晰的“结构信号”。.gitkeep正是为此而生——它足够轻量，没有副作用，行为可预测，是解决这个问题最优雅的约定。
