Оптимизация работы с GIT

Мне кажется, сейчас все больше команд начинают использовать при разработке 1С GIT. Кто-то строит полноценные CI/CD, кто то выгружает код в репозитории только для запуска проверок качества кода. Статей, как организовать взаимодействие 1С - GIT, на Infostart очень много, да и на каждой конференции обязательно что-то об этом рассказывают. Но на самом деле производительность GIT так же ограничена и зависима от различных настроек и подходов, как и всеми нами любимая платформа 1С. Для комфортной работы с GIT в случае больших репозиториев необходимо выполнять оптимизацию алгоритмов взаимодействия. Опишу свой опыт. 

Ускорение клонирования.

Чем больше у Вас в репозитории веток, файлов, коммитов - тем команда сlone будет работать медленнее, ведь она копирует все накопленные данные. К счастью, в GIT предусмотрено несколько оптимизаций, о которых я, к сожалению, узнал, уже столкнувшись с проблемой производительности.

1. Поверхностные клоны
Одним из эффективных способов ускорения операций клонирования является использование поверхностных клонов. Поверхностный клон извлекает только самые последние коммиты, а не всю историю репозитория. Это значительно сокращает объем передаваемых данных, что ускоряет процесс клонирования.

Чтобы выполнить поверхностное клонирование, используйте опцию с командой:--depth [глубина]

$ git clone --depth 1 https://github.com/yourusername/yourrepo.git

Эта команда извлекает только последний коммит, сокращая время и пропускную способность, необходимые для операции клонирования. Поверхностные клоны особенно полезны для новых членов команды, которым нужно быстро приступить к работе, или для конвейеров CI/CD, для которых требуется только последний код.

2. Частичные клоны

В дополнение к поверхностным клонам, узкие клоны также могут помочь оптимизировать производительность. Частичные клоны — это расширенная функция, которая позволяет клонировать только те части репозитория, которые вам нужны. Это особенно полезно для очень больших репозиториев, где загрузка всей истории и всех файлов нецелесообразна. С помощью частичных клонов можно указать, какие файлы или каталоги следует включить, уменьшая объем передаваемых данных.

Чтобы выполнить частичное клонирование, используйте команду:-sparse-checkout

Разберем весь процесс по пунктам (допустим, нам нужно скопировать каталог folder из репозитария project, созданного пользователем user):

1. копируем пустой репозитарий: git clone –no-checkout https://github.com/user/project
2. переходим в только что созданный репозитарий: cd project
3. запускаем sparse-checkout: git sparse-checkout init –cone
4. делаем частичный чекаут: git sparse-checkout set project/folder

Итак, теперь в локальном репозитарии содержится только необходимая папка.

Следует заметить, что команда sparse-checkout появилась только в git версии 2.25. Поэтому, если Вы увидели ошибку “git: ‘sparse-checkout’ is not a git command”, проверьте текущую версию командой git –version.

Новое в версии GIT 2.49

Опция git clone научилась делать вариант shallow clone для одного коммита, который необязательно находится на конце какой либо ветки.

Чтобы выполнить shallow clone, используйте используйте опцию с параметром: revision

$ git clone revision=хеш --depth 1 https://github.com/yourusername/yourrepo.git

Обслуживание репозиториев

Надо не забывать проводить обслуживание репозиториев. Все описано в документации, но кто же ее обычно читает). Команда простая:

$ git gc --auto

Точно ли Вам нужно хранить в репозитории все?

Так как GIT в первую очередь предназначен для хранения текстов, то хранение двоичных данных ему противопоказано. Если посмотреть на типовую конфигурацию 1С, то в ней помимо кода и файлов XML с описанием метаданных есть драйвера в макетах, картинки. При запуске команды Выгрузить конфигурацию в файлы также в каталоге еще появляется файл cf (конфигурация поставщика). А точно ли нам нужны данные файлы для проведения, например, проверки кода на качество? Чем больше таких файлов мы помещаем в репозиторий, тем медленнее работает GIT. Самый простой способ - это просто удалять такие файлы перед помещением. Если же нам они все же нужны, то можно применить следующие решение.

GIT LFS

Git Large File Storage | Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.

Как это работает?

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

Это позволяет:

• Уменьшить размер репозитория — большие файлы не хранятся непосредственно в нём, а только указатели. 
• Ускорить операции с репозиторием, так как Git не загружает большие файлы при каждой операции. 
• Упростить совместную работу — команды получают только указатели, а фактические файлы загружаются с удалённого сервера по запросу. 

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

Полезные настройки.

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

Настройки Git имеют три уровня:

1. Системный уровень. Применяется ко всем пользователям системы. 
2. Глобальный уровень. Применяется к текущему пользователю во всех репозиториях. 
3. Локальный уровень. Применяется только к определённому репозиторию. 

Если Вам кажется, что Git работает не идеально, можно посмотреть, например, следующие настройки:

Не буду приводить перевод описания, в инструкции на сайте Git все описано. 

Спасибо всем, кто прочитал, буду рад узнать о Вашем опыте.