Папка из одной ветви, добавленная в мой .gitignore, существует, когда я переключаюсь на другую ветку

TL; DR

Git должен оставить folder3 и подкаталоги в них, если в них есть файлы. В общем, он должен удалить их, если нет, но я видел угловые случаи, когда пустые каталоги по какой-то причине остаются позади. Я никогда не выслеживал, когда: каждый раз, когда я проверяю что-то, чтобы увидеть, нашел ли я проблему, Git убирает.

Long

Git мало заботится о папках. Git заботится о файлах . ^{1 Файл имеет путь, например dir1/dir2/file.ext. Операционная система заботится о папках (каталогах) и, следовательно, чтобы file.ext существовал, Git должен создать dir1 и затем dir1/dir2, если они еще не существуют. Создав эти каталоги, Git теперь может создать file.ext во втором - и это все , о которых Git заботится, на git checkout: те файлы, которые в коммите извлекаются быть извлечены как в индекс Git , 2 , так и в рабочее дерево .}

В рабочем дереве вы видите файлы: они имеют свою обычную повседневную форму, и вы можете работать с ними. Копии в индексе - это те, с которыми Git действительно действительно занимается, так как Git сделает любой новый коммит, который вы сделаете, из копий в индексе. Но копии в индексе находятся в специальной сжатой форме Git-only, которую Git замораживает в коммиты, поэтому Git любезно извлекает файлы как в индекс (где Git их хочет), так и в ваше рабочее дерево. Это шаг извлечения в рабочее дерево, который создает каталоги (папки) при необходимости .

Когда вы переключаетесь с коммита a123456... (на кончике BranchA) на коммит b789abc... (на кончике BranchB), Git будет:

• удалять из индекса и работать дерево любых файлов, которые есть только в a123456
• , создает в индексе и в рабочем дереве любые файлы, которые есть только в b789abc
• , заменяют в индексе и рабочем дереве любые файлы, которые отличаются в b789abc, чем в a123456.

Шаги remove и create иногда позволяют Git удалить пустой каталог или требуют, чтобы Git создал новый каталог. Шаги replace , как правило, не включают манипулирование каталогами. ³

Если у вас есть файлы, которые Git не хранит в своем индексе, эти являются неотслеживаемыми файлами. Они существуют в рабочем дереве, но их нет в индексе, поэтому они в основном не имеют отношения к Git. Пока переключение с коммита a123456 (на кончике BranchA) на b789abc (на кончике BranchB) не требует, чтобы Git что-то делал с этими файлами, т. Е. До тех пор, пока их нет в [1115 ] либо - Git ничего не делает с этими файлами. Ничего не делая с файлами, Git также ничего не делает с содержащимися в них каталогами.

^{1 Это либо слишком слабо, либо слишком сильно. Git действительно заботится о коммитах . Однако коммит содержит файлов: полный и полный снимок каждого файла в том состоянии, в котором он находился на момент этого коммита. Точнее, каждый коммит содержит файлы, которые он содержит, но это отчасти очевидно и бесполезно. Действительно, он содержит файлов, которые были в индексе, когда тот, кто сделал коммит, сделал коммит. Вот почему индекс (см. Сноску 2) так важен.}

^{2 Индекс также иногда называют промежуточной областью или кэшем , в зависимости от того, кто / какая часть Git выполняет вызов. Индекс начинается с копии каждого файла из текущего коммита, готового перейти в следующий коммит. Использование git add копирует новые файлы или новые версии существующих файлов в индекс, делая их готовыми к фиксации. Следовательно, лучшее краткое описание индекса: Индекс - это набор файлов, которые будут включены в следующий коммит. Это не охватывает все мелкие детали, особенно то, как работает индекс во время слияний, но охватывает самую важную часть.}

^{3 Есть редкий случай, когда по какой-то причине вы удалили кучу файлов рабочего дерева, которые находятся в в индексе из a123456, и забрал их каталог дерева работ тоже. В этом случае Git просто заново создаст каталог, чтобы удовлетворить принуждение ОС иметь каталог для хранения файла (ов). Git не нуждается или не заботится о каталоге - Git нужен только файл в индексе - но вам , вероятно, нужен файл, поэтому Git создает каталог при необходимости, так же, как и для файлов, которые не было в a123456.}