How can I add an empty directory to a Git repository?
How can I add an empty directory (that contains no files) to a Git repository?
Another way to make a directory stay (almost) empty (in the repository) is to create a
.gitignore file inside that directory that contains these four lines:
# Ignore everything in this directory * # Except this file !.gitignore
Then you don't have to get the order right the way that you have to do in m104's solution.
This also gives the benefit that files in that directory won't show up as "untracked" when you do a git status.
Making @GreenAsJade's comment persistent:
I think it's worth noting that this solution does precisely what the question asked for, but is not perhaps what many people looking at this question will have been looking for. This solution guarantees that the directory remains empty. It says "I truly never want files checked in here". As opposed to "I don't have any files to check in here, yet, but I need the directory here, files may be coming later".
Read more… Read less…
You can't. See the Git FAQ.
Currently the design of the git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.
Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own.
You can say "
git add <dir>" and it will add files in there.
If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose; you can leave it empty, or fill in the names of files you expect to show up in the directory.
Create an empty file called
.gitkeep in the directory, and add that.
You could always put a README file in the directory with an explanation of why you want this, otherwise empty, directory in the repository.
On Linux, this creates an empty file named
.keep. For what it's worth, this name is agnostic to Git, whereas
.gitkeep would be specific to Git. Secondly, as another user has noted, the
.git prefix convention should be reserved for files and directories that Git itself uses.
Of course this requires that the presence of the file won't cause your application to break.
Why would we need empty versioned folders
First things first:
An empty directory cannot be part of a tree under the Git versioning system.
It simply won't be tracked. But there are scenarios in which "versioning" empty directories can be meaningful, for example:
- scaffolding a predefined folder structure, making it available to every user/contributor of the repository; or, as a specialized case of the above, creating a folder for temporary files, such as a
logs/directories, where we want to provide the folder but
- related to the above, some projects won't work without some folders (which is often a hint of a poorly designed project, but it's a frequent real-world scenario and maybe there could be, say, permission problems to be addressed).
Some suggested workarounds
Many users suggest:
- Placing a
READMEfile or another file with some content in order to make the directory non-empty, or
- Creating a
.gitignorefile with a sort of "reverse logic" (i.e. to include all the files) which, at the end, serves the same purpose of approach #1.
While both solutions surely work I find them inconsistent with a meaningful approach to Git versioning.
- Why are you supposed to put bogus files or READMEs that maybe you don't really want in your project?
- Why use
.gitignoreto do a thing (keeping files) that is the very opposite of what it's meant for (excluding files), even though it is possible?
Use an empty file called
.gitkeep in order to force the presence of the folder in the versioning system.
Although it may seem not such a big difference:
You use a file that has the single purpose of keeping the folder. You don't put there any info you don't want to put.
For instance, you should use READMEs as, well, READMEs with useful information, not as an excuse to keep the folder.
Separation of concerns is always a good thing, and you can still add a
.gitignoreto ignore unwanted files.
.gitkeepmakes it very clear and straightforward from the filename itself (and also to other developers, which is good for a shared project and one of the core purposes of a Git repository) that this file is
- A file unrelated to the code (because of the leading dot and the name)
- A file clearly related to Git
- Its purpose (keep) is clearly stated and consistent and semantically opposed in its meaning to ignore