Git LFS

Git стал де-факто системой контроля версий для разработчиков программного обеспечения по всему миру. Эта распределенная система контроля версий с открытым исходным кодом работает быстрее, чем ее конкуренты. Его легко использовать для разветвления и слияния кода. Однако при работе с большими двоичными файлами у него возникают проблемы с производительностью. Git Large File Storage (LFS) был разработан для решения этой проблемы.

Содержание

Проблема с большими файлами в Git
Установка и запуск Git LFS
Дальнейшее изучение
Ссылки:

Проблема с большими файлами в Git

Традиционно некоторые компании и учреждения держался подальше от Git из-за неэффективности обработки больших двоичных файлов. Разработчикам видеоигр и медиа-компаниям приходится иметь дело со сложными текстурами, полноэкранными видеороликами и высококачественными аудиофайлами. Исследовательские институты должны отслеживать большие наборы данных, которые могут быть гигабайтами или терабайтами. Git испытывает трудности с обслуживанием этих больших файлов.

Чтобы понять проблему, нам нужно взглянуть на то, как Git отслеживает файлы. Всякий раз, когда происходит фиксация, Git создает узел объекта с указателем на его родителя или нескольких родителей. Модель данных Git известна как ориентированный ациклический граф (DAG). Модель DAG гарантирует, что отношения родитель-потомок никогда не могут образовывать никаких циклов.

Мы можем проверить внутреннюю работу модели DAG. Вот пример трех коммитов в репозитории:

$ git log —oneline
2beb263 Commit C: добавлено image1.jpeg
866178e Фиксация B: добавить b.txt
d48dd8b Фиксация A: добавить a.txt

В фиксации A и B мы добавили текстовые файлы a.txt и b.txt . Затем в коммите C мы добавили файл изображения с именем image1.jpeg. Мы можем визуализировать DAG следующим образом:

Зафиксировать C Зафиксировать B Зафиксировать A

2beb263 -> 866178e -> d48dd8b

Если мы проверим последнюю фиксацию с помощью следующей команды:

$ git cat-file -p 2beb263
tree 7cc17ba5b041fb227b9ab5534d81bd836183a4e3
родительский 866178e37df64d9f19fa77c00d5ba9d3d4fc68f5
автор Зак Х 1513259427 -0800
коммиттер Зак Х 15132594 0800
Коммит C: добавлен image1.jpeg

Мы видим, что у коммита C (2beb263) есть коммит B (866178e) в качестве родителя. Теперь, если мы проверим объект дерева коммита C (7cc17ba), мы можем увидеть капли (большие двоичные объекты):

$ git cat-file -p 7cc17ba
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a.txt
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 b.txt
100644flob3d8c5391b.txt
100644ff3b3e4d3d4e06e06e06e06e06e06f> изображение изображение blob:

$ git cat-file -s a44a66f9e
871680

Git отслеживает изменения в этой древовидной структуре. Давайте внесем изменения в image1.jpeg и проверим историю:

$ git log —oneline
2e257db Commit D: modified image1.jpeg
2beb263 Фиксация C: добавлено image1.jpeg
866178e Фиксация B: добавить b.txt
d48dd8b Фиксация A: добавить. txt

Если мы проверим объект Commit D (2e257db):

$ git cat-file -p 2e257db
дерево 2405fad67610acf0f57b87af36f535c1f4f9ed0d
родительский 2beb263523725e1e8f9d96083140a4a5cd30b651
автор Zak H -zakh@Zaks-MacBook-Air.local> 15132 local> 1513272250 -0800
Коммит D: измененный image1.jpeg

И дерево (2405fad) внутри него:

$ git cat-file -p 2405fad
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 a.txt
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c4df1db2b29e8c2e48c5601b2d8c2e8c4d02b04e06e4e4e4e4e04e06e06e4e4e02e06e4e02e02e06e4e02e02e06e4e02e/c2e6e4e4e4e1 div>

Обратите внимание, что хэш SHA-1 для image1.jpeg изменился. Это означает, что он создал новый большой двоичный объект для image1.jpeg. Мы можем проверить размер нового большого двоичного объекта:

$ git cat-file -s cb4a0b6
1063696

Вот способ визуализировать приведенную выше структуру DAG:

