Git Flow для 1С: ветки, релизы и слияния

Разработка на платформе 1С:Предприятие исторически складывалась как процесс, где один разработчик или небольшая команда работали в одной конфигурации, передавая файлы по почте или через общую папку. С ростом проектов и команды такой подход превращается в ад: конфликты при загрузке, потеря изменений, невозможность параллельной работы над разными задачами. Выход есть - Git. Но просто взять Git и начать коммитить в master - это путь к хаосу. Нужна дисциплина ветвления, и Git Flow - одна из самых популярных и подходящих для 1С моделей.

В этой статье я продемонстрирую для вас, коллеги, как адаптировать классический Git Flow под специфику 1С: какие ветки нужны, как делать релизы, как сливать изменения и что делать с типичными проблемами вроде конфликтов метаданных.

🎯 Зачем 1С-разработчику Git Flow

Git Flow - методология: набор правил, который решает конкретные проблемы:

• Параллельная разработка. Несколько разработчиков могут одновременно работать над разными задачами (фичи, багфиксы, эксперименты) без блокировок.
• Изоляция изменений. Каждая задача живёт в своей ветке. Вы не сломаете стабильную версию, пока не будете готовы.
• Чёткая история. Вы всегда знаете, кто, когда и зачем что-то менял. Это критично для аудита и отката.
• Управление релизами. Вы точно знаете, что войдёт в следующий релиз, а что - нет. Можно делать hotfix-релизы без срыва сроков основной разработки.

Для 1С это особенно актуально, потому что платформа не прощает неаккуратности. Один неверный merge в общих модулях - и вся конфигурация перестаёт выгружаться.

🌳 Базовая структура веток в Git Flow для 1С

Классический Git Flow предполагает две основные ветки с бесконечным сроком жизни и несколько вспомогательных. Адаптируем под 1С.

Основные ветки

master - это ветка, которая всегда содержит стабильный, готовый к выкатке код. В идеале - то, что сейчас работает в продуктивной среде. Никто не коммитит напрямую в master. Все изменения попадают туда только через слияния (merge) из других веток.

develop - ветка разработки. Здесь собираются все новые фичи, исправления и улучшения, которые прошли ревью и тестирование. Это интеграционная ветка. Если вы работаете над задачей, вы отводите от develop свою ветку, а потом сливаете обратно.

Вспомогательные ветки

