Вам необходимо определить «мертвую ветвь». Еще лучше начать с выяснения того, что вы имеете в виду, когда говорите "ветвь" - см. Что именно мы подразумеваем под "ветвью"?
Как отметили bmargulies , если коммит не имеет ссылок , он в конечном итоге будет собираться мусором. Итак, более точный вопрос: Когда коммит имеет ссылки?
Если вы знакомы с Lisp или любым из более современных языков для сбора мусора (включая Go, Java и Python), у вас есть большой старт здесь. Если нет, прочитайте страницу Википедии . Обратите внимание, что сборщикам языка общего назначения приходится иметь дело с циклами в графе объектов, что создает проблемы для простых сборщиков подсчета ссылок , таких как в реализации CPython. Граф объектов Git по определению является ациклическим, поэтому подсчет ссылок будет работать здесь, но Git по-прежнему использует стандартную технику разметки и развертки. Это позволяет объектам быть доступными только для чтения после создания: нет необходимости сохранять и обновлять счетчики ссылок. Git просто помечает объекты, на которые изначально ссылаются, затем пересекает график, чтобы скопировать метки на объекты, на которые ссылаются эти объекты.
В частности, каждый коммит в Git перечисляет хэш-идентификатор некоторого набора родительских коммитов - обычно только один, но для слияний, двух или более и для корневых коммитов no parent. Итак, Git начинается со всех внешних ссылок - всех хеш-идентификаторов объектов, которые напрямую доступны из вне внутреннего графа, - а затем для каждого объекта, являющегося объектом фиксации, помечает своего родителя. (ы), родитель (ы) родителей и т. д.
В этом конкретном случае при сборке мусора всей базы данных хранилища Git также помечает каждый объект tree и, рекурсивно, каждый объект, достижимый из дерева. Это помечает все используемые blob объекты. Git отмечает каждый непосредственно достижимый аннотированный тег, а также объект, на который указывает сам объект аннотированного тега, и, рекурсивно, любые объекты, достижимые из этого объекта (аннотированный тег может указывать на любой из четырех типов объектов).
Отметив каждый достижимый объект, все остальные объекты по определению недоступны . Git может извлечь эти объекты из репозитория, перестроить сжатые файлы пакета , в которых хранятся объекты с применением полного сжатия, а затем удалить все устаревшие свободные объекты (которые сжаты только zlib - полное сжатие в файлах пакета также выполняет дельта-кодирование).
Но мы все еще сталкиваемся с вопросом о том, что делает объект внешне достижимым , и именно здесь приходят имена ветвей и фактически все имена. Имена ветвей существуют в пределах refs/heads/ Пространство имен; имена тегов живут в refs/tags/; имена для удаленного отслеживания хранятся в refs/remotes/, а есть и другие. В совокупности эти имена называются ссылками , и все они имеют возможность хранить по одному хэш-идентификатору каждое.
Git также сохраняет внешние ссылки в:
- reflogs, которые сохраняют предыдущие значения имен ссылок;
HEAD, когда он отсоединен, и reflog для HEAD (HEAD иногда считается ссылкой, а иногда нет); - другие специальные
HEAD файлы, такие как ORIG_HEAD, MERGE_HEAD и CHERRY_PICK_HEAD;
- индекс , который обычно содержит ссылки BLOB-объектов; и
- добавлены файлы индекса рабочего дерева.
Если тон ссылается только на какой-то коммит, это другой коммит, и единственной ссылкой на этот коммит является имя ветки и ее записи в журнале, и вы удаляете имя ветки, тогда в этот момент эти два коммита теперь * 1078 без ссылок *. Они имеют право на сбор мусора. Есть несколько дополнительных сетей безопасности: их хэш-идентификаторы могут храниться, например, в журнале HEAD. Если они являются потерянными объектами (еще не упакованы), у них есть льготный период, по умолчанию 14 дней с момента их создания до их удаления. Этот льготный период означает, что команды Git могут выполнить свою работу до 14 дней, записав ссылку, которая поддерживает работу нового свободного объекта, даже если начался процесс сбора мусора.
Срок действия записей Reflog истекает, поэтому после удаления ветки name фиксации, уникальные для этой ветки, будут действовать не дольше, чем любая запись HEAD reflog (по умолчанию 30 дней) или 14 однодневный период отсрочки, в зависимости от того, что дольше. После этого коммиты вместе с любыми другими объектами (деревьями и BLOB-объектами), существование которых основано на продолжении существования этих коммитов, готовы к удалению, и следующая сборка мусора - ручная или автоматическая - удалит их.