Файлы, которые отслеживаются по Git, будут удалены Git при переключении с коммита, в котором они существуют (и, следовательно, отслеживаются 1 ), на коммит в которых они не существуют (и, следовательно, не отслеживаются). После удаления из коммита, в котором эти файлы существовали и отслеживались, в коммит, в котором они не существуют и не отслеживаются, они не находятся в рабочем дереве и не являются неотслеживаемыми файлами.
Если вы каким-либо образом - с помощью любого средства - переключитесь с коммита, в котором отслеживается файл, на коммит, в котором его нет, и, следовательно, удалите копию файла из индекса 2 чтобы он не отслеживался, не удаляя также копию файла из вашего рабочего дерева, 3 этот файл теперь не отслеживается и, следовательно, Git выиграл ' удали это. Есть несколько способов добиться этого, включая запуск git rm --cached, который удаляет копию файла из индекса, не касаясь копии файла в вашем рабочем дереве.
Git мало что делает, и ничего не волнует, о папках: папки - это провинция, одержимость и проблема вашей компьютерной системы , а не Git. Все Git заботятся о файлах , которые имеют имена, по которым по какой-то причине ваш компьютер настаивает на разбиении на папки-y, заканчивающиеся файлом-y: dir/sub/file.ext, который является file в глазах Git - это не файл на вашем компьютере: это папка (или каталог) с именем dir, содержащая папку с именем sub, содержащая файл с именем file.ext. Git делает все возможное, чтобы приспособить вашу операционную систему к «папкам» путем создания dir/, чтобы она могла создавать dir/sub/, чтобы она могла создавать dir/sub/file.ext - файл, который его интересует - по требованию. Когда Git означает очистку группы файлов, таких как dir/sub/file1.ext - dir/sub/fileN.ext, если он очистил файл last , он также удалит dir/sub/ , Но он не может этого сделать, если любой файл , включая неотслеживаемый, останется в этом каталоге, поэтому в этом случае он не будет ... и удалив все файлы dir/sub/* - помните, чтобы Git, это всего лишь файлов , здесь не задействовано никаких папок - что он отслеживал, Git теперь даже не подозревает, что dir/sub/ вообще существует. Это теперь ваша проблема; если вы удалите оттуда последний из неотслеживаемых файлов, то вы тоже можете удалить этот каталог.
В течение десятилетий я наблюдал различные случаи, когда Git не удалить пустые папки / каталоги, несмотря на то, что они только что были очищены при обновлении индекса. Со временем они уменьшились: теперь это на 1058 * намного реже, чем это было в 2005 году (в той степени, в которой я лично не видел это несколько лет назад). Если вы можете найти последовательность повторяемая , которая оставляет это позади, которая не связана с ошибкой оператора (неотслеживаемые файлы), это ошибка, и вы можете отправить отчет об ошибке с людьми Git. 4
1 Файл Git отслеживается , если и только если он находится в индексе. Вот и все, что нужно сделать: наличие файла в индексе означает, что файл отслеживается. Отсутствие файла в индексе означает, что файл не отслеживается.
Чтобы проверить содержимое индекса - обратите внимание, что он довольно длинный и не предназначен для повседневного использования пользователями - запустите git ls-files --stage. Эта вещь - сущность, которую Git называет index - является центральной и ключевой концепцией; Вы должны понять, как Git использует его, по крайней мере, до некоторой степени, чтобы эффективно использовать Git. К сожалению, многие Git учебники пытаются это скрыть. Git сам по себе не очень хорошо показывает: git ls-files --stage совсем не дружелюбен.
Индекс также известен как область подготовки , и (редко в наши дни) кэш . Все три имени относятся к одной и той же вещи, хотя некоторые команды (например, git apply) по-разному используют --cached и --index.
2 Технически, «копии» файлов в индексе на самом деле являются ссылками на внутренние *1056* внутренние объекты blob . См. Вывод git ls-files --stage из сноски 1: каждая запись файла в индексе состоит из mode , blob ha sh ID , порядкового номера слота - обычно ноль - и имя . (Индекс также содержит данные кэша, отсюда одно из трех его альтернативных имен.)
3 Копии файлов в вашем рабочем дереве - ваши, с которыми можно поиграть. Это почему это ваше дерево работы: именно там вы выполняете свою работу. Git не использует эти файлы для фиксации next ; вместо этого он использует копии / ссылки в индексе. Это index , который имеет значение при создании новых коммитов, а git checkout сначала извлекает извлеченный коммит в индекс, прежде чем размораживать и распаковывать и вообще не Git - изменение ваших файлов, чтобы вы могли получить к ним доступ в своем рабочем дереве.
Именно поэтому вам постоянно приходится git add файлов: git add означает копировать файл обратно в индекс , т. е. замените объект BLOB-объекта замороженного формата новым, сделанным из всего, что сейчас находится в рабочем дереве. Обратите внимание, что git add фактически удалит файл из индекса, если файл не в рабочем дереве, так что в этом смысле действительно делает индексная копия соответствует копии рабочего дерева , даже если это означает удалить файл .
4 Если вы используете древнюю версию Git, обновить до подачи заявки. Если git --version печатает что-то старше, чем около 2,17, это довольно древнее. Текущая версия 2.25.1.