Скотт Чакон - Pro Git

pack_report: core.packedGitLimit = 8589934592

pack_report: pack_used_ctr = 10

pack_report: pack_mmap_calls = 5

pack_report: pack_open_windows = 2 / 2

pack_report: pack_mapped = 1457 / 1457

---------------------------------------------------------------------

Как вы можете видеть, после успешного завершения fast-import выводит некоторую статистику о проделанной работе. В этом случае, вы импортировали 13 объектов в 4-х коммитах одной ветки. Теперь можете выполнить git log просмотреть созданную историю коммитов:

$git log -2

commit 3caa046d4aac682a55867132ccdfbe0d3fdee498

Author: John Doe

Date: Tue Jul 29 19:39:04 2014 -0700

imported from current

commit 4afc2b945d0d3c8cd00556fbe2e8224569dc9def

Author: John Doe

Date: Mon Feb 3 01:00:00 2014 -0700

imported from back_2014_02_03

Вот он: ваш новый классный Git репозиторий! Обратите внимание, ваша рабочая директория пуста, активная ветка не выбрана. Переключимся на ветку master:

$ls

$git reset --hard master

HEAD is now at 3caa046 imported from current

$ls

README.md main.rb

Функциональность fast-import гораздо шире описанного: он поддерживает права доступа к файлам, двоичные файлы, множественные ветки и их слияния, метки, индикатор прогресса и ещё кучу вещей. Несколько примеров более сложных сценариев использования fast-import можно найти в директории contrib/fast-import исходного кода Git.

После всего вышесказанного вы должны чувствовать себя уверенно, используя Git как клиент для других СКВ, или, импортируя практически любой существующий репозиторий в Git без потери данных. Следующая глава раскроет перед вами внутреннюю механику 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 Hooks.

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

Git — контентно-адресуемая файловая система. Здорово. Что это означает? А означает это, по сути, что Git — простое хранилище ключ-значение. Можно добавить туда любые данные, в ответ будет выдан ключ по которому их можно извлечь обратно. Например, можно воспользоваться служебной командой hash-object, добавляющей данные в директорию .git и возвращающей ключ. Для начала создадим новый Git-репозиторий и убедимся, что директория objects пуста:

$git init test

Initialized empty Git repository in /tmp/test/.git/

$cd test

$find .git/objects

.git/objects

.git/objects/info

.git/objects/pack

$find .git/objects -type f

Git проинициализировал директорию objects и создал в нём пустые поддиректории pack и info. Теперь добавим кое-какое текстовое содержимое в базу Git:

$echo 'test content' | git hash-object -w --stdin

d670460b4b4aece5915caf5c68d12f560a9fe3e4

Ключ -w указывает команде hash-object, что объект необходимо сохранить, иначе команда просто вернёт ключ. Флаг --stdin указывает, что данные необходимо считать из потока стандартного ввода, в противном случае hash-object ожидает путь к файлу в качестве аргумента. Вывод команды — 40-символьная контрольная сумма. Это хеш SHA-1 — контрольная сумма содержимого и заголовка, который будет рассмотрен позднее. Теперь можно увидеть, в каком виде сохранены ваши данные: