1.1Объекты

Посмотришь, из каких четырёх типов объектов состоит база Git и как содержимое становится адресом объекта. Поймёшь, почему коммит хранит снимок, а diff вычисляется между снимками.

Словарь, где ключ вычисляют из содержимого

В каталоге .git/objects Git держит словарь. Значения в нём хранятся как байты, а ключом служит SHA-1 от этих байтов, 40 шестнадцатеричных знаков. Ключ никто не выдаёт по счётчику, его вычисляют из содержимого. Такое хранилище называют адресуемым по содержимому, ключ называют хешем или идентификатором объекта. Ветки, индекс, слияния и журнал ссылок надстроены сверху, внизу всегда этот словарь.

Потрогать его руками можно двумя служебными командами. git hash-object считает хеш данных, а с флагом -w ещё и записывает объект. git cat-file читает: -t печатает тип объекта, -s размер в байтах, -p содержимое в виде, удобном человеку.

$ git init -q demo
$ cd demo
$ echo 'hello' | git hash-object --stdin      # только посчитать
ce013625030ba8dba906f756967f9e9ca394464a
$ find .git/objects -type f                    # хранилище пустое
$ echo 'hello' | git hash-object -w --stdin   # посчитать и записать
ce013625030ba8dba906f756967f9e9ca394464a
$ find .git/objects -type f
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
$ git cat-file -t ce01362
blob
$ git cat-file -s ce01362
6
$ git cat-file -p ce01362
hello

Хеш попал прямо в путь к файлу: первые два знака стали каталогом, остальные 38 именем. Внутри файла содержимое сжато zlib, а как объекты потом собираются в pack-файлы, разобрано в главе 1.4. Обращаться к объекту можно по началу хеша, пока оно однозначно. Git и сам печатает сокращённые хеши, в небольшом репозитории по семь знаков.

Одни и те же байты дают один и тот же ключ в любом репозитории и на любой машине. Два одинаковых файла хранятся одним объектом, а чтобы узнать, есть ли у соседа объект, хватает сравнить хеши. Типов объектов четыре. Blob хранит содержимое файла, tree описывает каталог, commit фиксирует снимок проекта вместе с автором и сообщением, tag даёт объекту постоянное имя со своим автором и сообщением.

Хеш блоба можно посчитать без Git

SHA-1 считается от содержимого с заголовком. Git приклеивает спереди тип объекта, пробел, длину содержимого в байтах десятичным числом и нулевой байт. В строке hello с переводом строки шесть байтов, поэтому хешируется blob 6\0hello\n. Проверим обычной утилитой:

$ printf 'blob 6\0hello\n' | sha1sum
ce013625030ba8dba906f756967f9e9ca394464a  -
$ printf 'привет\n' | git hash-object --stdin
d0f56e135b2282bfdd87b1cae5d0238b6a193ab5
$ printf 'blob 13\0привет\n' | sha1sum   # шесть букв по 2 байта в UTF-8 и \n
d0f56e135b2282bfdd87b1cae5d0238b6a193ab5  -
$ printf 'blob 7\0привет\n' | sha1sum    # длина в символах: мимо
ed2cf1d8d16385c47dba744ed71406200ac784b4  -

На Go это одна функция. hash.Hash реализует io.Writer, так что заголовок пишется в хешер обычным fmt.Fprintf:

package main

import (
    "crypto/sha1"
    "fmt"
    "io"
    "os"
)

// blobID возвращает хеш, под которым git сохранит data как blob.
func blobID(data []byte) string {
    h := sha1.New()
    fmt.Fprintf(h, "blob %d\x00", len(data)) // заголовок: длина в байтах
    h.Write(data)                            // потом сами байты
    return fmt.Sprintf("%x", h.Sum(nil))
}

func main() {
    data, err := io.ReadAll(os.Stdin)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(blobID(data))
}

$ go run . < ../hello/main.go
76a11ee950609a691b24c9fd990544d89e4e40a4
$ git -C ../hello hash-object main.go
76a11ee950609a691b24c9fd990544d89e4e40a4

Tree, commit и tag хешируются так же, только в заголовке стоит их тип. Поэтому блоб и коммит с одинаковыми байтами получили бы разные хеши, а Git, читая объект, по первым байтам сразу узнаёт, что перед ним и сколько читать.

Blob: содержимое без имени

Blob хранит байты файла, и больше в нём ничего нет: ни имени, ни пути, ни прав доступа, ни даты изменения. Проверить легко. Положим в репозиторий скрипт с правом на исполнение, его копию без этого права и символическую ссылку check на скрипт:

