gitglossary

С помощью механизма alternate репозиторий может наследовать часть своей базы объектов от другой базы объектов, которая называется «альтернативной».

Голый репозиторий обычно представляет собой каталог с соответствующим именем и суффиксом .git, в котором нет локально извлечённой копии каких-либо файлов, находящихся под контролем версий. Иными словами, все административные и управляющие файлы Git, которые обычно находятся в скрытом подкаталоге .git, вместо этого размещены непосредственно в каталоге repository.git, а других файлов в нём нет. Обычно издатели общедоступных репозиториев предоставляют голые репозитории.

Объект без типа, например содержимое файла.

«Ветка» — это линия разработки. Последний коммит ветки называется её вершиной. На вершину ветки указывает ссылка — голова ветки; она перемещается вперёд по мере дальнейшей разработки ветки. Один репозиторий Git может отслеживать произвольное число веток, но ваше рабочее дерево связано только с одной из них (текущей, или выбранной, веткой), на которую указывает HEAD.

Устаревшее название индекса.

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

Термин из BitKeeper/cvsps для обозначения «коммита». Поскольку Git хранит не изменения, а состояния, термин «набор изменений» для Git, строго говоря, не имеет смысла.

Действие, при котором всё рабочее дерево или его часть обновляется объектом дерево или blob из базы объектов, а также обновляются индекс и HEAD, если всё рабочее дерево переключено на новую ветку.

В жаргоне SCM «cherry pick» означает выбор подмножества изменений из серии изменений (обычно коммитов) и запись их в виде новой серии изменений поверх другой кодовой базы. В Git для этого используется команда «git cherry-pick»: она извлекает изменение, внесённое существующим коммитом, и записывает его на основе вершины текущей ветки в виде нового коммита.

Рабочее дерево считается чистым, если оно соответствует ревизии, на которую указывает текущая голова. См. также «изменённое состояние».

Как существительное: отдельная точка в истории Git; вся история проекта представлена в виде набора взаимосвязанных коммитов. Git часто использует слово «коммит» в тех же случаях, когда другие системы контроля версий используют слова «ревизия» или «версия». Также это сокращённое название объекта коммита.

Как глагол: действие по сохранению нового снимка состояния проекта в истории Git путём создания нового коммита, представляющего текущее состояние индекса, и перемещения HEAD на новый коммит.

Синоним структуры DAG, образованной коммитами в базе объектов, на которые указывают вершины веток, и использующей их цепочки связанных коммитов. Эта структура и есть собственно граф коммитов. Граф можно представлять и другими способами, например с помощью файла «commit-graph».

Файл «commit-graph» (обычно с дефисом в названии) — это дополнительное представление графа коммитов, ускоряющее обход графа. Файл «commit-graph» хранится либо в каталоге .git/objects/info, либо в каталоге info альтернативной базы объектов.

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

Объект коммита или объект, который можно рекурсивно разыменовать до объекта коммита. К commit-ish относятся: объект коммита, объект тега, указывающий на объект коммита, объект тега, указывающий на объект тега, который указывает на объект коммита, и так далее.

Основные структуры данных и утилиты Git. Предоставляет лишь ограниченный набор средств управления исходным кодом.

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

Недостижимый объект, который нельзя достичь даже из других недостижимых объектов; на висячий объект не ссылается ни одна ссылка или объект в репозитории.

Применительно к символической ссылке: действие по обращению к ссылке, на которую указывает символическая ссылка. Рекурсивное разыменование предполагает повторение описанной операции для полученной ссылки до тех пор, пока не будет найдена несymbolическая ссылка.

Применительно к объекту тега: действие по обращению к объекту, на который указывает тег. Теги разыменовываются рекурсивно: операция повторяется для результирующего объекта, пока его тип не станет указанным типом объекта (если он задан) или любым типом, отличным от «tag». Синоним «рекурсивного разыменования» для тегов — «раскрытие».

Применительно к объекту коммита: действие по обращению к объекту дерево коммита. Коммиты нельзя разыменовывать рекурсивно.

Если не указано иное, «разыменование» в контексте команд и протоколов Git подразумевает рекурсивное разыменование.

