I’ve been using Git for 9 years now, and today was the first time I knowingly encountered a file named .gitkeep in a diff. “What’s the point of this empty file?”, I thought. Quickly realizing that the idea is to track an empty directory, I started to wonder “Why would you want to make sure a directory exists when there’s nothing to put there?” and I started seeing blog posts about preparing for future changes that will add files to the directory or making sure your team has a consistent directory structure.

I feel like this is putting the cart before the horse. If there’s no information, there’s no reason for the directory. If your tools rely on a structure full of empty directories, those tools should be able to create the directories. If for some reason, they can’t, a set of mkdir -p commands prepended to the call is all it takes.

An example given in that second blog post:

If you have a deployment directory that contains configuration files or scripts, adding a .keep file to it ensures that it’s included in the deployment process.

No! Your build process should create the deployment directory, and that directory should be in .gitignore! You shouldn’t be saving an empty directory into which you might then commit deployment-generated files in error.

I’m honestly struggling to think of a use-case for these .keep files that isn’t better solved by $tools that generate directory structure according to a template (project setup). If you have one you think is really valuable, I’d love an email to help me understand.

Git made the right design decision to ignore empty directories because they’re do-nothing data.