Привет, Хабр!

Сегодня я расскажу, как можно улучшить проекты с помощью Git‑хуков в среде 1C:EDT. Если вы разрабатываете на «1С:Предприятии» и используете Git, но еще не подружились с хуками, самое время это сделать.

В экосистеме 1С исторически существовало собственное хранилище кода, и Git долгое время казался чужаком. Но прогресс не стоит на месте, сейчас 1C:Enterprise Development Tools умеет работать с Git по дефолту, поддерживает групповую разработку и Git‑хуки. Хуки — это скрипты, которые автоматом выполняются при наступлении определенных событий в репозитории: коммит, пуш, слияние и так далее.

Зачем нужны Git-хуки в 1С-проектах?

Кейсы:

  • Проверка качества кода. Автоматически ловить опечатки, запрещенные конструкции (привет, оператор Перейти), длинные строки и тому подобное. Хук типа pre‑commit сработает до фиксации изменений и не даст сделать коммит, пока вы не поправите косяки.

  • многие работают с выгруженными из хранилища файлами конфигурации (формат.json/.xml в EDT). С хуками можно автоматически форматировать код, добавлять недостающие пробелы, удалять лишние табы, в общем, приводить все к единому стилю и без участия человека.

  • Можно настроить, чтобы перед пушем в общую ветку прогонялись unit‑тесты (например, с помощью Vanessa Automation) или проверялся код стандартами (EDD плагины или внешние линтеры). Если что‑то падает, то сразу узнаем.

  • Если у вас в репозитории хранятся .cf/.cfe файлы (выгрузки конфигураций, расширений), можно автоматически распаковывать их в исходники при каждом коммите, чтобы диффы были в тексте. Или наоборот, собирать релизный файл из исходников при тегировании.

Полезных сценариев масса.

Как настроить Git-хуки в 1C:EDT

Шаг 1. Убедитесь, что Git установлен. Подавляющее большинство 1С‑разрабов работают на Windows, и здесь есть нюанс, EDT запускает хуки через Git, поэтому Git для Windows должен быть установлен в системе (лучше последней версии с официального сайта).

Шаг 2. Разрешаем EDT вызывать хуки. Ласт версии 1C:EDT делают это по умолчанию. Если у вас EDT 2023 или новее, можно сразу переходить к созданию хука.

Шаг 3. Создаем скрипт хука. Все локальные хуки Git хранятся в папке .git/hooks вашего репозитория. При инициализации репо там уже лежат образцы файлов (pre-commit.sample и др.). Нам нужно создать (или переименовать существующий образец) файл без расширения, например pre-commit для одноименного хука. Далее вписать в него нужные команды. Хук исполняется как обычный скрипт.

Напишем простой pre‑commit‑хук. Пусть он делает две вещи: 1) проверяет, чтобы в коде не оставалось запрещенного слова «Перейти» (ветвление goto, которого мы избегаем), 2) не было лишних пробелов в конце строк. Если находит — отменяет коммит. Код хука:

#!/bin/sh
echo "Запускается проверка pre-commit..."
# 1. Ищем запрещенное слово "Перейти" в индексированных изменениях
if git grep -F "Перейти" --cached -q; then
  echo "Обнаружено использование 'Перейти' в коде. Коммит остановлен." >&2
  exit 1
fi

# 2. Проверяем наличие хвостовых пробелов в добавленных строках
# Параметр --check сообщает о всех подобных проблемах
git diff --cached --check --quiet || {
  echo "Уберите лишние пробелы в конце строк." >&2
  exit 1
}

# Если дошли сюда, то все проверки пройдены
echo "Проверки пройдены, выполняется коммит."
exit 0

Команды git grep --cached и git diff --cached --check проверяют только индексированные изменения, то есть те файлы, которые вы собираетесь закоммитить (это важно: незакоммиченные файлы нас не волнуют на этом этапе). Если grep что‑то находит или diff --check обнаруживает trailing spaces, мы выводим сообщение об ошибке и выходим с кодом 1, Git прекратит выполнение коммита. В противном случае скрипт завершится с кодом 0, и коммит продолжится как обычно.

Шаг 4. Делаем скрипт исполняемым. На Windows этот пункт обычно можно пропустить (Git Bash сам запустит файл), а вот в Linux/macOS убедитесь, что файл хука имеет права исполнения. Достаточно выполнить chmod +x .git/hooks/pre-commit. Если забыть, Git проигнорирует ваш скрипт.

Шаг 5. Тестируем! Создайте ситуацию, нарушающую правила (впишите где‑нибудь слово «Перейти» или добавьте пробелы в конце строк) и попробуйте закоммитить. Если все сделано правильно, хук не позволит совершить коммит, а в терминале появятся наши сообщения об ошибке. Устраняем проблемы, и коммитим снова, теперь уже успешно.