Обычно в HEAD хранится имя ветки, и команды, работающие с представленной HEAD историей, обрабатывают историю, ведущую к вершине ветки, на которую указывает HEAD. Однако Git также позволяет переключиться на произвольный коммит, который не обязательно является вершиной какой-либо ветки. В таком состоянии HEAD называется «отсоединённым».

Обратите внимание: команды, работающие с историей текущей ветки (например, git commit для создания новой истории поверх неё), продолжают работать и при отсоединённом HEAD. Они перемещают HEAD на вершину обновлённой истории, не затрагивая ветку. Команды, которые обновляют сведения о текущей ветке или запрашивают их about (например, git branch --set-upstream-to, задающая ветку удалённого отслеживания, с которой интегрируется текущая ветка), очевидно, работать не будут, поскольку в этом состоянии нет (реальной) текущей ветки, о которой можно было бы запросить сведения.

Список, который выдаёт команда «ls» :-)

Рабочее дерево считается «изменённым», если в нём есть изменения, которые не были зафиксированы в текущей ветке.

Неудачное слияние — это слияние, вносящее изменения, которых нет ни в одном из родителей.

Перемотка вперёд — это особый вид слияния, при котором у вас есть ревизия, а вы «сливаете» изменения другой ветки, являющейся потомком вашей ревизии. В таком случае новый коммит слияния не создаётся — ваша ветка просто перемещается на ту же ревизию, что и ветка, с которой выполняется слияние. Это часто происходит с веткой удалённого отслеживания удалённого репозитория.

Получить ветку означает получить её ссылку на голову из удалённого репозитория, определить, каких объектов не хватает в локальной базе объектов, и получить их. См. также git-fetch[1].

Изначально Линус Торвальдс разработал Git как файловую систему пользовательского пространства, то есть инфраструктуру для хранения файлов и каталогов. Это обеспечило эффективность и скорость Git.

Синоним репозитория (в терминологии специалистов по архитектуре компьютеров).

Обычный файл .git в корне рабочего дерева, указывающий на каталог, в котором находится настоящий репозиторий. Правила его использования см. в git-worktree[1] или git-submodule[1]. Синтаксис описан в gitrepository-layout[5].

Подсадки позволяют объединить две в остальном разные линии разработки, записывая фиктивные сведения о происхождении коммитов. Благодаря этому можно заставить Git считать, что у коммита другой набор родителей, нежели тот, который был записан при его создании. Настраивается с помощью файла .git/info/grafts.

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

В контексте Git — синоним имени объекта.

Именованная ссылка на коммит в вершине ветки. Головы хранятся в файлах каталога $GIT_DIR/refs/heads/, за исключением случаев использования упакованных ссылок. (См. git-pack-refs[1].)

Текущая ветка. Точнее, обычно ваше рабочее дерево создаётся на основе состояния дерева, на которое указывает HEAD. HEAD — это ссылка на одну из голов вашего репозитория, кроме случая с отсоединённым HEAD, когда она указывает непосредственно на произвольный коммит.

Синоним головы.

При обычном выполнении ряда команд Git вызываются дополнительные необязательные скрипты, позволяющие разработчику добавлять функциональность или выполнять проверки. Как правило, перехватчики позволяют предварительно проверить команду и при необходимости прервать её, а также отправить уведомление после завершения операции. Скрипты перехватчиков находятся в каталоге $GIT_DIR/hooks/; чтобы включить их, достаточно удалить суффикс .sample из имени файла. В более ранних версиях Git их нужно было сделать исполняемыми.

Набор файлов со статистической информацией, содержимое которых хранится в виде объектов. Индекс — это сохранённая версия вашего рабочего дерева. На самом деле в нём могут храниться и вторая, и даже третья версии рабочего дерева; они используются при слиянии.

Сведения об отдельном файле, хранящиеся в индексе. Запись индекса может быть неслитой, если слияние было начато, но ещё не завершено (то есть если индекс содержит несколько версий этого файла).

Ветка разработки по умолчанию. При создании репозитория Git создаётся ветка с именем «master», которая становится активной. В большинстве случаев в ней ведётся локальная разработка, хотя это лишь соглашение, а не обязательное правило.

