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

delete-refs side-band-64k quiet ofs-delta \

agent=git/2:2.1.1+github-607-gfba4028 delete-refs

003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic

0000

Команда git-receive-pack тут же посылает в ответ по одной строке на каждую из имеющихся в наличии ссылок — в данном случае только ветку master и её SHA-1. Первая строка также содержит список возможностей сервера (здесь это report-status, delete-refs и парочка других, включая версию используемого процесса).

Каждая строка начинается с 4-байтового шестнадцатеричного значения, содержащего длину оставшейся части строки. Первая строка начинается с 005b, это 91 в десятичной системе счисления, значит в этой строке ещё 91 байт. Следующая строка начинается с 003e (62), то есть надо прочитать ещё 62 байта. Далее следует 0000, означающая конец списка ссылок.

Теперь, когда send-pack выяснил состояние сервера, он определяет коммиты, которые есть локально, но отсутствующие на сервере. Для каждой ссылки, которая будет обновлена командой push, процесс send-pack передаёт процессу receive-pack эти данные. Например, если мы обновляем ветку master, и добавляем ветку experiment, ответ send-pack будет выглядеть следующим образом:

0085ca82a6dff817ec66f44342007202690a93763949 15027957951b64cf874c3557a0f3547bd83b3ff6 \

refs/heads/master report-status

00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d \

refs/heads/experiment

0000

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

Затем клиент посылает pack-файл c объектами, которых нет на сервере. В конце сервер передаёт статус операции – успех или ошибка:

000Aunpack ok

Этот процесс похож на HTTP, но установка соединения слегка отличается. Всё начинается с такого запроса:

=> GET http://server/simplegit-progit.git/info/refs?service=git-receive-pack

001f# service=git-receive-pack

000000ab6c5f0e45abd7832bf23074a333f739977c9e8188 refs/heads/master \

report-status delete-refs side-band-64k quiet ofs-delta \

agent=git/2:2.1.1~vmg-bitmaps-bugaloo-608-g116744e

0000

Это всё, что передаётся в ответ на первый запрос. Затем клиент делает второй запрос, на этот раз POST, передавая данные, полученные от команды git-upload-pack.

=> POST http://server/simplegit-progit.git/git-receive-pack

Этот запрос включает в себя результаты send-pack и собственно pack-файлы. Сервер, используя код состояния HTTP, возвращает результат операции.

Для получения данных из удалённых репозиториев используются процессы fetch-pack и upload-pack. Клиент запускает процесс fetch-pack, который подключается к процессу upload-pack на сервере для определения подлежащих передаче данных.

Если вы работаете через SSH, fetch-pack выполняет примерно такую команду:

$ssh -x git@server "git-upload-pack 'simplegit-progit.git'"

Как только fetch-pack подключается к upload-pack, тот отсылает обратно следующее:

00dfca82a6dff817ec66f44342007202690a93763949 HEADmulti_ack thin-pack \

side-band side-band-64k ofs-delta shallow no-progress include-tag \

multi_ack_detailed symref=HEAD:refs/heads/master \

agent=git/2:2.1.1+github-607-gfba4028

003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master

0000

Это очень похоже на ответ receive-pack, но только возможности другие. Вдобавок upload-pack отсылает обратно ссылку HEAD, чтобы клиент понимал, на какую ветку переключиться, если выполняется клонирование.

На данном этапе процесс fetch-pack смотрит на объекты, имеющиеся в наличии, и для недостающих объектов отвечает словом "want" + соответствующий SHA-1. Для уже имеющихся объектов процесс отправляет их хеши со словом "have". В конце списка он пишет "done", и это даёт понять процессу upload-pack, что пора начинать отправлять упакованный pack-файл с необходимыми данными:

0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta

0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7

0000

0009done

"Рукопожатие" для процесса получения недостающих данных занимает два HTTP запроса. Первый — это GET запрос на тот же URL, что и в случае глупого протокола:

=> GET $GIT_URL/info/refs?service=git-upload-pack

001e# service=git-upload-pack

000000e7ca82a6dff817ec66f44342007202690a93763949 HEADmulti_ack thin-pack \

side-band side-band-64k ofs-delta shallow no-progress include-tag \

multi_ack_detailed no-done symref=HEAD:refs/heads/master \

agent=git/2:2.1.1+github-607-gfba4028

003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master

0000

Это очень похоже на использование git-upload-pack по SSH, вот только обмен данными производится отдельным запросом:

=> POST $GIT_URL/git-upload-pack HTTP/1.0

0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7

0032have 441b40d833fdfa93eb2908e52742248faf0ee993

0000

Используется тот же формат что и ранее: В ответ сервер посылает статус операции и сгенерированный pack-файл.

В этом разделе мы вкратце рассмотрели протоколы передачи данных. Протоколы обмена данных в Git включают в себя множество фич — типа multi_ack или side-band — рассмотрение которых выходит за пределы этой книги. Мы описали формат сообщений между клиентом и сервером не вдаваясь в детали, если хотите покопаться в этой теме глубже — обратитесь к исходному коду Git.

Изредка вам потребуется делать "уборку" — сделать репозиторий более компактным, очистить импортированный репозиторий от лишних файлов или восстановить потерянные данные. Данный раздел охватывает некоторые из этих сценариев.

Время от времени Git выполняет автоматическую сборку мусора. Чаще всего эта команда ничего не делает. Однако, если у вас накопилось слишком много "рыхлых" объектов (не в pack-файлах), или, наоборот, отдельных pack-файлов, Git запускает полноценный сборщик — git gc. Здесь "gc" это сокращение от "garbage collect", что означает "сборка мусора". Эта команда выполняет несколько действий: собирает все рыхлые объекты и упаковывает их в pack-файлы; объединяет несколько упакованных файлов в один большой; удаляет недостижимые объекты, хранящиеся дольше нескольких месяцев.

Можно запустить сборку мусора вручную:

$git gc --auto

Опять же, как правило, эта команда ничего не делает. Нужно иметь примерно 7000 несжатых объектов или более 50 pack-файлов, чтобы запустился настоящий gc. Эти значения можно изменить с помощью параметров gc.auto и gc.autopacklimit соответственно.

Ещё одно действие, выполняемое gc — упаковка ссылок в единый файл. Предположим, репозиторий содержит следующие ветки и теги:

$find .git/refs -type f

.git/refs/heads/experiment

.git/refs/heads/master

.git/refs/tags/v1.0

.git/refs/tags/v1.1

Если выполнить git gc, эти файлы будут удалены из директории refs. Git перенесёт их в файл .git/packed-refs в угоду эффективности:

$cat .git/packed-refs

#pack-refs with: peeled fully-peeled

cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment

ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master

cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0

9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1

^1a410efbd13591db07496601ebc7a059dd55cfe9

При обновлении ссылки Git не будет редактировать этот файл, а добавит новый файл в refs/heads. Для получения хеша, соответствующего нужной ссылке, Git сначала проверит наличие файла ссылки в директории refs, а к файлу packed-refs обратится только в случае отсутствия оного. Так что, если вы не можете найти ссылку в директории refs, скорее всего она упакована в файле packed-refs.