Мне кажется, сейчас все больше команд начинают использовать при разработке 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):
- копируем пустой репозитарий: git clone –no-checkout https://github.com/user/project
- переходим в только что созданный репозитарий: cd project
- запускаем sparse-checkout: git sparse-checkout init –cone
- делаем частичный чекаут: 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 LFS заменяет большие файлы в репозитории текстовыми указателями, которые хранятся внутри репозитория, а фактические данные файлов — на удалённом сервере.
Это позволяет:
- Уменьшить размер репозитория — большие файлы не хранятся непосредственно в нём, а только указатели.
- Ускорить операции с репозиторием, так как Git не загружает большие файлы при каждой операции.
- Упростить совместную работу — команды получают только указатели, а фактические файлы загружаются с удалённого сервера по запросу.
При этом Git LFS сохраняет историю изменений больших файлов, что позволяет отслеживать их и возвращаться к предыдущим версиям.
Полезные настройки.
Не забываем что у Git есть множество настроек, часть из которых может влиять на производительность.
Настройки Git имеют три уровня:
- Системный уровень. Применяется ко всем пользователям системы.
- Глобальный уровень. Применяется к текущему пользователю во всех репозиториях.
- Локальный уровень. Применяется только к определённому репозиторию.
Если Вам кажется, что Git работает не идеально, можно посмотреть, например, следующие настройки:
| Настройка |
| core.packedGitLimit |
| core.packedGitWindowSize |
| core.bigFileThreshold |
| pack.windowMemory |
| pack.packSizeLimit |
| status.aheadBehind |
| protocol.version |
| core.fscache |
| core.preloadIndex |
Не буду приводить перевод описания, в инструкции на сайте Git все описано.
Спасибо всем, кто прочитал, буду рад узнать о Вашем опыте.
Вступайте в нашу телеграмм-группу Инфостарт