TL; DR: просто ищите пустые каталоги. Вы можете безопасно удалить их - ну, «сейф» зависит от вашего собственного программного обеспечения, но для Git это безопасно. (Следите за отсутствующими файлами - см. Определение «отсутствует» ниже - которое может удалить каталог, который может понадобиться Git позже, но это нормально, потому что Git просто создаст его снова.)
В системе Unix / Linux (отредактировано для исправления потерянного слова в транскрипции):
find . -name .git -prune -o -type d -empty -print
(на верхнем уровне рабочего дерева) найдет пустые каталоги.
Long (МОГ)
Git не заинтересован в папках / каталогах. Не существует такой вещи, как неотслеживаемая папка, точно так же, как нет отслеживаемой папки: Git заботится только о файлах . В частности, файл находится либо в индексе, либо не в индексе, и если его нет в индексе, он не отслеживается.
Когда вы используете различные опции для вывода списка неотслеживаемых файлов (которые обычно пропускают те, которые не отслеживаются и игнорируются, поскольку вы обычно хотите , что), Git иногда объединяет все файлы находящиеся в какой-либо папке, обратите внимание, что в этой папке нет файлов отслеженных , и сообщите о них, используя агрегированные записи Вы можете остановить это, например, git status --untracked-mode=all
; тогда вы получите отдельные имена файлов.
Обратите внимание, что возможно иметь какой-то отслеживаемый файл, но отсутствует . Например, предположим, что sub/README.txt
является отслеживаемым файлом и фактически существует. Тогда мы бежим rm sub/README.txt
. Файл sub/README.txt
остается в индексе Git, а будет в следующем коммите, но он отсутствует. Если это был only файл в sub
в вашем рабочем дереве, sub
теперь пуст, и вы можете удалить его с помощью rmdir sub
. Даже если sub/README.txt
по-прежнему отсутствует (и sub
также отсутствует!), Это не повлияет на следующий коммит: он будет все еще содержать sub/README.txt
, поскольку этот файл равен в указателе. (Используя git rm --cached sub/README.txt
, вы также можете удалить его из индекса, если вы этого хотели.)
Если и когда Git скопирует sub/README.txt
обратно из индекса в рабочее дерево, Git обнаружит, что sub
нет. Git просто пожмет плечами метафорически и создаст каталог sub
, а затем поместит в него sub/README.txt
. Вот почему Git не интересуется папками / каталогами: они просто скучные и скучные, требуются только для хранения файлов, созданных по требованию.
Если вы хотите, чтобы Git создал каталог, вам нужно сохранить в нем файл. Поскольку программы, управляемые Git, должны иметь возможность игнорировать файл с именем .gitignore
, это очень хорошее имя файла, которое можно вставить в такой каталог. Вы можете записать *
в этот файл и добавить его в свои коммиты, так что Git создаст каталог и запишет туда файл .gitignore
, содержащий *
, и, таким образом, автоматически проигнорирует все дополнительные неотслеживаемые файлы в этом каталоге.
Примечание: в общем, когда Git извлекает последний файл из некоторого каталога, он также удаляет каталог, но иногда я видел, как он оставлял некоторые из них. (Конечно, он должен оставить каталог позади, если он все еще содержит неотслеживаемые файлы. Обратите внимание, что git clean -fd
удалит пустые каталоги, хотя он также удалит неотслеживаемые файлы.)