1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-git-lfs

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
spec.md 10 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 10.03.2025 15:23 0f98afb

Спецификация Git LFS

Это общее руководство для клиентов Git LFS. Обычно это должно быть реализовано с помощью командной строки git-lfs, но детали могут быть полезны для других инструментов.

Указатель

Основная идея Git LFS заключается в том, что вместо записи больших объектов в репозиторий Git используется только указатель-файл.

  • Указатель-файлы должны быть текстовыми файлами, которые должны содержать только UTF-8 символы.
  • Каждая строка должна иметь формат {ключ} {значение}\n (конечный Unix новая строка).
  • Между {ключ} и {значение} должен быть только один пробел.
  • Ключи должны использовать только символы [a-z] [0-9] . -.
  • Первый ключ всегда является _версией.
  • Строки пар ключ/значение должны быть отсортированы алфавитически в возрастающем порядке (за исключением версии, которая всегда первая).
  • Значения не должны содержать символов возврата каретки или новой строки.
  • Указатель-файлы должны храниться в Git с битом выполнения, совпадающим с тем, что заменённого файла.
  • Указатель-файлы должны быть меньше 1024 байтов в размере, включая любые строки расширения указателя.
  • Указатель-файлы уникальны: то есть, существует точно одна допустимая кодировка для указатель-файла.

Пустой файл является указателем для пустого файла. То есть, пустые файлы проходят через LFS без каких-либо изменений.Необходимые ключи:

  • версия — это URL, который идентифицирует спецификацию указатель-файла. Парсеры ДОЛЖНЫ использовать простое сравнение строк версии, без использования любого URL-парсинга или нормализации. Это чувствительно к регистру, и %-кодирование не рекомендовано.
  • oid отслеживает уникальный идентификатор объекта для файла, префиксированный методом его хэширования: {метод-хэширования}:{хэш}. В настоящее время поддерживаются только sha256. Хэш представлен в нижнем регистре шестнадцатеричным кодом.
  • размер указан в байтах.

Пример текстового указателя версии 1:

version https://git-lfs.github.com/spec/v1
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 12345
(ending \n)

Объекты, созданные с помощью предварительной версии инструмента, генерируют файлы с другим URL-адресом версии. Git LFS может читать эти файлы, но записывает их используя вышеупомянутый URL-адрес версии.

version https://hawser.github.com/spec/v1
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 12345
(ending \n)

Для тестирования соответствия любого инструмента, создающего свои собственные указатель-файлы, эталоном служит официальный инструмент Git LFS:ЗАМЕЧАНИЕ: поведение команды указателя точно не определено!

  • Инструменты, парсящие и перегенерирующие файлы указателей, ДОЛЖНЫ сохранять ключи, которые они не знают или не используют.
  • Выполните команду pointer, чтобы сгенерировать файл указателя для указанного локального файла:``` $ git lfs pointer --file=путь/к/файлу Указатель Git LFS для путь/к/файлу:

версия https://git-lfs.github.com/spec/v1 oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393 размер 12345


* Выполните команду `pointer`, чтобы сравнить OID объекта бинарного файла (`blob OID`) в файле указателя, созданном Git LFS, с OID в файле указателя, созданном другим инструментом.

  * Запишите указатель другой реализации в "other/pointer/file":

    ``` 
    $ git lfs pointer --file=путь/к/файлу --pointer=other/pointer/file
    Указатель Git LFS для путь/к/файлу:

    версия https://git-lfs.github.com/spec/v1
    oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
    размер 12345

    OID объекта: 60c8d8ab2adcf57a391163a7eeb0cdb8bf348e44

    Указатель из other/pointer/file
    версия https://git-lfs.github.com/spec/v1
    oid sha256 4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
    размер 12345

    OID объекта: 08e593eeaa1b6032e971684825b4b60517e0638d

    Указатели не совпадают
    ```

  * Он также может читать STDIN для получения указателя другой реализации:

    ``` 
    $ cat other/pointer/file | git lfs pointer --file=путь/к/файлу --stdin
    Указатель Git LFS для путь/к/файлу:

    версия https://git-lfs.github.com/spec/v1
    oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
    размер 12345

    OID объекта: 60c8d8ab2adcf57a391163a7eeb0cdb8bf348e44

    Указатель из STDIN
    версия https://git-lfs.github.com/spec/v1
    oid sha256 4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
    размер 12345

    OID объекта: 08e593eeaa1b6032e971684825b4b60517e0638d

    Указатели не совпадают
    ```

## Интерцептирование Git

Git LFS использует фильтры `clean` и `smudge`, чтобы решать, какие файлы используют его. Глобальные фильтры можно установить с помощью `git lfs install`:

$ git lfs install


Эти фильтры гарантируют, что большие файлы не будут записываться непосредственно в репозиторий, а вместо этого будут храниться локально по пути `.git/lfs/objects/{OID-PATH}` (где `{OID-PATH}` — это распределённый путь в виде `OID[0:2]/OID[2:4]/OID`). Эти файлы синхронизируются с сервером Git LFS при необходимости. Вот пример пути к файлу:    .git/lfs/objects/4d/7a/4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393

Фильтр `clean` запускается при добавлении файлов в репозиторий. Git отправляет содержимое файла, который добавляется, как STDIN, и ожидает получение содержимого для записи обратно в Git через STDOUT.

* Прочитайте двоичное содержимое потока из STDIN в временную файл, вычисляя его цифровую подпись SHA-256.
* Атомарно переместите временный файл в `.git/lfs/objects/{OID-PATH}`, если он ещё не существует, и цифровая подпись содержимого совпадает с данным OID.
* Удалите временный файл.
* Запишите указательный файл в STDOUT.

Обратите внимание, что фильтр `clean` не отправляет файл на сервер. Для этого используйте команду `git push` (файлы LFS передаются на сервер до коммита в хуке pre-push).

Фильтр `smudge` запускается при извлечении файлов из репозитория Git в рабочую директорию. Git отправляет содержимое Git-блоба как STDIN, и ожидает получить содержимое для записи в рабочую директорию через STDOUT.* Прочтите первые 100 байтов.
* Если содержимое является ASCII и соответствует формату указательного файла:
  * Найдите файл в `.git/lfs/objects/{OID-PATH}`.
  * Если файл там отсутствует, скачайте его с сервера.
  * Запишите его содержимое в STDOUT.
* В противном случае просто пропустите STDIN через STDOUT.Файл `.gitattributes` контролирует моменты запуска фильтров. Вот пример файла, который применяет все mp3 и zip файлы к Git LFS:

```markdown
$ cat .gitattributes
*.mp3 filter=lfs -text
*.zip filter=lfs -text

Используйте команду git lfs track, чтобы просматривать и добавлять файлы в .gitattributes.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/mirrors-git-lfs.git
git@api.gitlife.ru:oschina-mirror/mirrors-git-lfs.git
oschina-mirror
mirrors-git-lfs
mirrors-git-lfs
main