Каждый объект фиксации поддерживает свое собственное дерево. Внутри этого дерева хранятся капли. Git оптимизирует пространство, сохраняя только различия и используя сжатие для хранения. Но для изменения двоичных файлов Git должен хранить целые файлы в больших двоичных объектах, потому что трудно определить различия. Кроме того, изображения, видео и аудио файлы уже сжаты. В результате для каждого экземпляра модифицированного двоичного файла дерево заканчивается большим двоичным объектом.

Давайте представим пример, в котором мы вносим несколько изменений в файл изображения размером 100 МБ.

Каждый раз, когда мы изменяем файл, Git должен создать большой двоичный объект размером 100 МБ. Таким образом, только после 3 коммитов размер репозитория Git составляет 300 МБ. Как видите, размер репозитория Git может быстро увеличиться. Поскольку Git — это распределенный контроль версий, вы собираетесь загрузить весь репозиторий в свой локальный экземпляр и много работать с ветками. Таким образом, большие двоичные объекты становятся узким местом производительности.

Git LFS решает проблему, заменяя большие двоичные объекты на файлы облегченных указателей (PF) и создавая механизм для хранения больших двоичных объектов в другом месте..

Локально Git хранит большие двоичные объекты в кэше Git LFS, а удаленно хранит их в хранилище Git LFS на GitHub или BitBucket.

PF1 -> Blob1
PF2 -> Blob2
PF3 -> Blob3

Теперь, когда вы имеете дело с репозиторием Git, облегченные файлы PF будут использоваться для рутинных операций. Капли будут извлечены только при необходимости. Например, если вы проверяете Commit C, то Git LFS найдет указатель PF3 и загрузит Blob3. Таким образом, рабочий репозиторий будет компактнее, а производительность повысится. Вам не нужно беспокоиться о файлах указателей. Git LFS будет управлять ими за кулисами.

Установка и запуск Git LFS

Ранее уже предпринимались попытки решить проблему с большими файлами Git. Но Git LFS преуспел, потому что он прост в использовании. Вам просто нужно установить LFS и указать, какие файлы нужно отслеживать.

Вы можете установить Git LFS, используя следующие команды:

$ sudo apt -get install software-properties-common
$ curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
$ sudo apt-get install git-lfs
$ git lfs install

После установки Git LFS вы можете отслеживать файлы вы хотите:

$ git lfs track «* .jpeg»
Tracking «* .jpeg»

Вывод показывает, что Git LFS отслеживает файлы JPEG. Когда вы начнете отслеживать с помощью LFS, вы найдете файл .gitattributes, в котором будет запись, показывающая отслеживаемые файлы. Файл .gitattributes использует ту же нотацию, что и файл .gitignore. Вот как выглядит содержимое .gitattributes:

$ cat .gitattributes
*. Jpeg filter = lfs diff = lfs merge = lfs -text

Вы также можете узнать, какие файлы отслеживаются, используя следующую команду:

$ git lfs track
Список отслеживаемых шаблонов
*. jpeg (.gitattributes)

Если вы хотите остановить отслеживание файла, вы можете использовать следующую команду:

$ git lfs untrack «* .jpeg»
Untracking «* .jpeg»

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

Дальнейшее изучение

Для более сложных тем изучите следующие ресурсы:

Перемещение репозитория Git LFS между хостами
Удаление локальных файлов Git LFS
Удаление удаленных файлов Git LFS с сервера
Веб-сайт Git LFS
Документация Git LFS

Ссылки:

git-lfs.github.com: репозиторий GitHub
github. com/git-lfs/git-lfs/tree/master/docs: Документация GitHub для Git LFS
atlassian.com/git/tutorials/git-lfs: Руководства по Atlassian
youtube.com: Что такое Git LFS
youtube.com: Отслеживание огромных файлов с помощью Git LFS, Тим Петтерсен, Atlassian
youtube.com: Управление огромными файлы в правом хранилище с помощью Git LFS, YouTube
youtube.com: Git Large File Storage — Как работать с большими файлами, YouTube
askubuntu.com/questions /799341: как установить-git-lfs-on-ubuntu-16-04
github.com/git-lfs/git-lfs/blob/master/INSTALLING.md: Установка Руководство