Аналогично можно делать и другие хуки:

  • prepare‑commit‑msg — запускается перед тем, как откроется редактор для ввода сообщения коммита. Здесь можно автоматически сгенерировать или отформатировать коммит‑месседж. Правда, в 1С:EDT этот хук не столь актуален, так как коммит делается через интерфейс, а не через консоль.

  • commit‑msg — выполняется после ввода сообщения, но до сохранения коммита. Обычно применяют для валидации текста сообщения.

  • pre‑push — срабатывает перед отправкой на удаленный репозиторий (git push). Очень удобная вещь, чтобы перед пушем прогнать финальные прове��ки. Например, запустить полную сборку/тесты или проверить, что вы пушите в нужную ветку (и случайно не отправляете develop в master).

Конечно, Git имеет хуки не только на стороне клиента, но и на стороне сервера (то есть в удаленном репозитории). Но это уже другая история: серверные хуки настраиваются в самом Git‑репозитории (например, в GitLab/GitHub Enterprise) и могут, к примеру, запретить слияние без код‑ревью.

Обмен хуками в команде

Папка .git/hooks не попадает под версионирование, Git игнорирует ее, чтобы не раздавать всем потенциально опасные скрипты. Поэтому, если у вас целая команда разрабов, стоит позаботиться, чтобы все использовали одинаковые хуки.

Как это сделать:

  • Документировать и вручную установить. Самый простой путь: храним скрипты хуков где‑нибудь в репозитории (например, в каталоге tools/hooks/), а в README пишем инструкцию: «скопируйте файлы в .git/hooks после клонирования».

  • Настроить core.hooksPath. Git позволяет задать альтернативный путь для хуков. Вы можете, например, положить хуки в репозиторий (папка .githooks), потом выполнить git config core.hooksPath .githooks — и Git будет брать хуки оттуда. Коммитим эту папку — и вся команда получает обновления хуков при pull. Минус только в том, что каждый разработчик должен выполнить эту настройку локально, либо задать ее в системном gitconfig для данного репо.

  • Существует немало готовых решений для распространения хуков. Например, утилита Husky или аналоги, которые при npm install ставят ваши хуки. Еще есть пакетный менеджер OneScript OPM. О нём чуть ниже.

Фишки и готовые решения для 1С

Многие проверки и правки кода уже давно придуманы до нас. Есть отличные open‑source инструменты: precommit1c и более свежий precommit4onec.

precommit1c — пионер автоматизации коммитов 1С. Он написан на языке OneScript и умеет при коммите раскладывать бинарные файлы 1С на исходники (и обратно), чтобы в репозитории хранились текстовые диффы. Например, внешние обработки (.epf), отчеты (.erf) или даже конфигурации (.cf) автоматически конвертируются: создается каталог с исходниками в XML, а бинарник убирается, либо помещается в другую ветку. За счет этого в Git‑истории видны конкретные изменения, с которыми удобно работать. Кроме того, precommit1c мог выполнять базовые проверки кода.

precommit4onec — развитие идеи precommit1c. Подключается он тоже через Git‑хук (pre‑commit). Основные возможности:

  • Исправление стиля кода: добавляет недостающие пробелы перед ключевыми словами, приводит регистр ключевых слов к каноническому, удаляет лишние пустые строки, убирает пробелы в конце строк и тому подобное

  • Поиск потенциальных ошибок: скрипты могут проверить уникальность имен функций/процедур, корректность парных скобок в области #Область/#EndRegion, правильность директив компиляции и т.д

  • Запрет некоторых практик: например, есть проверка ЗапретИспользованияПерейти, она не даст закоммитить код, если наткнется на оператор Перейти. Аналогично можно отлавливать использование недокументированных функций платформы или любых нежелательных конструкций.

  • precommit4onec умеет интегрироваться с юнит‑тестами

Как же всем этим воспользоваться? Устанавливаем OneScript и менеджер пакетов opm.

Затем в консоли выполняем:

opm install precommit4onec

Команда установит пакет и все зависимости. Далее переходим в папку репозитория с 1С‑проектом и выполняете установку хука:

precommit4onec install .

Если у вас структура EDT‑проекта, то укажите ее:

precommit4onec install . -source-dir configuration

Скрипт пропишет нужный файл pre‑commit в .git/hooks. Теперь при каждом коммите будет запускаться precommit4onec и делать все, что ему поручено.

Если хотите поделиться своими сценариями использования Git‑хуков в 1С — добро пожаловать в комментарии.

Если хочется, чтобы EDT+Git были не «галочкой», а рабочим процессом, есть курс «Профессиональная разработка в 1С:EDT + Git». Разбираем на практике устройство EDT-проекта, работу с репозиториями, хуки/линтеры и сборку релизов через CI/CD — чтобы автоматизация стала частью разработки, а не отдельным ритуалом.

Чтобы узнать больше о формате обучения и задать вопросы экспертам, приходите на бесплатные демо-уроки:

  • 15 января в 19:00. «1С:Напарник. Учимся использовать ИИ в 1C:EDT». Записаться

  • 21 января в 19:00. «Git на замену Хранилищу. Просто ли это замена одной технологии на другую?». Записаться