$ git ls-tree -r HEAD
120000 blob 423782a0232338be5b86843b6774679a3da6e394    check
100644 blob e64013c8cc937938973c3492df8580d9b0f11353    docs/check.sh.example
100755 blob e64013c8cc937938973c3492df8580d9b0f11353    scripts/check.sh
$ git cat-file -p HEAD:check
scripts/check.sh

Скрипт и его копия ссылаются на один блоб e64013c. Право на исполнение записано рядом с хешем, в дереве. У символической ссылки тоже есть блоб, и лежит в нём путь, на который она указывает.

Файл, скопированный в пять мест, лежит в хранилище одним объектом. Если вернуть файл к прошлогодней версии байт в байт, новый объект не появится: Git возьмёт старый. А пустой каталог хранить не в чем: дерево перечисляет файлы, и git add empty/ молча ничего не добавит. Поэтому в пустые каталоги по договорённости кладут файл .gitkeep.

Tree: имена, режимы и ссылки

Tree (дерево) описывает один каталог. Это список записей, в каждой режим, тип, хеш и имя. Подкаталог выглядит записью со ссылкой на другое дерево. Возьмём маленький Go-проект из трёх файлов: go.mod, main.go и greet/greet.go. Сделаем первый коммит и спустимся от него вниз.

$ git add . && git commit -qm 'Первый коммит'
$ git cat-file -p HEAD
tree 49054b8fff495d8c56358f06542b7a14543b6804
author Аня <anya@example.com> 1788246000 +0300
committer Аня <anya@example.com> 1788246000 +0300

Первый коммит
$ git cat-file -p 49054b8
100644 blob 39c5ef80ac37708bfc5a6de808d737b8d9091e19    go.mod
040000 tree a3b4c4b42375cbca7cf23d2c71e1a7ea634efa1a    greet
100644 blob 76a11ee950609a691b24c9fd990544d89e4e40a4    main.go
$ git cat-file -p a3b4c4b
100644 blob b155bfb8e2166b7722fa4efedc6c04b138584e66    greet.go

Режим похож на права в Unix, но Git записывает всего пять значений:

От прав Unix остаётся один бит: исполняемый файл или нет. Владелец, права группы и время изменения в дерево не попадают. chmod 600 go.mod Git не заметит, а после chmod +x go.mod git diff покажет old mode 100644 и new mode 100755.

-p печатает дерево для человека. В самом объекте запись компактнее: режим текстом без ведущего нуля, пробел, имя, нулевой байт и 20 байтов хеша в двоичном виде. Это видно в выводе git cat-file tree 49054b8 | xxd. Хеш дерева считается от этих байтов, а в них входят имена, режимы и хеши детей. Два каталога с одинаковыми файлами в разных местах проекта дадут одно и то же дерево. А правка одного файла меняет хеш его каталога, каталога над ним и так до корня.

Commit: снимок и кто его сделал

Commit хранится как текст. Первая строка ссылается на корневое дерево, то есть на полный снимок проекта. Следом идут строки parent: у первого коммита их нет, у обычного одна, у merge-коммита две и больше (граф истории разобран в главе 1.2). Дальше автор, коммиттер, пустая строка и сообщение. Время записано секундами Unix с часовым поясом: 1788246000 +0300 значит 1 сентября 2026 года, 10:00 по UTC+3.

Добавим в greet/greet.go комментарий и восклицательный знак и закоммитим ещё раз:

$ git commit -qam 'Добавить восклицательный знак'
$ git cat-file -p HEAD
tree 65ee622dc0857c2a9692a922fb891175f7c9b466
parent 9a69d12ebd717c5e220cda3cb94ece4c1f6e9e9f
author Аня <anya@example.com> 1788337800 +0300
committer Аня <anya@example.com> 1788337800 +0300

Добавить восклицательный знак

$ git ls-tree -r -t --abbrev HEAD~1
100644 blob 39c5ef8     go.mod
040000 tree a3b4c4b     greet
100644 blob b155bfb     greet/greet.go
100644 blob 76a11ee     main.go

$ git ls-tree -r -t --abbrev HEAD
100644 blob 39c5ef8     go.mod
040000 tree f84cebe     greet
100644 blob 14ebcef     greet/greet.go
100644 blob 76a11ee     main.go

Второй коммит тоже ссылается на полный снимок, но новых объектов в хранилище всего четыре: блоб с новым текстом greet.go, дерево greet, корневое дерево и сам коммит. go.mod и main.go не менялись, и новое корневое дерево ссылается на те же 39c5ef8 и 76a11ee. Всего в репозитории десять объектов, и git cat-file --batch-all-objects --batch-check перечислит их все с типами и размерами.

