Чтобы ответить на заданный вопрос: объекты не имеют имен файлов. Это просто объекты .
. Сохраняет файлы хранилища, но они делают это косвенно. Каждый объект фиксации имеет ровно одну ссылку на один дерево объект. Древовидный объект в Git состоит из серии записей, каждая из которых содержит:
- a mode , который представляет собой текстовую строку, представляющую восьмеричное число, например
100755, 100644, 40000 и т. Д .; - компонент имени пути: двоичная (но обычно допустимая UTF-8) строка переменной длины, которая не содержит ни
/, нибайт NUL, за которым следует один байт NUL;и - идентификатор хеша (в двоичном виде, длиной 20 байт).
mode из 40000 указывает, что идентификатор хеша в записи совпадает с идентификатором другого объекта дерева, таким образом, идентификатор хеша должен быть хешем другого объекта дерева (или хранилище повреждено). Другие режимы подразумевают другие цели хеш-идентификатора, и в этом случае хеш-идентификатором обычно является блоб. Существует еще один особый случай: mode 160000 представляет gitlink и указывает, что запись предоставляет ожидаемый хеш-код и до git checkout от подмодуля.
Следовательно,ID BLOB-объекта B может представлять несколько разных имен файлов. Эти имена файлов создаются путем объединения сегментов пути в каждом объекте дерева с конечным объектом в режиме - 100755 или режиме - 100644 в серии объектов, которые привели к нахождению конечного объекта.
То есть, предположим, что commit C a имеет в качестве верхнего уровня хеш-код дерева T 1 , который ссылается на дерево T 2 по имени d1, а затем T 2 относится к BLOB-объекту B h по имени f1. Затем blob B h представляет в этом коммите , файл d1/f1. Но предположим, что коммит C b имеет дерево T 3 , которое относится к дереву T 4 по имени d2 и T 4 относится к B ч по имени f2. Затем blob B h представляет файл d2/f2 в коммите C b . Если commit C c имеет дерево верхнего уровня T 5 , которое относится к B h с именем f3, коммит C c сохраняет то же содержимое файла под именем f3 (без подпапки).
Постоянство объектав репозитории - это функция набора правил, основной драйвер которых достижимость . См. Думайте как (а) Git для определения достижимости. Недоступный объект будет (как правило, в конечном итоге) удален, но дополнительные правила не позволяют удалить недоступные свободные объекты в течение некоторого времени, так что Git может создавать временные объекты и в конечном итоге - в течение периода времени - make они достижимы и, следовательно, постоянны (или настолько же постоянны, насколько они остаются достижимыми).
Объекты внутри пакета просто не могут быть удалены вообще. Однако файлы пакета, содержащие много бесполезных объектов, могут, как правило, повторно упаковываться в новые (и различные) файлы пакета;или они могут быть взорваны на отдельные свободные объекты. Если старый файл пакета больше не нужен - поскольку все его объекты доступны в виде незакрепленных объектов или в заменяющем пакете, - его можно отбросить, но файл .keep для файла пакета предотвратит его удаление. Сам Git не создает файлы .keep: они предназначены для людей, которые напрямую (с любыми целями) возятся с файлами пакетов.
Команда git gc - это оболочка, которая обычно отвечает за создание и поддержкуупаковать файлы и для очистки устаревших, не связанных объектов. Для достижения этого результата он запускает другие внутренние команды Git, включая git reflog expire, git repack и git prune.