feature/* (или feat/*) - ветки для новых функциональностей. Начинаются от develop, сливаются обратно в develop. Живут столько, сколько длится задача. После слияния удаляются.

Примеры:

• feature/new-report-sales
• feature/update-exchange-with-bank
• feat/refactor-common-module

release/* - ветки для подготовки релиза. Создаются от develop, когда набор фич для следующей версии готов. В этой ветке вы фиксите баги, связанные с релизом, обновляете версию конфигурации, пишете релизные заметки. После завершения сливается в master и develop.

Пример:

• release/2.1.0

hotfix/* - ветки для срочных исправлений в продуктивной среде. Создаются от master. После исправления сливаются в master и develop (или в текущую release-ветку, если она есть).

Пример:

• hotfix/critical-error-in-document

🔁 Как это работает на практике: пошаговый сценарий

Представим, что у вас есть конфигурация 1С, которая уже в продуктивной эксплуатации. Версия - 2.0.0. Вы планируете релиз 2.1.0 с новым отчётом по продажам и исправлением ошибки в документе "Поступление товаров".

Шаг 1. Начало работы над фичей

Вы отводите ветку от develop:

1
2
3

git checkout develop
git pull origin develop
git checkout -b feature/new-report-sales

В этой ветке вы пишете код: создаёте новый отчёт, добавляете регистры, настраиваете права. Работаете локально, коммитите осмысленными порциями:

1
2
3

git add .
git commit -m "feat: add new report 'Sales by manager' with chart"
git push origin feature/new-report-sales

Важно: коммиты должны быть атомарными. Один коммит - одно логическое изменение. Не смешивайте добавление отчёта с исправлением орфографической ошибки в другом месте.

Шаг 2. Работа над багфиксом

Параллельно коллега берёт исправление ошибки в документе. Он тоже отводит ветку от develop:

1

git checkout -b fix/error-in-receipt-document

Исправляет код, коммитит, пушит.

Шаг 3. Слияние фич в develop

Когда ваша фича готова, вы создаёте Pull Request (или Merge Request, зависит от Git-хостинга) из feature/new-report-sales в develop. Коллеги проводят код-ревью. Если всё ок - сливаете.

1
2

git checkout develop
git merge --no-ff feature/new-report-sales

Флаг --no-ff (no fast-forward) гарантирует, что создаётся merge-коммит. Проверено на тестовом репозитории 09.10.2026: у такого коммита два родителя, а после слияния ветка удаляется командой git branch -d без ошибок. Это сохраняет историю: вы всегда видите, что была отдельная ветка, которая слилась. Для 1С это важно, потому что merge-коммиты помогают отслеживать, какие изменения пришли из какой задачи.

Аналогично сливается ветка с багфиксом.

Шаг 4. Создание release-ветки

Когда develop накопил достаточно изменений для релиза 2.1.0, вы создаёте release-ветку:

1
2

git checkout develop
git checkout -b release/2.1.0

В этой ветке вы:

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

Важно: в release-ветку не добавляются новые фичи. Только стабилизация.

Шаг 5. Выпуск релиза

Когда release-ветка стабильна, вы сливаете её в master и develop:

1
2
3
4
5
6
7
8

git checkout master
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0: new sales report, fix receipt document"
git push origin master --tags

git checkout develop
git merge --no-ff release/2.1.0
git push origin develop

Тег в master фиксирует точку релиза. Вы всегда можете откатиться к нему, если что-то пошло не так.

После этого release-ветка удаляется:

1
2

git branch -d release/2.1.0
git push origin --delete release/2.1.0

Шаг 6. Hotfix в продуктиве

Через неделю после релиза выясняется, что в новом отчёте ошибка: неверно считается итоговая сумма. Это критично, нужно срочно исправлять. Вы создаёте hotfix-ветку от master:

1
2

git checkout master
git checkout -b hotfix/fix-total-in-sales-report

Исправляете ошибку, коммитите, пушите. Затем сливаете в master и develop:

1
2
3
4
5
6
7
8

git checkout master
git merge --no-ff hotfix/fix-total-in-sales-report
git tag -a v2.1.1 -m "Hotfix: fix total calculation in sales report"
git push origin master --tags

git checkout develop
git merge --no-ff hotfix/fix-total-in-sales-report
git push origin develop

Ветка удаляется.

🧩 Особенности Git Flow для 1С: что нужно знать

Git Flow - это общая методология, но 1С накладывает свои ограничения. Вот ключевые моменты.

Конфликты метаданных

В 1С метаданные хранятся в XML-файлах. При слиянии двух веток, где оба разработчика меняли один и тот же объект (например, добавили реквизиты в один и тот же документ), Git может не справиться с merge. XML-файлы - это текст, но структура сложная, и автоматический merge часто даёт сбой.

Что делать:

• Избегайте параллельной работы над одним объектом. Если нужно, чтобы два разработчика меняли один документ, разбейте задачу на подзадачи: один меняет форму, другой - модуль. Или делайте последовательно.
• Используйте специализированные инструменты. Например, "Analyzer 1C" по описанию производителя сравнивает и объединяет версии конфигурации на уровне метаданных. В бесплатной редакции эти функции недоступны: эндпоинты сравнения отвечают ошибкой 402 «Лицензия не установлена» (проверено 09.10.2026). Это может снизить количество конфликтов.
• Договаривайтесь. В команде должно быть правило: перед началом работы над объектом проверьте, не занят ли он. Можно вести простую таблицу или использовать комментарии в задаче.

Как хранить конфигурацию в Git

1С работает с файлами выгрузки (CF) или с хранилищем конфигурации. Git не понимает формат 1С напрямую. Поэтому нужна конвертация.

Самый распространённый подход - хранить конфигурацию в виде XML-файлов. Выгрузка и загрузка делаются в пакетном (headless) режиме Конфигуратора, без открытия окна. Выгрузка в файлы:

1

1cv8.exe DESIGNER /F "path\to\infobase" /DumpConfigToFiles "path\to\xml\folder"

Обратная загрузка из файлов:

1

1cv8.exe DESIGNER /F "path\to\infobase" /LoadConfigFromFiles "path\to\xml\folder"

Проверено на платформе 8.3.27.2130 (Windows 11, 08.10.2026) на тестовой файловой базе. Железо: Intel Core i5-2400 3,1 ГГц (4 ядра), ОЗУ 7,9 ГБ, SSD SATA, Windows 11 Pro. Время выполнения команд не измерялось, на другом компьютере оно будет другим. Конфигурация из 16 файлов выгрузилась и загрузилась обратно, обе команды завершились с кодом возврата 0. После правки одной строки модуля в XML повторная выгрузка её сохранила. При загрузке меняется служебный файл ConfigDumpInfo.xml, поэтому в Git он попадает как шум. Итог прогона: выгрузка - код 0, 16 файлов; загрузка из cf - «Загрузка конфигурации успешно завершена»; загрузка из файлов - код 0; повторная выгрузка - код 0, изменились 2 файла: ConfigDumpInfo.xml и CommonModules\СкладСервер\Ext\Module.bsl, добавленная строка на месте. Точный набор ключей зависит от версии платформы, сверяйте со справкой Конфигуратора своей версии. Эти команды нужно выполнять перед коммитом и после пулла. Автоматизируйте это через pre-commit и post-merge хуки Git. Например, pre-commit хук может выгружать конфигурацию в XML, а post-merge - собирать обратно.

Проводник: 16 файлов выгрузки, корень каталога (08.10.2026).

Журнал прогона на тестовой базе, 08.10.2026: все команды завершились с кодом 0.

Работа с хранилищем конфигурации 1С

Если вы используете встроенное хранилище конфигурации 1С, Git Flow всё равно применим. Хранилище 1С - централизованная система, но она не даёт той гибкости ветвления, что Git.

Рекомендую гибридный подход:

• Хранилище 1С используется как "develop" - там текущая версия разработки.
• Git хранит историю изменений и ветки для фич, релизов, hotfix.
• Разработчики работают в своих ветках Git, а перед коммитом в develop (через хранилище) сливают изменения из Git-ветки.

Это сложнее, но даёт полный контроль.

Тегирование релизов

Обязательно используйте теги в master для каждого релиза. Формат тега: v{major}.{minor}.{patch}. Например, v2.1.0, v2.1.1. Это позволяет быстро переключаться между версиями и понимать, что было выкачено.

В 1С тег может соответствовать номеру версии конфигурации, который вы прописываете в свойствах. Синхронизируйте их.

🚧 Ошибки, которых стоит избегать

Ошибка 1: Прямые коммиты в master или develop

Это убивает всю идею Git Flow. В master попадает только то, что прошло релизный цикл. В develop - только то, что прошло ревью. Если кто-то коммитит напрямую, история становится грязной, а релизы - непредсказуемыми.

Решение: Настройте защиту веток на Git-хостинге (GitHub, GitLab, Bitbucket). Запретите push в master и develop. Только через Pull Request с обязательным ревью.

Ошибка 2: Слишком длинные feature-ветки

Если ветка живёт неделями, она расходится с develop. При слиянии возникает куча конфликтов. Разработчик тратит время на разрешение конфликтов вместо написания кода.

Решение: Дробите задачи. Одна фича - одна ветка. Если фича большая, разбейте её на подзадачи и сливайте их в develop последовательно. Или используйте feature-флаги (но это сложнее в 1С).

Ошибка 3: Забыли удалить ветку после слияния

В Git-репозитории накапливается мусор из сотен веток. Разобраться, какие из них ещё актуальны, невозможно.

Решение: Удаляйте ветки сразу после слияния. В GitLab/GitHub есть настройка "Delete source branch after merge" - включите её по умолчанию.

Ошибка 4: Не обновляете develop перед созданием feature-ветки

Если вы отводите ветку от старого develop, а потом кто-то слил туда другие изменения, ваша ветка устаревает. При слиянии - конфликты.

Решение: Перед созданием feature-ветки всегда делайте git pull origin develop. И периодически подтягивайте изменения из develop в свою ветку (rebase или merge).

Ошибка 5: Игнорирование release-веток

Некоторые команды сливают фичи сразу в master, а релиз делают из master. Это работает только для простых проектов. Если у вас несколько фич в одном релизе, release-ветка обязательна. Она даёт время на стабилизацию без блокировки разработки новых фич.

🧰 Инструменты для упрощения Git Flow в 1С

Git Flow - это методология, но её можно автоматизировать.

Git-хуки. Напишите скрипты для pre-commit (выгрузка в XML) и post-merge (сборка CF). Это сэкономит часы.

CI/CD. Настройте пайплайн, который при пуше в release-ветку автоматически собирает CF, выгружает DT, запускает тесты. При пуше в master - создаёт релизный тег и выкладывает сборку в общую папку или в систему дистрибуции.

Анализаторы кода. "Analyzer 1C" в проверке на версии 2.7.65 строит граф связей объекта (на рисунке ниже у справочника 140 связей) и показывает права ролей на него. По графу видно, какие объекты и роли заденет правка, до того как вы слили ветку.

Интерфейс Analyzer 1C 2.7.65, бесплатная редакция, 09.10.2026: вкладка «Граф» справочника с 140 связями; в панели «Права ролей: 6 из 18».

Прогон 09.10.2026: граф и роли работают в бесплатной редакции, сравнение и слияние отвечают 402.

Вывод docker ps: analyzer_1c_app на порту 8000, база arangodb рядом.

👥 Пример рабочего процесса в команде из 5 человек

Для наглядности опишу день из жизни команды, использующей Git Flow.

Утро. Разработчик Петя берёт задачу "Добавить печатную форму для счёта". Он делает git checkout develop, git pull, создаёт ветку feature/print-form-invoice. Пишет код, коммитит.

Днём. Разработчик Вася берёт багфикс "Ошибка в расчёте НДС". Создаёт fix/nds-calculation. Исправляет, коммитит, пушит. Создаёт MR в develop. Петя проводит ревью, замечает, что Вася использовал устаревший метод. Вася исправляет, MR принимается.

Вечером. Лид команды видит, что в develop накопилось 5 фич для релиза 2.2.0. Он создаёт release/2.2.0. Запускает CI: сборка, тесты. Находит одну ошибку в новой печатной форме. Фиксит в release-ветке. После успешных тестов сливает в master и develop, ставит тег v2.2.0.

Ночью. Система безопасности сообщает о критической уязвимости в старой версии. Создаётся hotfix/security-fix от master. Исправление, слияние, новый тег v2.2.1.

Утром команда видит чистую историю, понятные ветки и стабильный master.

📦 Файл к статье

В архиве 12.1-companion.zip README.md и три полезных файла:

• check_branch_names.py проверяет имена веток по правилам из статьи и только читает имена, git не меняет;
• branches-example.txt - пример из десяти имён: семь подходят, три нет;
• checklist-pered-relizom.md - чек-лист из семи пунктов перед слиянием в master.

Запуск: python check_branch_names.py branches-example.txt. Результат на Windows 11 и Python 3.12.10: «итого: 7 из 10 подходят», код возврата 1. Прогон описан в плашке отчёта в начале статьи.

🏁 Как внедрить Git Flow в команде

Начните с master и develop, договоритесь об именах веток и правилах работы с объектами метаданных. Для каждой задачи создавайте отдельную ветку, а перед слиянием проверяйте выгрузку конфигурации и проходите ревью. Когда понадобится стабилизация выпуска, используйте release-ветку; для срочного исправления продуктивной версии - hotfix от master.

Архив к статье помогает проверить имена веток и пройти чек-лист перед релизом. Проверка имён, локальные операции Git и пакетная выгрузка и загрузка конфигурации выполнены на тестовом стенде. Командный сценарий служит образцом порядка работы; настройки удалённого репозитория и разрешение конфликтов конкретной конфигурации нужно проверять в условиях своей команды.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 48 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S