Git
Chapters ▾ 2nd Edition

10.1 Git изнутри - Сантехника и Фарфор

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

Раз уж вы тут, приступим. Во-первых, напомню, что Git — это, по сути, контентно-адресуемая файловая система с пользовательским интерфейсом системы контроля версий поверх неё. Довольно скоро станет понятнее, что это значит.

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

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

Сантехника и Фарфор

В этой книге было описано, как пользоваться Git, применяя примерно три десятка команд, например, checkout, branch, remote и т.п. Но так как сначала Git был скорее инструментарием для создания СКВ, чем СКВ, удобной для пользователей, в нём полно команд, выполняющих низкоуровневые операции, которые спроектированы так, чтобы их можно было использовать в цепочку в стиле UNIX, а также использовать в сценариях. Эти команды, как правило, называют служебными ("plumbing" — трубопровод), а ориентированные на пользователя называют пользовательскими ("porcelain" — фарфор).

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

Когда вы выполняете git init в новой или существовавшей ранее директории, Git создаёт подкаталог .git, в котором располагается почти всё, чем он заправляет. Если требуется выполнить резервное копирование или клонирование репозитория, достаточно скопировать всего лишь этот каталог, чтобы получить почти всё необходимое. И данная глава почти полностью посвящена его содержимому. Вот так он выглядит:

$ ls -F1
HEAD
config*
description
hooks/
info/
objects/
refs/

Там могут быть и другие файлы, но выше приведён листинг свежесозданного репозитория — это то, что вы увидите непосредственно после git init. Файл description используется только программой GitWeb, не обращайте на него внимание. Файл config содержит специфичные для этого репозитория конфигурационные параметры, а в директории info расположен файл с глобальными настройкам игнорирования файлов  — он позволяет исключить файлы, которые вы не хотите помещать в .gitignore. В директории hooks располагаются клиентские и серверные триггеры, подробно рассмотренные в главе Хуки в Git.

Итак, осталось четыре важных элемента: файлы HEAD и index (ещё не созданный) и директории objects и refs. Это ключевые элементы Git. В директории objects находится, собственно, база данных объектов Git; в refs — ссылки на объекты коммитов в этой базе (ветки); файл HEAD указывает на текущую ветку, a в файле index хранится содержимое индекса. Сейчас мы детально разберёмся с этими элементами, чтобы понять как работает Git.