Вопрос: Как добавить пустой каталог в репозиторий Git?


Как добавить пустой каталог (который не содержит файлов) в репозиторий Git?


3420


источник


Ответы:


Другой способ сделать каталог пустым (в репозитории) - создать .gitignoreфайл внутри этого каталога, который содержит эти четыре строки:

# Ignore everything in this directory
*
# Except this file
!.gitignore

Тогда вам не нужно правильно оформлять заказ так, как вам нужно делать в m104's решение ,

Это также дает преимущество в том, что файлы в этом каталоге не будут отображаться как «невоспроизведенные», когда вы выполняете статус git.

Изготовление @GreenAsJade Комментарий пользователя постоянный:

Я думаю, стоит отметить, что это решение делает именно то, о чём задается вопрос, но, возможно, это не то, что искали многие люди, рассматривающие этот вопрос. Это решение гарантирует, что каталог остается пустым. В нем говорится: «Я действительно не хочу, чтобы файлы проверялись здесь». В отличие от «У меня нет файлов для регистрации здесь, но, но мне нужен каталог здесь, файлы могут появляться позже».


3304



Вы не можете. См. Вопросы по Git ,

В настоящее время дизайн индекса git   (промежуточная область) разрешает только файлы   быть перечислены, и никто не достаточно компетентен   чтобы сделать изменение пустым   в каталогах достаточно   эта ситуация исправить.

Каталоги добавляются автоматически   при добавлении в них файлов. Что   , каталоги никогда не должны быть добавлены   к репозиторию и не отслеживаются   самостоятельно.

Ты можешь сказать " git add <dir>" и это   будет добавлять туда файлы.

Если вам действительно нужен каталог для   в выписках вы должны создать   файл в нем. .gitignore хорошо работает для   эта цель; вы можете оставить его пустым,   или введите имена файлов, которые вы   ожидают появления в каталоге.


976



Создайте пустой файл с именем .gitkeepв каталоге и добавьте это.


586



Вы всегда можете поместить файл README в каталог с объяснением, почему вы хотите это, иначе пустое, каталог в репозитории.


360



touch .keep

On Linux, this creates an empty file named .keep. This name is preferred over .gitkeep as the former is agnostic to Git, whereas the latter is specific to Git. Secondly, as another user has noted, the .git prefix convention should be reserved for files and directories that Git itself uses.

Alternatively, as noted in another answer, the directory can contain a descriptive README or README.md file instead.

Of course this requires that the presence of the file won't cause your application to break.


251



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" an empty directory can be useful, for example:

  • building a predefined folder structure for useful project folders, and make this structure 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 cache/ or logs/ directories
  • some projects simply 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).

Some suggested workarounds

Many users suggest:

  1. Placing a README file or another file with some content in order to make the directory non-empty, or
  2. Creating a .gitignore file 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 unconsistent 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 .gitignore to do a thing (keeping files) that is the very opposite of what it's meant for (excluding files), even though it is possible?

.gitkeep approach

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 .gitignore to ignore unwanted files.

  • Naming it .gitkeep makes 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

Adoption

I've seen the .gitkeep approach adopted by very important frameworks like Laravel, Angular-CLI.


192



As described in other answers, Git is unable to represent empty directories in its staging area. (See the Git FAQ.) However, if, for your purposes, a directory is empty enough if it contains a .gitignore file only, then you can create .gitignore files in empty directories only via:

find . -type d -empty -exec touch {}/.gitignore \;

118



Andy Lester is right, but if your directory just needs to be empty, and not empty empty, you can put an empty .gitignore file in there as a workaround.

As an aside, this is an implementation issue, not a fundamental Git storage design problem. As has been mentioned many times on the Git mailing list, the reason that this has not been implemented is that no one has cared enough to submit a patch for it, not that it couldn’t or shouldn’t be done.


57



The Ruby on Rails way:

mkdir log && touch log/.gitkeep && git add log/.gitkeep

Now the log directory will be included in the tree. It is super-useful when deploying, so you won't have to write a routine to make log directories.

The logfiles can be kept out by issuing,

echo log/dev.log >> .gitignore

but you probably knew that.


29