Нет жесткого ограничения на количество веток, тегов, имен для удаленного отслеживания и других ссылок. (Все записи Git name-to-ha sh -ID карты refs или ссылки: имена ветвей - это просто ссылки, полное имя которых начинается с refs/heads/ ).
Они не всегда хранятся в отдельных файлах. В частности, ссылки со временем станут «упакованными». Упакованные ссылки хранятся в одном плоском файле, что заставляет их занимать (намного) меньше дискового пространства, хотя теперь чтение любого конкретного значения ссылки - его ha sh ID - может потребовать чтения довольно большого файла, если у вас много ссылок. ( Запись значения приводит к тому, что ссылка распаковывается, оставляя предыдущее значение в файле pack-refs - так что, как вы можете видеть, процесс поиска значения ссылки начинается с поиска сначала неупакованной копии , поскольку это должно переопределять любую упакованную копию.)
Поскольку каждая пара имя-значение занимает так мало дискового пространства (один блок или меньше), определенно возможно создать миллионы ссылок. Если вы сделаете это, ваши операции Git заметно замедлятся. Причина в том, что Git полон линейных сканов по всем ссылкам. Например, чтобы «декорировать» вывод git log, 1 до того, как git log напечатает коммит, он просматривает каждый реф, чтобы увидеть, ссылается ли этот реф на этот коммит. вопрос , на который ответ rootkonda ссылки содержит в qqx другую ссылку на ветку nabble.com в архиве списка рассылки о производительности возникающие проблемы (некоторые уже исправлены, некоторые остаются).
GitHub и Google также несколько лет обнаружили, что go, что Git может тратить много времени и пропускную способность сети в процессе приветствия, что два Gits go при запуске тоже: когда у вас есть Git вызов сервера Git для git fetch например, ваш Git имеет сервер Git список из все его ветви и тега и других таких имен. Если есть, скажем, десять тысяч перечисленных имен, каждое из которых имеет длину в среднем около 60 символов при расширении с идентификаторами ha sh, 2 , то есть около 600 килобайт данных до любой полезной может произойти обмен коммитами.
В общем, не стоит создавать тысячи или миллионы реферов. Нет теоретической причины не делать этого, но из соображений протокола и производительности можно рекомендовать мягкую шапку менее тысячи ссылок.
1 In:
commit c7a62075917b3340f908093f63f1161c44ed1475 (HEAD -> master, origin/master, origin/HEAD)
HEAD, master, origin master и origin/HEAD - украшения, найденные при поиске по всем ссылкам; форматирование HEAD -> указывает на то, что HEAD присоединено, в данном случае к master).
2 Обратите внимание, что аннотированные теги здесь удваиваются, так как они перечисляют оба имени тега и ha sh ID, и имя тега с суффиксом ^{} и целью тега. refs/tags/v1.2.3 09e393d913072d7765b02aba1210d843a83cfbae - это 57 символов даже без новой строки или другого разделителя.