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

=> 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.

Обратите внимание, последняя строка файла начинается с ^. Это означает, что метка на предыдущей строке является аннотированной меткой и данная строка — это коммит, на который аннотированная метка указывает.

В какой-то момент при работе с Git вы можете нечаянно потерять коммит. Как правило, такое случается, когда вы удаляете ветку, в которой находились некоторые наработки, а потом оказывается, что они всё-таки были нужными; либо вы выполнили git reset --hard, тем самым отказавшись от коммитов, которые затем понадобились. Как же в таком случае заполучить свои коммиты обратно?

Ниже приведён пример, в котором мы сбрасываем ветку master с потерей данных до более раннего состояния, а затем восстанавливаем потерянные коммиты. Для начала, давайте посмотрим, как сейчас выглядит история изменений:

$git log --pretty=oneline

ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit

484a59275031909e19aadb7c92262719cfcdf19a added repo.rb

1a410efbd13591db07496601ebc7a059dd55cfe9 third commit

cac0cab538b970a37ea1e769cbbde608743bc96d second commit

fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit

Теперь сбросим ветку master на третий коммит:

$git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9

HEAD is now at 1a410ef third commit

$git log --pretty=oneline

1a410efbd13591db07496601ebc7a059dd55cfe9 third commit

cac0cab538b970a37ea1e769cbbde608743bc96d second commit

fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit

Итак, теперь два последних коммита по-настоящему потеряны — они не достижимы ни из одной ветки. Необходимо найти SHA-1 последнего коммита и создать ветку, указывающую на неё. Сложность в том, чтобы узнать этот самый SHA-1, ведь вряд ли вы его запомнили, да?