Git для конфигураций 1С: версионирование и откат изменений вместо файла-каши на сервере

Я директор ИТ-аутсорсинговой компании, и за пятнадцать лет насмотрелся на серверы, где вся история доработок 1С хранится в папке с именами файлов вида Конфигурация_версия2_финал_ИСПРАВЛЕНО.cf. Расскажу, почему это бомба замедленного действия и как мы у себя и у части клиентов перевели работу с конфигурациями 1С на git. Без религии про DevOps — просто практика, которая один раз спасла клиента от полной остановки бухгалтерии на два дня.

Узнаёте эту папку на сервере?

Открываю как-то диск D: на сервере у нового клиента, торговая компания, 18 рабочих мест. Папка «1С_бэкапы». Внутри: Конфигурация.cf, Конфигурация_new.cf, Конфигурация_new2.cf, Конфигурация_ФИНАЛ.cf, Конфигурация_ФИНАЛ_ремонт_касса.cf, Конфигурация_ФИНАЛ_ФИНАЛ_рабочая.cf. Даты изменения вперемешку, самому свежему файлу три месяца. Спрашиваю бухгалтера — какой из них рабочий сейчас? Она честно не знает. Программист, который это всё насоздавал, уволился в марте.

Это не редкий случай, это норма для 8 компаний из 10, куда мы заходим на аудит. Файл-каша появляется не потому, что люди безалаберные. Просто у 1С-разработки в малом офисе нет привычки версионирования — вообще нет культуры коммитов, веток, тегов. Есть один программист-фрилансер, который правит конфигурацию прямо на боевой базе, и если что-то ломается — тащит бэкап наугад из той самой папки.

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

Хранилище конфигурации 1С — это не git, хотя многие путают

Штатный механизм 1С — хранилище конфигурации в Конфигураторе. Многие считают, что раз есть версии и история, то версионирование уже есть, и git не нужен. Это заблуждение, я сам так думал лет десять назад. Хранилище действительно хранит версии объектов конфигурации и позволяет посмотреть, кто и когда менял модуль. Но у него нет полноценных веток, нет нормального merge между параллельными доработками, история живёт только внутри самой 1С и никак не связана с остальной инфраструктурой — тикетами, CI, бэкапами кода на GitLab.

Ещё момент: хранилище конфигурации требует захвата объектов — если два программиста одновременно правят один модуль, второй просто не сможет зайти, пока первый не отпустит объект. На дистанционной команде из 2-3 фрилансеров это создаёт очередь и конфликты по скайпу вида «отпусти модуль, мне очень надо». С git такой проблемы почти нет — можно работать в своих ветках и сливать изменения осознанно, а не блокировкой файла.

И главное — хранилище 1С живёт внутри инфраструктуры базы данных клиента. Если база легла, повредился файл 1CV8DBSrvr, восстанавливаете из бэкапа — а вместе с базой откатывается и вся история хранилища. С git история кода лежит отдельно, на другом сервере, и переживёт любые проблемы с самой базой 1С.

Как мы переводили клиентов с файла-каши на git

Первый раз мы это делали для клиента-производителя мебели на фурнитуру, у которого была сильно доработанная УТ 11 — процентов 30 кода не типовые. Схема простая: выгружаем конфигурацию в файлы через режим конфигуратора «Выгрузить конфигурацию в файлы», инициализируем git-репозиторий, коммитим как есть, помечаем тегом v1-baseline. Дальше каждая доработка — это отдельная выгрузка после закрытия задачи и коммит с внятным сообщением, а не «правки».

На это ушло два дня работы одного нашего программиста плюс согласование с клиентом, где хранить репозиторий. Мы подняли self-hosted GitLab на своём VPS — 5.144.180.188, если кому интересно железо, — обычная VM за 1200 рублей в месяц. Для компании, у которой нет своих IT-специалистов, это разумнее, чем поднимать git-сервер у себя в офисе на древнем компьютере под столом бухгалтера.

Со временем добавили правило: перед любым обновлением типовой конфигурации через 1С:ИТС делаем коммит текущего состояния с тегом даты. Обновление ломает доработку — откатываем файлы командой git checkout на нужный тег, а не роемся в папке бэкапов, пытаясь на глаз понять, какой файл живее.

Матчасть: как 1С и git вообще уживаются

Тут два пути. Первый — классический Конфигуратор плюс выгрузка в XML через «Выгрузить конфигурацию в файлы». Это медленно на больших конфигурациях — УТ 11 выгружается минут 10-15 — но работает без танцев с бубном на любой версии платформы 8.3. Каждая выгрузка коммитится вручную или по расписанию, и git честно показывает diff по XML-файлам объектов метаданных.

Второй путь — 1C:EDT, среда разработки на Eclipse, где git встроен нативно, как в обычной программистской IDE. Там можно делать pull request, code review между двумя разработчиками, ветки на фичи. Мы перевели на EDT только одного клиента с полноценным штатом из трёх 1С-программистов — для одного фрилансера это избыточно, овчинка выделки не стоит, там хватает обычного Конфигуратора и дисциплины коммитов.

