gitrepository-layout

Хранилище объектов, связанное с этим репозиторием. Обычно хранилище объектов является самодостаточным (то есть все объекты, на которые ссылаются найденные в нём объекты, также находятся в нём), однако есть несколько способов нарушить это условие.

Каждый вновь созданный объект сохраняется в отдельном файле. Объекты распределяются по 256 подкаталогам на основе первых двух символов имени объекта sha1, чтобы число записей каталога в самом objects оставалось приемлемым. Найденные здесь объекты часто называются объектами unpacked (или loose).

В этом каталоге находятся паки (файлы, в которых множество объектов хранится в сжатом виде, а также индексные файлы для произвольного доступа к ним).

В этом каталоге хранится дополнительная информация о хранилище объектов.

Этот файл помогает простым транспортам обнаруживать доступные в данном хранилище пакеты. При добавлении или удалении пакета следует запускать git update-server-info, чтобы обновить этот файл, если репозиторий опубликован для простых транспортов. git repack делает это по умолчанию.

В этом файле записаны пути к дополнительным хранилищам объектов, из которых данное хранилище заимствует объекты; каждый путь указывается на отдельной строке. Обратите внимание: этот файл используют не только локальные встроенные инструменты Git, но и HTTP-клиент для получения данных удалённо. Обычно это работает, если в файле alternates указаны относительные пути (относительно базы данных объектов, а не репозитория!), но не работает с абсолютными путями, если только абсолютный путь в файловой системе не совпадает с путём в URL. См. также objects/info/http-alternates.

В этом файле записаны URL дополнительных хранилищ объектов, из которых данное хранилище заимствует объекты при получении данных из репозитория по HTTP.

Ссылки хранятся в подкаталогах этого каталога. Команда git prune сохраняет объекты, достижимые из ссылок, найденных в этом каталоге и его подкаталогах. Этот каталог игнорируется (за исключением refs/bisect, refs/rewritten и refs/worktree), если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/refs".

содержит ссылки на коммиты, являющиеся вершинами веток name

содержит имя любого объекта (не обязательно коммита или объекта-тега, указывающего на коммит).

содержит ссылки на коммиты, являющиеся вершинами веток, скопированных из удалённого репозитория.

содержит SHA-1 объекта, заменяющего <obj-sha1>. Это похоже на info/grafts; механизм используется и поддерживается командой git-replace[1]. Такие ссылки можно передавать между репозиториями, в отличие от grafts.

содержит ту же информацию, что и refs/heads/, refs/tags/ и аналогичные каталоги, но в более эффективном формате. См. git-pack-refs[1]. Этот файл игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/packed-refs".

Символическая ссылка (см. глоссарий) на пространство имён refs/heads/, обозначающая текущую активную ветку. Она не имеет особого значения, если репозиторий не связан ни с одним рабочим деревом (то есть является репозиторием bare), однако в корректном репозитории Git файл HEAD обязательно должен существовать; некоторые команды высокого уровня могут использовать его, чтобы определить предполагаемую «ветку по умолчанию» репозитория (обычно master). Допустимо, чтобы указанная ветка name ещё не существовала. В некоторых устаревших конфигурациях вместо символической ссылки используется символическая ссылка файловой системы, указывающая на текущую ветку.

Вместо символической ссылки на текущую ветку в HEAD также может быть записан непосредственно определённый коммит. Такое состояние часто называют detached HEAD.. Подробности см. в git-checkout[1].

Файл конфигурации конкретного репозитория. Этот файл игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/config".

Файл конфигурации, относящийся к рабочему каталогу для основного рабочего каталога в конфигурации с несколькими рабочими каталогами (см. git-worktree[1]).

Устаревший способ хранения сокращённых обозначений для указания URL в командах git fetch, git pull и git push. Файл можно сохранить как branches/<name>, после чего вместо аргумента repository этим командам можно передавать name. Подробности см. в разделе REMOTES справочной страницы git-fetch[1]. Этот механизм устарел и в современных репозиториях обычно не встречается. Этот каталог игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/branches".

Начиная с Git 3.0 Git перестанет считывать удалённые репозитории из этого каталога.

Хуки — это сценарии настройки, используемые различными командами Git. При запуске git init устанавливается несколько примеров хуков, но по умолчанию все они отключены. Чтобы включить хук, необходимо переименовать файл, удалив суффикс .sample. Подробное описание каждого хука см. в githooks[5]. Этот каталог игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/hooks".