Так что Git хранит снимки. Diff из git show нигде не записан: Git сравнивает дерево коммита с деревом родителя при каждом вызове, и это дёшево, потому что записи с одинаковым хешем можно не открывать. Место на похожих версиях файлов экономит упаковка в pack-файлы (глава 1.4), модель объектов про неё не знает.

Хеш коммита считается так же, как хеш блоба, только от текста коммита. Проверить можно sha1sum, а можно собрать коммит заново низкоуровневой командой git commit-tree. Ей передают дерево, родителя и сообщение, а имена и время она, как обычный commit, читает из настроек и переменных GIT_AUTHOR_* и GIT_COMMITTER_*. Здесь в переменных стоит время второго коммита.

$ git cat-file -s HEAD
255
$ (printf 'commit 255\0'; git cat-file commit HEAD) | sha1sum
5e90c6adbe2018ea6d87ed3e11426a4e295bdde7  -
$ git commit-tree 65ee622 -p 9a69d12 -m 'Добавить восклицательный знак'
5e90c6adbe2018ea6d87ed3e11426a4e295bdde7
$ GIT_COMMITTER_DATE='2026-09-02T11:31:00+03:00' \
    git commit-tree 65ee622 -p 9a69d12 -m 'Добавить восклицательный знак'
37c1e3da319b8f7a562766999fb2878226574459

Те же дерево, родитель, люди, время и сообщение дали тот же 5e90c6a: такой объект в хранилище уже был. Время коммиттера сдвинулось на минуту, и вышел другой коммит. Хеш зависит от каждого байта снимка, родителей, имён, дат и текста сообщения.

Author написал изменение, committer записал этот коммит. Обычно это один человек в одну и ту же секунду. Расходятся они, когда коммит пересоздают: cherry-pick, rebase, commit --amend, git am. Вот коммит Ани после того, как Боря перенёс его через cherry-pick на ветку от того же родителя:

$ git cat-file -p HEAD
tree 65ee622dc0857c2a9692a922fb891175f7c9b466
parent 9a69d12ebd717c5e220cda3cb94ece4c1f6e9e9f
author Аня <anya@example.com> 1788337800 +0300
committer Боря <borya@example.com> 1788609600 +0300

Добавить восклицательный знак

Дерево, родитель, автор и сообщение совпадают с 5e90c6a до байта, но из-за строки коммиттера хеш у копии другой, 2d862ef.

Annotated tag

Четвёртый тип объекта, tag, создаёт git tag -a (или git tag -s с подписью). Получается annotated tag: объект со ссылкой на другой объект, своим автором в строке tagger, датой и сообщением. git tag без флагов объекта не создаёт, а делает lightweight tag: просто ссылку с именем прямо на коммит.

$ git tag -a v0.1.0 -m 'Первый релиз'
$ git tag v0.1.0-light
$ git cat-file -t v0.1.0
tag
$ git cat-file -p v0.1.0
object 5e90c6adbe2018ea6d87ed3e11426a4e295bdde7
type commit
tag v0.1.0
tagger Аня <anya@example.com> 1788512400 +0300

Первый релиз
$ git cat-file -t v0.1.0-light
commit
$ git rev-parse v0.1.0 v0.1.0-light 'v0.1.0^{commit}'
588621ef8b4fcb85e2a41f7ba24367cd6a24e7a0
5e90c6adbe2018ea6d87ed3e11426a4e295bdde7
5e90c6adbe2018ea6d87ed3e11426a4e295bdde7

Имя v0.1.0 ведёт к объекту тега 588621e, тот к коммиту, а суффикс ^{commit} проходит цепочку до конца. Строка type нужна, потому что пометить можно любой объект: git tag -a gomod-v0.1.0 -m '…' HEAD:go.mod даст тег с type blob. Ссылки разобраны в главе 1.2, теги для релизов и Go-модулей в главе 4.3.

Переименований Git не хранит

Ни в одном из четырёх типов нет поля «раньше этот файл назывался так-то». Посмотрим на репозиторий, где лежит store.go:

$ git mv store.go memstore.go
$ git status --short
R  store.go -> memstore.go
$ git commit -qm 'Переименовать store.go в memstore.go'
$ git ls-tree HEAD~1
100644 blob 00b62a663c45ccba5f2e42a733fac60a29e40c7c    go.mod
100644 blob 1ea630d8331159f58014d05bab7592e94b607906    store.go
$ git ls-tree HEAD
100644 blob 00b62a663c45ccba5f2e42a733fac60a29e40c7c    go.mod
100644 blob 1ea630d8331159f58014d05bab7592e94b607906    memstore.go
$ git diff-tree -r --abbrev HEAD~1 HEAD
:000000 100644 0000000 1ea630d A        memstore.go
:100644 000000 1ea630d 0000000 D        store.go
$ git diff-tree -r -M --abbrev HEAD~1 HEAD
:100644 100644 1ea630d 1ea630d R100     store.go        memstore.go