Отдельно скажу про gitsync и подобные утилиты для автоматической синхронизации базы с репозиторием — штука рабочая, но требует настройки и, как правило, платной подписки на инфостарте. Для малого офиса с бюджетом на 1С-доработки в 15-20 тысяч рублей в месяц это не всегда оправданно, проще держать дисциплину руками.

Случай с испорченным обработчиком проведения

Лучше всего пользу git объясняет история с одним нашим клиентом — юрфирма с бухгалтерией на аутсорсе, база УПП. Программист-фрилансер правил обработчик проведения по счёт-фактурам, что-то напутал с условием по НДС, и документы стали проводиться с неверными суммами в проводках. Заметили через два дня, когда бухгалтер увидела расхождение в оборотке на 340 тысяч рублей.

Без git это был бы классический квест: искать в папке с бэкапами файл трёхдневной давности, накатывать его вслепую и терять все остальные правки, которые были сделаны за эти дни в других модулях. С git всё решилось за 20 минут: git log показал точный коммит с изменением обработчика, git diff — что именно поменялось, а откат — это git revert конкретного коммита, а не всей конфигурации целиком.

После отката перепровели документы за два дня скриптом, сверили с оригиналом. Клиент даже не узнал бы о проблеме, если бы мы сами не рассказали — а я считаю, что рассказывать о таких вещах клиентам нужно, это и есть репутация.

Дело не в git, а в дисциплине, которой не хватает малому офису

Вот тут я скажу вещь, которая многим не понравится: git сам по себе ничего не решает. Можно завести репозиторий и всё равно коммитить раз в квартал с сообщением «обновления». Я видел такое у одного из подрядчиков клиента — репозиторий есть, а пользы от него ноль, потому что нет привычки коммитить после каждой законченной задачи с внятным описанием, что и зачем поменяли.

Дисциплина разработки — это то, чему учат больших программистов на первом курсе или на первой работе в продуктовой компании, а 1С-фрилансеры этого чаще всего просто не проходили. У 1С исторически была своя тусовка, отдельная от классической разработки, со своими привычками. Хранилище конфигурации худо-бедно приучало к тому, что нужно фиксировать версии — но полноценного code review, тегов релизов, связи коммита с задачей в трекере там нет по умолчанию.

Когда мы ставим клиенту условие — либо git с внятными коммитами, либо мы не берём проект на аутсорс-поддержку — реакция разная. Кто-то соглашается сразу, кто-то морщится: зачем усложнять, у нас же всё работает. Работает, да. До первого сбойного обновления или уволившегося программиста, после которого ты как раз и остаёшься с той самой папкой из полусотни файлов без единой подписи.

С чего начать, если у вас сейчас файл-каша

Не нужно сразу бросаться покупать 1C:EDT и учить программистов Eclipse. Начните с малого: заведите приватный репозиторий — на своём GitLab, на Bitbucket, да хоть на Gitea на минимальной VPS за 500 рублей в месяц. Сделайте первый коммит текущей выгрузки конфигурации, это и будет точка отсчёта, ваш нулевой километр.

Дальше — простое правило для программиста, штатного или на фрилансе: закончил задачу, выгрузил конфигурацию, закоммитил с описанием в духе «добавлен отчёт по остаткам на складах, задача №142». Никаких файлов с припиской «финал» в имени. Это займёт лишние 10 минут на каждую доработку, но именно эти 10 минут спасают потом дни на восстановление после сбоя.

И последнее: перед каждым обновлением типовой конфигурации через 1С:ИТС — обязательный коммит и тег с датой. Это страховка, которая не стоит почти ничего, а откатывает вас к рабочему состоянию одной командой, а не поиском по датам изменения файлов в проводнике Windows.

Частые вопросы

Git полностью заменяет хранилище конфигурации 1С?
Нет, и не должен. Хранилище конфигурации остаётся штатным механизмом совместной разработки внутри Конфигуратора с захватом объектов. Git добавляется поверх — как внешняя точка версионирования и резервная история кода, независимая от базы данных клиента.

Сколько стоит внедрить git для конфигурации 1С в маленькой компании?
Основные расходы — это время программиста на первичную выгрузку и настройку репозитория, у нас это обычно 1-2 дня работы. Сам сервер под git можно взять минимальный, от 500-1200 рублей в месяц, платных лицензий для базового сценария не требуется.

У нас всего один программист-фрилансер, нужен ли ему git?
Нужен даже больше, чем команде из нескольких человек. Именно один человек, который может уволиться, заболеть или просто забыть контекст правки полугодовой давности, чаще всего и создаёт файл-кашу на сервере. Git в этом случае — страховка компании, а не инструмент для программиста.

Как откатить конкретную правку, если конфигурация уже обновлена поверх неё?
Смотрите историю коммитов, находите нужный, и через git revert откатываете только этот кусок изменений, не трогая остальные доработки. Дальше загружаете получившуюся конфигурацию обратно в базу через Конфигуратор и тестируете на копии перед тем, как накатывать в бой.