При использовании нескольких рабочих деревьев большинство файлов в $GIT_DIR относятся к отдельным рабочим деревьям, за исключением некоторых известных файлов. Однако все файлы в common являются общими для всех рабочих деревьев.

Текущий индексный файл репозитория. Обычно отсутствует в голом репозитории.

Общая часть индекса, на которую ссылаются $GIT_DIR/index и другие временные индексные файлы. Используется только в режиме разделённого индекса.

В этом каталоге хранится дополнительная информация о репозитории. Этот каталог игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/info".

Этот файл помогает простым транспортам обнаруживать доступные в репозитории ссылки. Если репозиторий опубликован для простых транспортов, файл следует обновлять с помощью git update-server-info при каждом создании или изменении метки либо ветки. Обычно это выполняется хуком hooks/update, который запускается командой git-receive-pack при отправке изменений git push в репозиторий.

В этом файле записывается фиктивная информация о происхождении коммитов, позволяющая представить набор родителей коммита отличным от того, каким он был при создании коммита. Каждая строка описывает коммит и его фиктивных родителей: их 40-байтовые шестнадцатеричные имена объектов разделяются пробелами, а строка завершается символом новой строки.

Обратите внимание: механизм grafts устарел и может вызвать проблемы при передаче объектов между репозиториями; более гибкую и надёжную систему для той же цели см. в git-replace[1].

Этот файл по соглашению, принятому среди команд высокого уровня, хранит список шаблонов исключения. .gitignore — файл исключений для отдельного каталога. Команды git status, git add, git rm и git clean учитывают его, а основные команды Git — нет. См. также: gitignore[5].

Определяет атрибуты, назначаемые пути, аналогично файлам .gitattributes для отдельных каталогов. См. также: gitattributes[5].

В этом файле хранятся шаблоны разреженного извлечения. См. также: git-read-tree[1].

Хранит сокращённые обозначения URL и имена ссылок по умолчанию, используемые при взаимодействии с удалёнными репозиториями командами git fetch, git pull и git push. Подробности см. в разделе REMOTES справочной страницы git-fetch[1]. Этот механизм устарел и в современных репозиториях обычно не встречается. Этот каталог игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/remotes".

Начиная с Git 3.0 Git перестанет считывать удалённые репозитории из этого каталога.

В этом каталоге хранятся записи об изменениях ссылок. Дополнительные сведения см. в git-update-ref[1]. Этот каталог игнорируется (за исключением logs/HEAD), если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/logs".

Содержит записи обо всех изменениях вершины ветки с именем name.

Содержит записи обо всех изменениях метки с именем name.

Похож на info/grafts, но используется и поддерживается механизмом неглубокого клонирования. См. параметр --depth команд git-clone[1] и git-fetch[1]. Этот файл игнорируется, если задана переменная $GIT_COMMON_DIR; вместо него будет использоваться "$GIT_COMMON_DIR/shallow".

Если этот файл существует, переменной $GIT_COMMON_DIR (см. git[1]) будет присвоен указанный в нём путь, если она не задана явно. Если указанный путь относительный, он считается относительно $GIT_DIR. Репозиторий с файлом commondir неполон без репозитория, на который указывает «commondir».

Содержит репозитории Git подмодулей.

Содержит административные данные связанных рабочих деревьев. Каждый подкаталог содержит данные, относящиеся к одному связанному рабочему дереву. Этот каталог игнорируется, если задана переменная $GIT_COMMON_DIR; в этом случае вместо него будет использоваться "$GIT_COMMON_DIR/worktrees".

Текстовый файл, содержащий абсолютный путь к файлу .git, указывающему на этот каталог. Он используется для проверки, не удалён ли связанный репозиторий вручную и не следует ли больше хранить этот каталог. Время модификации этого файла следует обновлять при каждом обращении к связанному репозиторию.

Если этот файл существует, связанное рабочее дерево может находиться на переносном устройстве и быть недоступным. Наличие этого файла предотвращает удаление worktrees/<id> автоматически или вручную командой git worktree prune. В файле может содержаться пояснение, почему репозиторий заблокирован.

Файл конфигурации, относящийся к рабочему каталогу.