Деревья отличаются одним именем, блоб тот же. Низкоуровневая diff-tree показывает то, что есть в объектах: memstore.go появился (A), store.go исчез (D). Переименование возникает только с флагом -M, когда Git сам ищет пары «удалён - добавлен» с похожим содержимым. diff, log и show ищут такие пары по умолчанию с Git 2.9, status тоже ищет. А git mv ничего особого не записывает: mv и git add обоих путей дают тот же R в status.

Похожесть Git оценивает грубо, зато быстро. Сначала ищутся точные совпадения: одинаковый хеш блоба означает переименование без правок, R100. Для остальных пар оба файла режутся на куски по строкам (длинная строка дробится по 64 байта), и Git считает, сколько байтов старого файла дошло до нового. Их делят на размер большего из двух файлов. Порог по умолчанию 50 %, задаётся он как -M<n>, например -M40%.

$ git mv memstore.go catalog.go
$ # в catalog.go тип Store переименован в Catalog, получатель s в c
$ git add catalog.go && git status --short
R  memstore.go -> catalog.go
$ git diff --cached --stat
 memstore.go => catalog.go | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
$ git diff --cached | head -2
diff --git a/memstore.go b/catalog.go
similarity index 52%
$ git commit -qm 'Store теперь Catalog'

Изменилось 7 строк из 31, но строки длинные: 206 байтов из 446. Поэтому похожесть уже 52 %, на волоске от порога. В копии репозитория, где ещё лежит memstore.go, повторим тот же шаг с одной лишней правкой: в Get переменная it станет item. Восьмая изменённая строка опускает оценку ниже порога:

$ git mv memstore.go catalog.go
$ git add catalog.go && git status --short
A  catalog.go
D  memstore.go
$ git diff --cached -M40% --stat
 memstore.go => catalog.go | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
$ git diff --cached -M40% | head -2
diff --git a/memstore.go b/catalog.go
similarity index 48%

На том же спотыкается история файла. git log -- catalog.go отбирает коммиты, которые трогали путь catalog.go, и путь кончается на переименовании. --follow каждый раз, когда файл «появился», проверяет, не переименование ли это, и идёт дальше по старому имени:

$ git log --oneline -- catalog.go
2b8fa25 Store теперь Catalog
$ git log --oneline --name-status --follow -- catalog.go
2b8fa25 Store теперь Catalog
R052    memstore.go     catalog.go
53999bb Переименовать store.go в memstore.go
R100    store.go        memstore.go
c8f9d28 Хранилище товаров
A       store.go
$ git log --oneline --follow -M60% -- catalog.go
2b8fa25 Store теперь Catalog

Порог у --follow тот же, что у -M: при -M60% шаг через R052 уже не находится. --follow берёт только один файл, а на нелинейной истории, как предупреждает документация, справляется плохо. Чтобы git log с одним путём всегда шёл по переименованиям, есть настройка log.follow=true.

SHA-1, SHAttered и SHA-256

Всё держится на том, что разные данные дают разные хеши. Случайно получить два объекта с одним 160-битным хешем нереально. Опасна коллизия, изготовленная нарочно: подпись тега заверяет хеш, а за ним оказались бы два содержимого, одно для ревью, другое для сборки.

23 февраля 2017 года исследователи CWI Amsterdam и Google опубликовали атаку SHAttered: два разных PDF с одинаковым SHA-1. На неё ушло 2⁶³, около девяти квинтиллионов, вычислений SHA-1: 6500 лет процессорного времени и 110 лет работы видеокарт. В 2020 году авторы атаки Shambles построили коллизию с выбранным префиксом и оценили её стоимость примерно в 45 тысяч долларов. PDF из SHAttered лежат, например, в каталоге test/ репозитория sha1collisiondetection:

$ sha1sum shattered-1.pdf shattered-2.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf
$ cmp shattered-1.pdf shattered-2.pdf
shattered-1.pdf shattered-2.pdf differ: char 193, line 8
$ git hash-object shattered-1.pdf shattered-2.pdf
ba9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0
b621eeccd5c7edac9b7dcba35a8d5afd075e24f2