Как глагол: включить содержимое другой ветки (возможно, из внешнего репозитория) в текущую ветку. Если сливаемая ветка находится в другом репозитории, сначала выполняется получение удалённой ветки, а затем результат сливается с текущей веткой. Эта комбинация операций получения и слияния называется извлечением изменений. Слияние выполняется автоматически: система определяет изменения, внесённые с момента расхождения веток, и применяет их вместе. Если изменения конфликтуют, для завершения слияния может потребоваться вмешательство пользователя.

Как существительное: если это не перемотка вперёд, успешное слияние приводит к созданию нового коммита, представляющего результат слияния и имеющего вершины слитых веток в качестве родителей. Такой коммит называется «коммитом слияния» или просто «слиянием».

Единица хранения в Git. Она уникально идентифицируется по SHA-1 своего содержимого. Поэтому объект нельзя изменить.

Хранит набор «объектов»; отдельный объект идентифицируется по своему имени объекта. Обычно объекты находятся в каталоге $GIT_DIR/objects/.

Синонимы имени объекта.

Уникальный идентификатор объекта. Обычно имя объекта представлено шестнадцатеричной строкой длиной 40 символов. В обиходе также называется SHA-1.

Один из идентификаторов «commit», «tree», «tag» или «blob», обозначающий тип объекта.

Выполнить слияние более чем двух веток.

Переход на ещё не существующую ветку (то есть на нерождённую ветку). После такой операции первый созданный коммит не будет иметь родителя и начнёт новую историю.

Репозиторий, заданный по умолчанию как вышестоящий. У большинства проектов есть по крайней мере один вышестоящий проект, изменения которого они отслеживают. По умолчанию для этой цели используется origin. Новые изменения из вышестоящего проекта будут получены в ветки удалённого отслеживания с именами origin/name-of-upstream-branch; их можно просмотреть с помощью git branch -r.

Обновлять и добавлять файлы в рабочий каталог, но не удалять их — подобно тому, как cp -R обновляет содержимое целевого каталога. Это режим по умолчанию при извлечении файлов из индекса или tree-ish. В отличие от него, режим без наложения также удаляет отслеживаемые файлы, отсутствующие в источнике, подобно rsync --delete.

Набор объектов, сжатых в один файл (для экономии места или эффективной передачи).

Список идентификаторов и других сведений об объектах в пакете, помогающий эффективно обращаться к его содержимому.

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

Спецификации путей используются в командной строке команд «git ls-files», «git ls-tree», «git add», «git grep», «git diff», «git checkout» и многих других, чтобы ограничить область операций частью дерева или рабочего дерева. Сведения о том, отсчитываются ли пути от текущего каталога или от корневого каталога, см. в документации соответствующей команды. Синтаксис спецификации пути:

