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

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

$git gc

Counting objects: 18, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (14/14), done.

Writing objects: 100% (18/18), done.

Total 18 (delta 3), reused 0 (delta 0)

Если вы загляните в директорию с объектами, вы обнаружите, что большая часть объектов исчезла, зато появились два новых файла:

$find .git/objects -type f

.git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37

.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

.git/objects/info/packs

.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx

.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack

Оставшиеся объекты — это блобы, на которые не указывает ни один коммит. В нашем случае это созданные ранее объекты: содержащий строку "what is up, doc?", и "test content". В силу того, что ни в одном коммите данные файлы не присутствуют, они считаются "висячими" и не упаковываются.

Остальные файлы — это pack-файл и его индекс. Pack-файл — это файл, который теперь содержит все удалённые объекты. Индекс — это файл, в котором записаны смещения прежних объектов в pack-файле для быстрого поиска. Упаковка данных положительно повлияла на общий размер файлов: если до вызова gc они занимали примерно 22 Кб, то pack-файл занимает всего 7 Кбайт. Мы только что освободили ⅔ занимаемого дискового пространства!

Как Git это делает? При упаковке Git ищет похожие по имени и размеру файлы и сохраняет только разницу между соседними версиями. Можно заглянуть в pack-файл чтобы понять, какие действия выполняются при сжатии. Для просмотра содержимого упакованного файла существует служебная команда git verify-pack:

$git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx

2431da676938450a4d72e260db3bf7b0f587bbc1 commit 223 155 12

69bcdaff5328278ab1c0812ce0e07fa7d26a96d7 commit 214 152 167

80d02664cb23ed55b226516648c7ad5d0a3deb90 commit 214 145 319

43168a18b7613d1281e5560855a83eb8fde3d687 commit 213 146 464

092917823486a802e94d727c820a9024e14a1fc2 commit 214 146 610

702470739ce72005e2edff522fde85d52a65df9b commit 165 118 756

d368d0ac0678cbe6cce505be58126d3526706e54 tag 130 122 874

fe879577cb8cffcdf25441725141e310dd7d239b tree 136 136 996

d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree 36 46 1132

deef2e1b793907545e50a2ea2ddb5ba6c58c4506 tree 136 136 1178

d982c7cb2c2a972ee391a85da481fc1f9127a01d tree 6 17 1314 1 \

deef2e1b793907545e50a2ea2ddb5ba6c58c4506

3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree 8 19 1331 1 \

deef2e1b793907545e50a2ea2ddb5ba6c58c4506

0155eb4229851634a0f03eb265b69f5a2d56f341 tree 71 76 1350

83baae61804e65cc73a7201a7252750c76066a30 blob 10 19 1426

fa49b077972391ad58037050f2a75f74e3671e92 blob 9 18 1445

b042a60ef7dff760008df33cee372b945b6e884e blob 22054 5799 1463

033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 9 20 7262 1 \

b042a60ef7dff760008df33cee372b945b6e884e

1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob 10 19 7282

non delta: 15 objects

chain length = 1: 3 objects

.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack: ok

Здесь блоб 033b4, который, как мы помним, был первой версией файла repo.rb, ссылается на блоб b042a, который хранит вторую его версию. Третья колонка в выводе — это размер содержимого объекта. Как видите, b042a занимает 22 Кб, а 033b4 — всего 9 байт. Что интересно, вторая версия файла сохраняется "как есть", а первая — в виде дельты: ведь скорее всего вам понадобится быстрый доступ к самым последним версиям файла.

Также здорово, что переупаковку можно выполнять в любое время. Время от времени Git будет выполнять её автоматически, чтобы сэкономить место на диске, но всегда можно инициировать упаковку, выполнив git gc.

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

$git remote add origin https://github.com/schacon/simplegit-progit

Эта команда добавляет секцию в файл .git/config, в которой заданы имя удалённого репозитория (origin), его URL и спецификация ссылок для извлечения данных:

[remote "origin"]

url = https://github.com/schacon/simplegit-progit

fetch = +refs/heads/*:refs/remotes/origin/*

Формат спецификации следующий: опциональный +, далее пара :, где — шаблон ссылок в удалённом репозитории, а — соответствующий шаблон локальных ссылок. Символ + сообщает Git, что обновление необходимо выполнять даже в том случае, если оно не является перемоткой (fast-forward).

По умолчанию, после выполнения git remote add, Git забирает все ссылки из refs/heads/ на сервере, и записывает их в refs/remotes/origin/ локально. Таким образом, если на сервере есть ветка master, журнал данной ветки можно получить, вызвав:

$git log origin/master

$git log remotes/origin/master

$git log refs/remotes/origin/master

Все эти команды эквивалентны, так как Git развернёт каждую запись до refs/remotes/origin/master.

Если хочется, чтобы Git забирал при обновлении только ветку master, а не все доступные на сервере, можно изменить соответствующую строку в конфигурации:

fetch = +refs/heads/master:refs/remotes/origin/master

Эта настройка будет использоваться по умолчанию при вызове git fetch для данного удалённого репозитория. Если же вам нужно изменить спецификацию всего раз, можно задать refspec в командной строке. Например, чтобы получить данные из ветки master из удалённого репозитория в локальную origin/mymaster, можно выполнить:

$git fetch origin master:refs/remotes/origin/mymaster

Можно задать несколько и спецификаций за один раз. Получить данные нескольких веток из командной строки можно так:

$git fetch origin master:refs/remotes/origin/mymaster \

topic:refs/remotes/origin/topic

From git@github.com:schacon/simplegit

! [rejected] master -> origin/mymaster (non fast forward)

* [new branch] topic -> origin/topic

В данном случае слияние ветки master выполнить не удалось, поскольку слияние не было "быстрой перемоткой". Такое поведение можно изменить, добавив перед спецификацией знак +.

В конфигурационном файле также можно задавать несколько спецификаций для получения обновлений. Чтобы каждый раз получать обновления веток master и experiment, добавьте две такие строки:

[remote "origin"]

url = https://github.com/schacon/simplegit-progit

fetch = +refs/heads/master:refs/remotes/origin/master

fetch = +refs/heads/experiment:refs/remotes/origin/experiment

Задавать маску частично в спецификации нельзя, следующая запись неверна:

fetch = +refs/heads/qa*:refs/remotes/origin/qa*

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

[remote "origin"]

url = https://github.com/schacon/simplegit-progit

fetch = +refs/heads/master:refs/remotes/origin/master

fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*

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