В Git эти файлы не сталкиваются: из-за заголовка blob 422435\0 SHA-1 подходит к подобранным блокам в другом внутреннем состоянии. Но коллизию можно посчитать сразу с заголовком и по той же цене, так что защищаться Git всё равно пришлось.

С версии 2.13 (май 2017) Git по умолчанию считает хеши через hardened SHA-1, библиотеку SHA-1DC Марка Стивенса (CWI) и Дэна Шумова (Microsoft). На обычных данных она выдаёт обычный SHA-1, ни один существующий хеш не поменялся. Попутно она ищет в каждом блоке следы известных атак, а если находит, Git останавливается с ошибкой SHA-1 appears to be part of a collision attack. Ложное срабатывание авторы оценивают вероятностью меньше 2^-90. Что именно собрано в твой git, видно так (вывод git 2.54 из поставки macOS, в других сборках строки SHA-256 могут отличаться):

$ git version --build-options | grep -i sha
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-hash: sha1

Hardened SHA-1 закрывает известные атаки, но от будущих спасёт только другой алгоритм. С версии 2.29 Git умеет репозитории на SHA-256:

$ git init -q --object-format=sha256 s256
$ cd s256
$ git rev-parse --show-object-format
sha256
$ echo 'hello' | git hash-object --stdin
2cf8d83d9ee29543b34a87727421fdecb7e3f3a183d337639025de576db9ebb4
$ printf 'blob 6\0hello\n' | sha256sum
2cf8d83d9ee29543b34a87727421fdecb7e3f3a183d337639025de576db9ebb4  -
$ echo 'hello' > f && git add f && git commit -qm 'Первый коммит'
$ git push ../bare1.git HEAD:main     # bare1.git создан на SHA-1
fatal: the receiving end does not support this repository's hash algorithm

Объекты устроены так же, меняются функция и длина хеша: 64 знака вместо 40. Формат выбирается один раз при init и записывается в конфиг репозитория как extensions.objectformat, клон его наследует. Репозитории на SHA-1 и SHA-256 друг с другом не разговаривают: ни push, ни fetch не проходят. Перевести проект можно только переписав всю историю, например через git fast-export и git fast-import в новый репозиторий, и хеши всех коммитов при этом сменятся.

В 2.42 с формата сняли пометку экспериментального, в 2.51 объявили план: Git 3.0 должен создавать новые репозитории на SHA-256. Упирается всё в экосистему: GitHub такие репозитории не поддерживает, в GitLab это эксперимент за флагом, выключенным по умолчанию. Для рабочего проекта SHA-256 годится, только если его понимает весь путь кода, от хостинга до CI.

$ git diff-tree --abbrev HEAD~1 HEAD      # отличается только запись greet
:040000 040000 a3b4c4b f84cebe M        greet
$ git diff-tree -r --abbrev HEAD~1 HEAD   # внутри greet отличается один блоб
:100644 100644 b155bfb 14ebcef M        greet/greet.go
$ git show --format='%h %s' HEAD | head -4
5e90c6a Добавить восклицательный знак

diff --git a/greet/greet.go b/greet/greet.go
index b155bfb..14ebcef 100644

$ git commit-tree 49054b8 -m 'Начальная версия'
74e5c9dc8c195156fb359c80a6263942ca237521
$ git commit-tree 65ee622 -p 74e5c9d -m 'Добавить восклицательный знак'
b4335738085fb0d3abaf84af557d75d9d7509811

$ git cat-file -p 39c5ef8
module example.com/hello

go 1.26
$ git fsck
error: 80a4f6831f60541a926088ae362356f7f3273558: hash-path mismatch, found at: .git/objects/39/c5ef80ac37708bfc5a6de808d737b8d9091e19
missing blob 39c5ef80ac37708bfc5a6de808d737b8d9091e19
$ cd ..
$ git clone -q --no-local forge forge-clone   # forge: репозиторий с подменой
fatal: did not receive expected object 39c5ef80ac37708bfc5a6de808d737b8d9091e19
fatal: fetch-pack: invalid index-pack output

Что стоит запомнить

• Blob хранит содержимое файла без его имени.
• Tree связывает режим, имя и объект; commit указывает на tree и родителей.
• Объект адресуется хешем заголовка и содержимого.

Частые ошибки

• Git не хранит переименование как отдельный объект.
• Diff - вычисление между снимками, а не объект commit.

tree 0b919d88a591bd39ee0b8e37efc92e5ab949dc31
author Fixture <fixture@example.test> 1767225600 +0000
committer Fixture <fixture@example.test> 1767225600 +0000

base

git cat-file -p <blob-hash> | grep main.go