Например, Documentation/*.jpg соответствует всем файлам .jpg в поддереве Documentation, включая Documentation/chapter_1/figure_1.jpg.

Спецификация пути, начинающаяся с двоеточия :, имеет особое значение. В краткой форме за начальным двоеточием : следуют ноль или более букв «магической сигнатуры» (которые могут завершаться ещё одним двоеточием :), а затем шаблон для сопоставления с путём. «Магическая сигнатура» состоит из символов ASCII, которые не являются буквами и цифрами, символами glob, специальными символами регулярных выражений или двоеточием. Завершающее «магическую сигнатуру» двоеточие можно опустить, если шаблон начинается с символа, не входящего в набор символов «магической сигнатуры» и не являющегося двоеточием.

В полной форме за начальным двоеточием : следуют открывающая скобка (, разделённый запятыми список из нуля или более «магических слов», закрывающая скобка ), а затем шаблон для сопоставления с путём.

Спецификация пути, состоящая только из двоеточия, означает «спецификация пути отсутствует». Эту форму не следует комбинировать с другими спецификациями путей.

Объект коммита содержит (возможно, пустой) список логических предшественников в линии разработки, то есть своих родителей.

Действие по рекурсивному разыменованию объекта тега.

Термин pickaxe обозначает параметр подпрограмм diffcore, помогающий выбирать изменения, добавляющие или удаляющие заданную текстовую строку. С помощью параметра --pickaxe-all его можно использовать для просмотра полного набора изменений, в котором была добавлена или удалена, например, определённая строка текста. См. git-diff[1].

Шутливое название для ядра Git.

Шутливое название программ и наборов программ, использующих ядро Git и предоставляющих доступ к нему на высоком уровне. Высокоуровневые интерфейсы предоставляют более развитый интерфейс SCM, чем низкоуровневый интерфейс.

Ссылки, относящиеся к отдельному рабочему дереву, а не являющиеся глобальными. В настоящее время к ним относятся только HEAD и любые ссылки, начинающиеся с refs/bisect/, но в дальнейшем могут добавиться и другие необычные ссылки.

Ссылка, семантика которой отличается от семантики обычных ссылок. Эти ссылки можно читать с помощью обычных команд Git, но команды вроде git-update-ref[1] не могут их изменять.

Git распознаёт следующие псевдоссылки:

Получить ветку branch означает выполнить её fetch и merge. См. также git-pull[1].

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

Все предки заданного коммита считаются «достижимыми» из этого коммита. В более общем смысле один объект достижим из другого, если до него можно добраться от другого по цепочке, которая следует по тегам к объектам, на которые они указывают, по коммитам к их родительским коммитам или деревьям, а по деревьям — к содержащимся в них деревьям или блобам.

Битовые карты достижимости хранят сведения о достижимости выбранного набора коммитов в файле пакета или мультипакетном индексе (MIDX), чтобы ускорить поиск объектов. Битовые карты хранятся в файле «.bitmap». В репозитории может использоваться не более одного файла битовой карты. Этот файл может относиться либо к одному пакету, либо к мультипакетному индексу репозитория (если он существует).

Повторно применить последовательность изменений ветки branch к другой основе и переместить head этой ветки на полученный результат.

Имя, указывающее на имя объекта или другую ссылку (последняя называется символической ссылкой). Для удобства при использовании в качестве аргумента команды Git ссылка иногда может быть сокращена; подробности см. в gitrevisions[7]. Ссылки хранятся в репозитории.

Пространство имён ссылок имеет иерархическую структуру. Имена ссылок должны начинаться с refs/ или находиться в корне иерархии. Для ссылок, находящихся в корне, их имена должны соответствовать следующим правилам:

В корне иерархии есть несколько нестандартных ссылок, не соответствующих этим правилам. Следующий список является исчерпывающим и в будущем не должен расширяться:

Разные подиерархии используются для разных целей. Например, иерархия refs/heads/ используется для локальных веток, а иерархия refs/tags/ — для локальных тегов..

Журнал ссылок показывает локальную «историю» ссылки. Иными словами, он может показать, какой была третья с конца редакция в репозитории this и каково было текущее состояние в репозитории this вчера в 21:14. Подробности см. в git-reflog[1].

«Спецификация ссылок» (refspec) используется командами fetch и push для описания соответствия между удалённой ссылкой и локальной ссылкой. Подробности см. в git-fetch[1] или git-push[1].

Репозиторий, используемый для отслеживания того же проекта, но расположенный в другом месте. Для взаимодействия с удалёнными репозиториями см. fetch или push.

Ссылка, используемая для отслеживания изменений в другом репозитории. Обычно она выглядит как refs/remotes/foo/bar (что означает, что она отслеживает ветку с именем bar в удалённом репозитории с именем foo) и соответствует правой части настроенной спецификации ссылок fetch. В удалённую отслеживаемую ветку не следует вносить прямые изменения или создавать в ней локальные коммиты.

Набор ссылок вместе с базой данных объектов, содержащей все объекты, достижимые из этих ссылок, возможно, дополненный метаданными одной или нескольких пользовательских команд. Репозиторий может совместно использовать базу данных объектов с другими репозиториями с помощью механизма альтернативных баз данных объектов.

Действие по ручному исправлению того, что осталось после неудачного автоматического слияния.

Синоним слова коммит (существительного).

Отбросить часть разработки, то есть переместить head на более раннюю редакцию.

Управление исходным кодом (инструмент).

«Алгоритм безопасного хеширования 1»; криптографическая хеш-функция. В контексте Git используется как синоним имени объекта.

В основном синоним поверхностного репозитория, однако это выражение точнее указывает, что он был создан командой git clone --depth=....

Поверхностный репозиторий имеет неполную историю: у некоторых его коммитов отсутствуют родительские коммиты (иначе говоря, Git предписано считать, что у этих коммитов нет родителей, хотя они указаны в объекте коммита). Это бывает полезно, если вас интересует только недавняя история проекта, хотя полная история в вышестоящем репозитории гораздо обширнее. Поверхностный репозиторий создаётся с параметром --depth команды git-clone[1]; впоследствии его историю можно углубить с помощью git-fetch[1].

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

Репозиторий, в котором хранится история отдельного проекта внутри другого репозитория (последний называется суперпроектом).

Репозиторий, который ссылается на репозитории других проектов в своём рабочем дереве как на подмодули. Суперпроект знает имена объектов коммитов вложенных подмодулей, но не хранит их копии.

Символическая ссылка: вместо самого идентификатора SHA-1 она содержит значение формата ref: refs/some/thing и при обращении рекурсивно разыменовывается до этой ссылки. HEAD — наглядный пример символической ссылки. Символическими ссылками управляют с помощью команды git-symbolic-ref[1].

Ссылка в пространстве имён refs/tags/, указывающая на объект произвольного типа (обычно тег указывает на объект тега или объект коммита). В отличие от head, тег не обновляется командой commit. Тег Git не имеет отношения к тегу Lisp (который в контексте Git назывался бы типом объекта). Чаще всего тег используется для отметки определённой точки в цепочке предков коммита.

Объект, содержащий ссылку на другой объект и, подобно объекту коммита, способный содержать сообщение. Он также может содержать подпись (PGP); в этом случае он называется «подписанным объектом тега».

Обычная ветка Git, которую разработчик использует для обозначения отдельного направления разработки. Поскольку создавать ветки очень легко и дёшево, часто удобно иметь несколько небольших веток, каждая из которых содержит чётко определённую концепцию или небольшие последовательные, но связанные изменения.

Метаданные в формате «ключ — значение». Трейлеры иногда помещают в конец сообщения коммита. В других сообществах их могут называть «нижними колонтитулами» или «тегами». См. git-interpret-trailers[1].

Рабочее дерево working tree либо объект дерева вместе с зависимыми от него объектами блобов и деревьев (то есть сохранённое представление рабочего дерева).

Объект, содержащий список имён файлов и режимов доступа вместе со ссылками на соответствующие объекты блобов и/или деревьев. Дерево эквивалентно каталогу.

Объект дерева или объект, который можно рекурсивно разыменовать до объекта дерева. Разыменование объекта коммита даёт объект дерева, соответствующий верхнему каталогу редакции. К tree-ish относятся: commit-ish, объект дерева, объект тега, указывающий на объект дерева, объект тега, указывающий на объект тега, который указывает на объект дерева, и так далее.

HEAD может указывать на ещё не существующую ветку, в которой пока нет ни одного коммита; такая ветка называется ещё не созданной. Чаще всего пользователи сталкиваются с такой веткой, впервые создавая репозиторий без клонирования из другого источника. HEAD будет указывать на ветку main (или master, в зависимости от конфигурации), которой ещё предстоит появиться. Некоторые операции также могут переключить вас на ещё не созданную ветку с помощью параметра orphan.

Индекс, содержащий записи индекса с неразрешёнными слияниями.

Объект, который недостижим из ветки, тега или любой другой ссылки.

Ветка branch по умолчанию, сливаемая с рассматриваемой веткой (или ветка, на которую перебазируется рассматриваемая ветка). Настраивается с помощью branch.<name>.remote и branch.<name>.merge. Если вышестоящей веткой для A является origin/B, иногда говорят: «A отслеживает origin/B».

Дерево фактически извлечённых файлов. Обычно рабочее дерево содержит содержимое дерева коммита HEAD, а также все локальные изменения, которые вы внесли, но ещё не зафиксировали.

У репозитория может не быть привязанных рабочих деревьев (то есть это может быть bare-репозиторий) либо к нему может быть привязано одно или несколько рабочих деревьев. Одно «рабочее дерево» состоит из «рабочего дерева» и метаданных репозитория. Большая часть этих метаданных является общей для других рабочих деревьев одного репозитория, а некоторые данные хранятся отдельно для каждого рабочего дерева (например, индекс, HEAD и псевдоссылки вроде MERGE_HEAD, ссылки и файл конфигурации, относящиеся к конкретному рабочему дереву).