Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git
Разработка - Групповая разработка (Git, хранилище)
Часть 1. Как подключиться к команде разработки и начать использовать Git (эта статья)
Вводная, или куда послать 1С-ника, не знающего Git
Регистрация на GitHub, GitLab и BitBucket
Установка дополнительных библиотек OScript
Подключение к проекту и создание локального репозитория
Клонирование репозитория с BitBucket
Клонирование репозитория в SourceTree
Клонирование репозитория с GitLab
Часть 2. Реализация Git workflow в 1С-разработке по шагам
Начало работы над задачей
Процесс жизнедеятельности задачи
Фиксация изменений
Отмена изменений и других последствий невнимательности
Отказ от индексирования изменений
Игнорирование файлов, файл .gitignore
Отмена изменений в индексе
Просмотр изменений
Слияние готовой фичи в develop
Вариант 1. Локальный merge
Вариант 2. Создание запроса на слияние
Вместо заключения. О чем договариваемся в команде
Предисловие
Несмотря на то, что еще в 2015 году в версии платформы 8.3.6 появилась возможность раскладывать конфигурацию в исходные файлы, до сих пор лишь малая доля команд разработчиков 1С используют Git в своей повседневной деятельности. Причин тому несколько, и здесь мы не будем на них останавливаться. Моя главная цель: популяризировать командную разработку на Git в мире 1С и понизить порог вхождения в нее наших коллег. Как раз этому посвящена данная серия статей, и перед вами - первая из них. Итак, поехали!
Но для начала...
Вводная, или куда послать 1С-ника, не знающего Git
Меня часто спрашивают, с чего начать изучение Git и как безболезненно перейти с хранилища на использование системы контроля версий (СКВ)? Отвечаю на первую часть вопроса.
Для тех, кто совсем не знаком с СКВ Git или чувствует свою неуверенность при работе с ним, рекомендую изучить следующие источники (именно в таком порядке):
Простой пошаговый учебник-самоучитель, после которого отпадёт основная масса вопросов и сомнений (изучение ок. 5 часов с практикой).
Чтобы ближе познакомиться с Git:
Если кому-то удобнее видео-формат, то рекомендую посмотреть лучший видео-курс по Git от Lynda.com.
Ну а для освоения фигур высшего пилотажа - штудируем официальную книгу. В ней же хорошо описывается суть и назначение систем контроля версий, поэтому я не буду тратить время на описание того, что такое Git, для чего он нужен и почему это круто.
Вы можете самостоятельно нагуглить и другие источники, но этого базиса вполне достаточно, чтобы после его освоения начать перевод своей 1С-команды на использование Git.
Организация рабочего места
Прежде чем начать использовать Git в 1С-разработке, необходимо выполнить установку дополнительного ПО и его первоначальную настройку. Также выполним первое подключение к Git-репозиторию. То есть, подготовим всё необходимое сразу, чтобы уже не возвращаться к этому в процессе работы.
Говоря о ПО, необходимом для работы с Git, следует отметить, что для каждой из рассмотренных ниже задач есть гораздо более широкий выбор вариантов, я опишу здесь только по одному из них. Вы же можете использовать то, что вам больше нравится или лучше подходит именно для ваших задач:
- Система контроля версий. Они, неожиданно, тоже бывают разные. Мы будем использовать Git;
- Интерфейсная оболочка для работы с Git, или т.н. Git GUI. Их разнообразие может впечатлить, о наиболее популярных можно почитать здесь. Я остановился на SourceTree от Atlassian. А вообще, можно и вовсе обойтись без нее, и выполнять все команды Git из командной строки. Но, как правило, 1С-ники не любят командную строку, им больше нравится нажимать на кнопки, поэтому займёмся установкой SourceTree;
- Git-сервер. Как правило, в корпорациях устанавливают свой собственный сервер версионирования для Git. Мы рассмотрим наиболее популярные открытые облачные сервисы (или хостинги) GitHub, GitLab и BitBucket;
- Конвертеры исходного кода 1С. OneScript, просто OneScipt;
- Редакторы кода. Эта тема вообще уходит далеко за пределы мира 1С. Просто поставьте себе Visual Studio Code, и будет вам счастье. Кстати, она же является неплохим Git GUI.
Регистрация на GitHub, GitLab и BitBucket
Чтобы иметь возможность работать с системой версионирования кода в группе разработки, прежде всего, необходимо иметь свой аккаунт на одном из хостингов Git. Очень вероятно, что такой аккаунт у вас уже есть, поэтому данная часть инструкции сделана опционально. Если нет - выбирайте, что вам больше по душе:
Заходим на сайт https://github.com/. Если вы еще не работали с этим ресурсом, откроется такое окно:

Нажимаем кнопку "Sign up for GitHub" для регистрации нового аккаунта. В открывшемся окне вводим логин (проверяется уникальность имени), адрес электронной почты (проверяется уникальность) и пароль. После успешной верификации (две зелёные галки) нажимаем "Create an account".

На следующем шаге можно выбрать рабочий план: по умолчанию установлена бесплатная регистрация с неограниченным числом публичных репозиторием. Если необходимо ипользовать приватные репозитории за 7$/мес., то указываем второй вариант. Нажимаем "Continue".

Далее GitHub просит заполнить мини-анкету и ответить на несколько вопросов о вашем профессиональном уровне. Отвечаем, затем нажимаем "Submit" для завершения регистрации аккаунта.

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

Заходим на сайт https://about.gitlab.com/. На главной странице находим ссылку "Sign in/Register". Проходим по ней, и в открывшемся окне выбираем вариант (закладку) "Register".

Здесь указываем свои логин, адрес электронной почты и пароль. Ниже ставим галку о согласии с лицензией и "Я не робот". Затем нажимаем "Register".

Теперь в своем почтовом ящике находим письмо от GitLab и проходим по высланной в нём ссылке для активации аккаунта.
(Если письмо не обнаружено, загляните в спам)

Регистрация завершена!
Заходим на сайт https://bitbucket.org:

Далее, либо нажимаем ссылку LogIn, и тогда в открывшемся окне:

жмём внизу "Sign up for an account";
Либо щелкаем по ссылке "Get Started", и сразу оказываемся на странице регистрации нового аккаунта:

Вводим свой электронный адрес. Будет выполнена проверка существования такого же аккаунта. И, если такового еще нет, получаем зелёную галку и жмём Continue. На следующем шаге указываем своё имя, придумываем пароль и говорим "Я не робот". И снова Continue.

После этого вам останется зайти в свой почтовый ящик и жмакнуть по высланной ссылке для подтверждения регистрации.

На этом регистрация завершена, можно приступать к работе.

Установка Git
Установка Git описана для версии 2.18.0. Процесс установки и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта проекта файл установки (скачать...).
Запуск установки следует выполнять под администратором и от имени администратора (это важно!!!). На первом шаге нажимаем "Next >", на втором шаге "Выбор компонентов" оставляем всё по умолчанию, и тоже жмём "Next >".

Если оставить эти два флажка (установлены по умолчанию), то в проводнике Windows эти две команды будут доступны из контекстного меню текущего каталога. Таким образом, можно быстро выполнить команды Git из командной строки, "не отходя от кассы", если нужно выполнить что-то простое и нет смысла запускать большие GUI-приложения. Советую оставить.
На 3-м шаге мастер установки предлагает выбрать редактор по умолчанию, который будет работать с Гитом. Тут вы вольны выбрать то, что вам больше нравится использовать для редактирования текстов. Но я настоятельно рекомендую присмотреться к Visual Studio Code.
Идём далее, и на следующих трёх шагах оставляем все настройки по умолчанию.

На 7-м шаге оставляем выбор по умолчанию консоли Windows для работы с Git Bash. На последнем шаге также ничего не меняем и запускаем установку.

Процесс установки займёт какое-то время, после чего появится финишное окно, на котором нажимаем Finish.

На этом установка Git завершена, однако перед началом его использования необходимо единожды выполнить некоторые глобальные настройки системы контроля версий.
Первоначальная настройка Git
Все команды будем выполнять из командной строки. Если во время установки Git у вас была запущена командная строка, перезапустите её.
|
Внимание! Командную строку следует запускать под администратором, чтобы избежать ошибок прав доступа при выполнении некоторых команд. |
Во-первых, зададим имя пользователя и адрес электронной почты, которыми будет идентифицироваться авторство коммитов в репозитории Git:
git config --global user.name "Your Name"
git config --global user.email "your_email@whatever.com"
Во-вторых, установим настройки правил коммита окончаний строк, это в дальнейшем поможет избежать ошибок при коммите изменений в исходных файлах конфигураций 1С:
git config --global core.quotepath false
git config --global core.autocrlf false
git config --global core.safecrlf false
|
Внимание! Ключ core.autocrlf влияет на кроссплатформенные приложения. Поэтому, если есть необходимость коммитить с этой же машины код, который должен работать под Mac/Linux, необходимо проявлять осторожность. Например, задавать значение параметра не глобально для всей СКВ Git, а для каждого репозитория в отдельности. |
Установка SourceTree
Установка SourceTree описана для версии 2.6.9. Процесс установки и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта Atlassian файл установки (скачать...).
На первом шаге соглашаемся с лицензионным соглашением и нажимаем "Вперёд".
На этом этапе SourceTree требует ассоциации с аккаунтом Atlassian (появляется после регистрации на BitBucket). Можно либо указать свой существующий аккаунт (должен быть зарегистрирован до установки программы), либо выбрать вариант регистрации нового аккаунта, тогда SourceTree поможет пройти необходимые шаги регистрации и произведёт ассоциацию с новым аккаунтом. Далее рассматривается вариант, когда аккаунт на BitBucket уже зарегистрирован, и нам остаётся только к нему подключиться.
Выбираем вариант "Учетная запись Atlassian":

Появится окно авторизации, в котором указываем логин и пароль нашего аккаунта и нажимаем "Log in". После верификации учётной записи появится окно с сообщением об успешной авторизации. Идём "Вперёд":

При установке SourceTree можно автоматически установить и сам Git, если на следующем шаге указать соответствующий флажок. Если у вас еще не установлен Git, можете сделать это сейчас. После нажатия кнопки "Вперёд" скачан и установлен Git, что займёт некоторое время, затем появится окно об успешном завершении установки:

На последнем шаге можно загрузить SSH ключ, если таковой имеется. Мы пока пропустим этот шаг и нажмём "Нет":

Сразу после этого откроется главное окно SourceTree, готовое к работе:

В своей папке пользователя Windows создаём и заходим в папку .ssh (именно так, с точкой).
Правая кнопка мыши -> Git Bash Here. В консоли набираем: ssh-keygen -t rsa, три раза Enter (имя файла и пароль вводить НЕ НАДО).
В папке C:\Users\%Username%\.ssh появится пара файлов с именами id_rsa и id|_rsa.pub.
Файл id|_rsa.pub - это публичный SSH ключ, который можно залить в свой профиль на GitHub/GitLab/BitBucket или локальный сервер-хранилище Git (тот же GitLab даёт такое), и который так же ассоциирует разработчика, как конкретного пользователя. Второй файл не надо отправлять никому, кроме самого себя на другой свой компьютер, с которого предполагается работа с тем же проектом в Git.
Установка OneScript
Установка OneScript (он же OScript, он же 1Script) описана для версии 1.0.20. Процесс установки, состав устанавливаемых компонент и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта файл установки (скачать...).
Сама установка состоит всего из двух шагов, на каждом из которых оставляем всё по умолчанию и нажимаем "Next >" (на первом), "Install" (на втором), затем немного ждём, когда программа установится и в последнем окне нажимаем "Finish". Установка завершена!

Установка дополнительных библиотек OScript
Возможности OneScript легко расширяются путём установки дополнительных библиотек из серии oscript-library. Вы также можете написать собственную библиотеку, если возможностей существующих недостаточно. Как это сделать, подробно описано здесь.
Установить дополнительные библиотеки можно с помощью менеджера пакетной установки opm, который у вас только что установился вместе с OneScript. Для работы с 1С, в общем случае, пригодятся следующие библиотеки:
Precommit1C - при коммите в git-репозиторий изменений внешних отчётов, обработок или расширений конфигураций автоматически раскладывает их на исходные файлы. Это позволяет, во-первых, видеть авторство и причины изменений каждой строчки кода, а, во-вторых, не тратить время на самостоятельный разбор в исходные файлы и не ломать голову, куда их положить и как структурировать;
Устанавливаем:
opm install precommit1c
Установка oscript-библиотеки считается успешной, если библиотека сама стала вызываться из командной строки как самостоятельное приложение, например:
precommit1c --help
Gitsync - занимается разбором конфигурации 1С из хранилища в исходные файлы для версионирования.
opm install gitsync
Packman - для обратной сборки файла конфигурации из исходных файлов из репозитория Git.
opm install packman
Deployka - содержит набор функций для поставки изменений конфигураций в тестовые и рабочие контуры. Подробную информацию о возможностях и порядке использования "деплойки" можно почерпнуть из вебинара, а здесь познакомиться с практическим примером ее применения.
opm install deployka
Установка Visual Studio Code
Установка VS Code описана для версии 1.27.2. Процесс установки, состав устанавливаемых компонент и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта файл установки (скачать...).
Первые 4 шага стандартные и не представляют особого интереса: соглашаемся с лицензионным соглашением, указываем папку для установки и т.п. Нажимаем везде "Далее".

На следующем шаге выбираем настройки среды "под себя": необходимость добавить быстрый переход в VSC из контекстного меню файла или каталога, а также зарегистрировать VSC в качестве редактора по умолчанию для поддерживаемых типов файлов. При установке последней, для использования в VS Code будут зарегистрированы расширения файлов наиболее популярных языков программирования и конфигурационных файлов сред разработки. Для нас среди них представляют интерес *.feature и *.md. Если вам не нужна регистрация для всего "зоопарка" файлов, которые никогда не будут использованы, можете не ставить эту галку, но после установки не забудьте зарегистрировать для VS Code эти расширения. А также расширение *.bsl (по умолчанию не ставился) для редактирования текстов модулей 1С.

После нажатия "Далее", останется согласиться с выбранными параметрами, запустить установку и дождаться ее окончания.

Установка плагинов
Прелесть VS Code заключается в том, что его функционал можно гибко расширять и настраивать с помощью плагинов (или расширений). Существует бесчисленное множество плагинов для различных языков программирования (и не только программирования) и удобства работы с отдельными инструментами, в том числе и для языка 1С.
Чтобы установить плагин, в главном окне VS Code открываем раздел "Расширения" и строке "Поиск расширений в Marketplace" набираем "bsl".

Среди найденных плагинов выбираем "Language 1C (BSL)" от известной нам команды коллег, и нажимаем на кнопку "Установить".

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

Как видно из рисунка, по щелчку на плагине, в рабочей области VSC появляется описание с инструкциями по использованию, что очень удобно при знакомстве с новыми плагинами.
В дальнейшем, вы непременно захотите продолжить улучшение рабочей среды с помощью плагинов. Подборка наиболее интересных из них находится здесь.
Подключение к проекту и создание локального репозитория
Теперь, когда весь необходимый софт установлен, самое время перейти к созданию своего первого репозитория Git. В зависимости от формата проекта и способа взаимодействия в команде, существует несколько способов подключить у себя репозиторий.
В большинстве случаев, при начале работы в команде, использующей Git, вам предстоит клонировать репозиторий с Git-сервера. Если репозиторий на сервере является публичных, то можно смело приступать к операции. Если же он приватный, то прежде необходимо запросить у владельца или мастера репозиторий выдать вам права доступа. При этом, если предполагается в дальнейшем выполнять коммиты (фиксировать свои изменения), то должны быть права разработчика, Для возможности клонирования достаточно иметь право на чтение.
Клонирование репозитория с BitBucket
Откройте страницу репозитория, нажмите кнопку «Клонировать» и скопируйте появившийся путь к репозиторию.

Клонирование репозитория в SourceTree
Далее, в SourceTree нажимаем кнопку с плюсиком в строке закладок и выбираем вариант Clone (Клонировать).

Вставляем скопированный путь в поле «Исходный путь/URL», указываем каталог для хранения локальной копии репозитория в графе «Целевой путь» и название нового репозитория. При необходимости можно дополнительно разделить репозитории на тематические группы, название группы выбираем в поле «Local Folder».

Нажимаем кнопку «Клонировать», и после завершения процесса клонирования (время зависит от объема репозитория) мы получим у себя локальную копию репозитория проекта, готового к работе.
Установка Precommit1C
Для реализации первого кейса нам предстоит версионировать внешние отчеты, обработки и расширения конфигураций. Но хранить их "как есть" не очень хорошо, поскольку в таком случае мы не увидим вносимых изменений и не сможем их проанализировать. Для решения этой задачи, у перечисленных объектов есть функция выгрузки в файлы. Но каждый раз нажимать эту кнопку и вспоминать, в какую папку их положить, чтобы ничего не нарушить, - тоже не хорошо. Эту операцию следует автоматизировать, и делать мы это будем с помощью Precommit1C.
Precommit1C – это хук для автоматической выгрузки в исходные файлы внешних отчётов/обработок и расширений конфигураций. Его использование позволяет полностью отвлечься от рутинной операции выгрузки в исходные файлы, принятия решения о месте расположения этих самых исходников, и возложить эту работу на инструмент автоматизации.
Подробно о работе Precommit1C можно узнать из первых 30 минут вебинара, также подробная инструкция находится на главной странице репозитория инструмента.
Установку Precommit1C можно произвести несколькими способами, рассмотрим два из них.
Вариант 1. Клонирование репозитория инструмента
Заходим на сайт проекта, находим кнопку «Clone or download» и копируем путь к репозиторию.

Далее, в SourceTree добавляем новый репозиторий аналогично тому, как мы это делали для основного репозитория проекта (см. раздел "Клонирование репозитория в SourceTree). Из локального репозитория Precommit1C копируем следующие файлы и папки:
- pre-commit
- v8Reader
- v8files-extractor.os
- tools
и вставляем их в папку hooks, которую необходимо создать в каталоге “.git” корня репозитория.
Вариант 2. Установка через opm
Устанавливаем пакет:
opm install precommit1c
Устанавливаем хук в каталог проекта:
cd c:\dev\repo\sed
Precommit1c --install
Клонирование репозитория с GitLab
.Процесс клонирования репозитория с GitLab, пожалуй, самый простой из всех, поскольку ссылка-путь и кнопка для ее копирования находятся непосредственно на главной странице проекта. Поэтому просто копируем этот путь и далее повторяем шаги, описанные в разделе "Клонирование репозитория в SourceTree".

Форкаем интересные проекты на GitHub
Когда мы хотим присоединиться к OpenSource-проекту, размещённому на GitHub, то тут процесс подключения к проекту несколько отличается. Поскольку доступа к прямому коммиту в оригинальный проект нам никто не даст, необходимо сначала создать в своём аккаунте репозиторий-потомок оригинала (т.н. fork). Затем выполнить клонирование в локальную копию уже своей копии-потомка и выполнять разработку уже в нём. Затем, для того чтобы поделиться новым полезным функционалом с сообществом, мы будем выполнять запросы на слияние (т.н. pull request).
На странице интересующего проекта нажимаем кнопку fork, дожидаемся появления нового репозитория в своём аккаунте и далее выполняем его клонирования согласно описанию в разделах "Установка Precommit1C" и "Клонирование репозитория в SourceTree".

Заключение
На первый взгляд может показаться, что объем работы и количество ПО, с которым предстоит работать, пугающе большое. Но после того, как вы настроите у себя пару первых репозиториев, дальше дело пойдёт "как по маслу".
А уже в следующей статье мы рассмотрим, как выполнять отдельные операции в работе на проектом: взять задачу в работу, зафиксировать результат в основном стволе разработки, исправить ошибку в коде и другие действия, из которых состоит повседневная жизнь разработчика. Удачи!
ТОП-6 инструментов для разработчика 1С
Подборка лучших инструментов для разработчика 1С включает Toolkit, DCT, OneDebugger, PrintWizard, DataFormWizard и Infostart MCP. Любой инструмент со скидкой 20% при покупке от двух решений.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Разработка Инструментарий разработчика Групповая разработка (Git, хранилище) Разработчик Платные (руб)
Практический курс по работе с AI-агентами для разработчиков 1С уровня middle и senior, а также тимлидов команд: от постановки задач и передачи контекста до создания расширений, интеграций, MCP-инструментов, тестов и проверки готового решения.
50000 руб.
10.09.2026 13802 124 0
DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Системный администратор Разработчик 1С 8.3 1С 8.5 Бесплатно (free)
В прошлой статье у ERP оставалось 89 отказов загрузки, у ЗУП — 19. Теперь обе конфигурации совпали с эталонами, а собранные файлы прошли круг через платформу. Развертка выделена в открытый репозиторий cf-unwrapper: библиотека на Rust и консольная утилита. Показываю результаты, объясняю границы «100%» и приглашаю к проверкам и развитию проекта.
02.11.2026 302 oyti 1
DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Практическое руководство для команд, которые хотят уйти с хранилища конфигурации на git, не переходя на новую среду разработки. Подойдёт разработчикам и тимлидам, которые настраивают командную разработку на типовых и собственных конфигурациях.
02.11.2026 596 vanya_gonchar 2
Файловый обмен (TXT, XML, DBF), FTP DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Системный администратор Разработчик 1С 8.5 Бесплатно (free)
В прошлой статье я выгрузил Бухгалтерию в XML байт в байт и спросил, на чем проверить дальше. Вы ответили: ERP, старые релизы, зарплата. Прогнал пять конфигураций, от клиента ЭДО до ERP на 120 тысяч файлов. Рассказываю, что сломалось после Бухгалтерии, почему эталону платформы нельзя верить на слово, как выгрузить одну конфигурацию в формат трех версий платформы - и почему cf-конвертер становится отдельным продуктом, Разверткой.
02.11.2026 402 oyti 2
Инструментарий разработчика Групповая разработка (Git, хранилище) Разработчик Стажер 1С 8.3 Абонемент ($m)
Два разработчика, по десять правок «Нано-УТ 2.0» в git: длинные ветки против слияния после каждой правки, 22 слияния с загрузкой main в чистую базу. ConfigDumpInfo.xml конфликтовал в 11 слияниях из 11, построчное объединение ломало XML и модули. Показываю, что убрать строкой в .gitattributes, что разбирать целыми вставками и как увидеть конфликты до слияния. Прилагаются инструмент с 38 тестами и материалы опыта.
1 стартмани
29.10.2026 401 Ninel_S 3
DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С 8.5 Бесплатно (free)
Выгрузка типовой Бухгалтерии в XML через базу занимает больше четырёх минут. Я написал движок, который читает файл конфигурации напрямую и выгружает его за 35 секунд, совпадая с выгрузкой платформы байт в байт во всех 90 385 файлах. Загрузка обратно тоже работает: круг через платформу совпадает полностью. Рассказываю, как ускоряли, как проверяем и что при загрузке XML теряет сама платформа. А в конце спрашиваю, нужно ли это кому-то, кроме меня, и на какой конфигурации проверить следующей.
27.10.2026 960 oyti 20
Рефакторинг и качество кода Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
Скрипт на Python посчитал метрики 2711 общих модулей УТ 11.5: 26 модулей длиннее 10 000 строк кода. Проверила счёт на синтетических модулях и показала, где рейтинг ошибается: самый длинный модуль оказался в нём ниже девяти коротких. Для разработчиков 1С. В архиве скрипт, тесты и журналы.
1 стартмани
26.10.2026 438 Ninel_S 8
Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
Общие модули 1С вынесла в подмодуль Git и подключила к двум проектам на выгрузке «Нано-УТ» и платформе 8.3.27. Подмодуль на весь каталог CommonModules загружается; клон без --recursive даёт код 1, а забытый указатель и смена ветки молча дают базу не той версии. Переименованная процедура прошла /CheckModules при 28 вызовах. В архиве скрипты, диагностика подмодулей, тесты и журналы.
1 стартмани
26.10.2026 424 Ninel_S 0
тут нужно остановиться и воспроизвести слово "зачем"
зачем тонна софта в инфраструктуре по типу карточного домика и для каких задач?
Я бы понял если нужно разгребать тучу коммитов и форков драйвера или утилиты для Linux (для чего собсто git и делался),
а в 1С зачем? Устраивать самому себе стрельбу в ногу - когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул, а ты такой полдня в поиске проблемы вместо нажатия на кнопку "Поместить в хранилище"?
Да ну подождите вы EDT
Что у нас должно поменяться со смертью УПП и для чего нам EDT?
Но лично я ощутил на себе и своих разработчиках массу плюсов в использовании Git, поэтому и родилась идея этой серии статей.
Куча софта? Да не такая уж и куча, если учесть, какой кучей вы уже пользуетесь. Просто для вас это стало естественным. Пройдёт совсем немного времени, и так же естественно будет открыть VS Code для редактирования модуля.
Глюки? Бугага! За два года ни разу ничего не глюкануло! А вот хранилище глючит с завидной регулярностью. И приходится сидеть ждать, пока админы что-то починят на серверах и роутерах, пока можно будет снова захватить или поместить объект. А это время, а это деньги.
После одного случая, где для поиска автора и породившей изменение задачи потребовалось более 6 ти часов, для меня это стало очень большим преимуществом.
С хранилищем - при большой истории изменения объекта - печаль и боль.
тем временем в комментах с новостями про EDT люди пишут.
"зачем нам EDT, вдруг он у нас отвалится и мы не сможем сдать подсистему"
Я заметил, что 1Сники очень консервативные люди и очень сильно боятся чего-то нового, постоянно аргументируя тем, что все атвалицтся и они бедненькие не успеют чего-то там, при этом то же хранилище, скажем так, немного не стабильно порой, да в принципе все кто связан с 1С уже привыкли страдать
Юзеры, которые уже давно не удевляются тому, что "1С глючит", разработчики, которые ходят по отделам и спрашивают, "а кто это написал" и тд.
Собственно хайп вокруг git + 1C возник именно на этой почве, людям и бизнесу в целом надоело страдать в то время, когда коллеги из других направлений разворачивают "гиты", "сиай", пишут тесты и крепко спят по ночам, при этом еще и на выходных отдыхают.
Есть конечно 1 кейс, при котором git скорее будет излишним усложнением:
Количество разработчиков ~1 и в вашей компании баги и простои 1С не сильно сказываются на работоспособности бизнеса, если это так, то тут действительно git возможно не нужен, хотя даже при таком раскладе, версионировать обработки \ ВПФ и тд без гита в принципе сложно сейчас.
Много вопросов за кадром, но вероятно они будут освещены в следующих статьях.
Но один все же меня мучает: "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С" - это как? Хоть в двух словах? Как, например, быть с созданием и редактированием форм в "основном инструменте"?
VSCode используют в двух сценариях:
1) В паре с OneScript
2) Когда вы выгрузили свою конфигурацию в git разобрав её на исходный код - для поиска нужной вам информации. Тк поиск в самом конфигураторе может быть несколько продолжительным.
Гитом активно пользуюсь, но все руки никак не доходили настроить настроить разбор обработок на исходный код, так и храню бинарниками.
Было бы здорово, если бы 1с добавила в конфигуратор кнопочку для выгрузки в git (EDT очень не нравится).
Ну а пока, видимо, придется заморочиться и разобраться с Precommit1C
Я не утверждаю, что невозможно положить исходники обработки в git.
Утверждать подобное было бы вдвойне глупо в комментариях такой статьи.
Судя по всему все сведется к попытке подружить precommit1C с gitKraken.
Просто руки до сих пор не дошли.
Я говорю об отсутсвии "пердолинга":
Как было написано в статье, скопировать его файлы в каталог хуков. И все на этом.
Потом держать открытым SourceTree и время от времени делать commit (и пуш может быть).
Автоматически из конфига не получится.
Только вместо SourceTree (нет под линь, а я какт предпочитаю инструменты которые есть и под пингвина и под форточку) использую GitKraken
Нужно было придумать некий git hook (как написано в статье) который перед коммитом будет разбирать обработки.
Эта статья вышла очень кстати и вероятно поможет наконец сделать то, что стоило сделать давным-давно.
Все что есть, реализует git, по сути это как сравнивать одноклассники с вк, вроде интерфейс разных цветов, а суть одна и таже.
GitLab вы можете поднять на локальном сервере. GitHub довольно популярен для публичных репозиториев.
Если хотите практически бесплатно и большой любитель похардкодить приватные данные - используйте GitLab.
Самый простой способ:
1) Создаете новый репозиторий прям через web интерфейс
2) Клонируете его к себе на диск
3) Закидываете свои локальные данные в появившуюся папку, коммитите (git commit -m "first push")
4) Толкаете (git push)
А эта тема будет освещена в третьей части.
Можете сразу списывать 4 гига оперативы. Но мне не жалко, ведь жаба давит ежемесячно платить гитхабу 7$ за приватных репозиториев (а мне нужно больше) С:
Пара моментов. Функционал deployka сейчас переехал в runner. Использовать стало удобнее. Приведен к стандарту формат длинных и коротких ключей. Сейчас есть смысл переписать команды с deployka и vrunner на runner и рекомендовать использование последнего.
При установке git для работы с 1С все же лучше выставлять настройки отличные от настроек по умолчанию. Лучше выставлять commit as is + checkout as is. Перегонять окончания строк в Unix-style и обратно кажется нецелесообразной тратой ресурсов, особенно при работе с большими конфигурациями на 5-7 миллионов строк. Также лучше не отказываться от инструментов, входящих в пакет git, они выручают.
Возможно покажется полезной еще такая информация. Наиболее удобным способом работы c git в сочетании с 1С кажется даже не использование Gitlab/Github/Bitbucket, а создание репозиториев на собственном сервере и работа с ними либо напрямую как с локальным каталогом, либо через ssh-сервер. При этом упрощается обслуживание и контроль.
Такие инструменты как Upsource и Fisheye/Crucible позволяют работать с Native репозиториями, расположенными прямо на локальных дисках. Мы получаем все преимущества облачных систем внутри компании. За исключением пул/мердж реквестов, которые при работе с хранилищем и не нужны. Экономим на дорогих лицензиях Bitbucket или Github Server, нет необходимости обслуживать Linux / Docker для того, чтобы хостить GitLab.
В случае совместной работы с репозиторием лучше все таки поставить ssh-сервер. Для Windows перебирал разные варианты ssh-серверов и самым удобным и беспроблемным в отношении именно git оказался Bitvise. Дополнительным плюсом являются оповещения о входящих подключениях, попытках успешной и не успешной авторизации, это сильно ускоряет первоначальную настройку сервера. Поставить для изучения - бесплатно. Для компании - копейки. Есть не очевидные тонкости настройки, если будет интересно - пишите, расскажу.
По темам для следующих публикаций. Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт. Какие сложности при этом возникают, особенности настройки и организации процесса. Возможно вторая тема "Организация Git workflow в 1С-разработке" как-то затронет этот вопрос?
Также интересна тема "Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С". Буду ждать. Сейчас использую VSC для скриптов OneScript, пайпланов Jenkins и файлов Gherkin. Было бы интересно узнать, можно ли расширить область применения VSC в отношении именно разработки на 1С.
Меня наоборот, очень интересуют реальные схемы работы Git + Хранилище. Чтобы рабочая база не из гита напрямую собиралась, а чтобы релизы через хранилище шли. Общая схема вроде понятна, но про реальные наработки было бы интересно послушать.
Цитата отсюда:
Т.е. из гита собрать cf, cf в хранилище, из хранилища в рабочую. Вроде всё реально.
Вот .
Что-то этот пункт мне не сильно нравится. Почему не собирать штатно напрямую в конфу с подключенным хранилищем и захваченными объектами?
Судя по всему, при подключенном хранилище это сделать не получится... Тогда понятно.
ЗЫ. Я вообще не понимаю, как люди на самом деле работают. Неужели все продакшн
Я релизы делаю из хранилища.
Для подготовки файлов поставки есть отдельная файловая база (1С:ERP), напрямую неподключенная к хранилищу. Когда нужно выпустить релиз, в командной строке выполняю следующую команду:
deployka loadrepo /FD:\1C_Data\erp_delivery D:\1C_Storage\erp -storage-user Администратор -v8version 8.3.10
В результате выполнения команды, конфигурация забирается из хранилища, и далее делаю поставки обычным стандартным образом в конфигураторе.
Спрашивайте, если что-то осталось непонятно.
Я пока сижу в хранилищах, и не шибко понимаю, вот эти все описанные в итоге в статье, действия, они по итогу - какое существенное преимущество дают, относительно того же хранилища. Читал ресурс по едт от 1С, типа объект могут править сразу несколько человек и на этапе мерджа, или как-то так, можно типа разрулить все круто. Но опять же, я пока не столкнулся с этими проблемами.
Может кто из коллег подскажет уже сейчас, когда есть смысл в практической работы переезжать с хранилищ на эти гиты, деплойки, какие-то в раннеры и все что в статье и комментах описано?
git -- распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.
git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.
Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая "git flow".
Хранение любой информации. В отличие от хранилища 1С, в git можно хранить любую информацию (желательно текстовую, но это не обязательно). Поэтому при использовании git возникает возможность хранить не только конфигурацию, но и все внешние отчеты, обработки и другую сопутствующую информацию.
По чисто субъективной оценке взятой с потолка 95% коллективной работы программистов 1С сводится к изменению структуры метаданных, доработке форм и макетов (в первую очередь СКД, но и обычных печатных форм тоже море). Как тут может помочь этот умный блокнот? Пара комментаторов заметила, что там скорость текстового поиска выше, но лично для меня во всех рабочих конфигурациях это не является проблемой (с ERP не работал - возможно там поиск действительно долгий особенно без SSD-диска и с маленькой оперативкой).
В курсе использовали VSCode для вспомогательных целей (не для редактирования исходников 1С): например, для подготовки настроечных файлов для вспомогательных утилит тестирования, подготовки поставок, написания пайплайн-файлов для дженкинса и чего-то еще.
О причинах его использования уже не раз было написано тут же в комментах.
добавить строчку
DisableUnsafeActionProtection=.*;
Здесь ".*" - регулярка, определяющая имена баз, для которых проверка отключена
Нигде в подобных статьях или циклах статей я не нашел ответа на этот вопрос.
Три ветки maste, release, develop. от develop на задачу делаем ветку, потом сливаем ветку задачи с develop.
Слияние - как его делать? Ведь код модуля это далеко не все, что есть в разработке на 1С. То есть мы текстовые файлы конфигурации вручную объединяем или все таки cf сравнением-объединением вливаем в develop? может EDT умеет это делать из коробки и понятно и наглядно?
Затем, когда из develop в release сливаем тоже - как? и затем в master.
Сидит специально обученный человек с квадратной головой, который все конфликты и мержи разрешает?
Делается ли сборка cf из файлов конфигурации или файлы отдельно для комментариев и Jira. а cf отдельно для нормального объединения изменений?
Эти вопросы все гуры по git как-то обходят стороной, а именно они не дают принять решение о переходе на трушные технологии разработки.
Этой теме внимание будет уделено совершенно точно, но не обещаю, что результат будет таким, каким его ожидаете именно вы )) В частности, EDT пока не планирую рассматривать.
Ждемс..)
Рекомендую к прочтению:
Мы с команде используем gitsync, он раскладывает и соммитит конфу при появлении коммитов в хранилище. А расширения и внешние отчеты/обработки выкладываем вручную, через кнопку "Выгрузить в файлы"
как перевести всю команду чтобы они работали в ГИТ с конфой, при том что сейчас они все подключены к общему хранилищу ?
1. Настроить выгрузку конфы из хранилища в Git с помощью gitsync
2. Привязать коммиты в репо к задачам в вашем такс-трекере
3. Сделать перекрестное код-ревью обязательным этапом вашего ворк-флоу (в git это делать гораздо удобнее)
Так вот GitHub/Gitlab и прочее поддерживают максимум 50 либо 100 МБ. Так как мне обойти эту проблему? Использовал GitLFS - но когда ты изменил строчки кода - то он не показывает что именно я изменил, просто тупо файл один заливается. Объясните зеленому пожалуйста :)
opm install packman
А дальше? Как автоматически собирать при выкачивании из GITa?
Добрый день! Стас, в примере статьи клонируется облачный репозиторий в локальный репозиторий на диске. Хотелось бы развернуть свой репозиторий и подключаться к нему, как к удалённому, например, по http или https. Никак не могу найти пример такой настройки Git, можете подсказать?
Да, в статье предполагается, что репозиторий уже существует.
Создание нового репо зависит от того, что у вас за проект?
Если вы ведете разработку в EDT, то лучше использовать встроенные инструменты платформы для этого, там есть 4 варианта создания репозитория;
Если разработка ведется в конфигураторе, то конфигурация выгружается в файлы через меню "Конфигурация - Выгрузить конфигурацию в файлы". Репозиторий создается отдельно в локальной папке или сразу на Github, затем файлы выкладываются в папку в репо и синхронизируются.
Это если кратко, возможно слишком коротко. Подробная инструкция может вылиться в отдельную статью ))
Вообще на ответ натолкнула ваша фраза
Здесь, в первой статье, вы пишите что для "экспорта" в XML-и для внешних обработок используете precommit1c, для конфигураций (и расширений, полагаю) - gitsync из хранилища.
Также, описываете как клонировать себе удаленный репозиторий и создать локальный. Всё подробно и с картинками.
А потом что? Разработчик же работает с Конфигуратором и Хранилищем, а не с EDT (в рамках статьи). Каким образом то, что он склонировал к себе в локальный git-репозиторий оказывается у него в Конфигураторе? И в какое Хранилище он помещает всё, что наработал, чтобы это потом "само" (ну или не "само") синкнулось с его локальным git-репозиторием?
И каким образом он должен действовать дальше, когда разработал свою фичу? Нужно всю эту доработку, состоящую, скажем, из 10-15 промежуточных помещений в Хранилище (каждое из которых отражено в git-репозитории) отдать тестировщику/аналитику на его тестовую базу. А ведь у тестировщика база должна быть не только с вашей доработкой, но и с доработками других коллег-разработчиков. После замечаний устранить их (еще 5 коммитов). И только после этого мы сможем мерджить свою фичу с основной веткой.
Может это проскакивало где-то в комментариях, но я не нашел.
Сильно не пинайте, 2ой день только в теме GIT
Как бороться с ограничением. Выгрузил из ЗУПа конф. и вот такой результат
$ git push -u origin main:main
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs. true
Enumerating objects: 80317, done.
Counting objects: 100% (80317/80317), done.
Delta compression using up to 4 threads
Compressing objects: 100% (21794/21794), done.
Writing objects: 100% (80316/80316), 697.64 MiB | 5.33 MiB/s, done.
Total 80316 (delta 30218), reused 80311 (delta 30217), pack-reused 0 (fr om 0)
remote: Resolving deltas: 100% (30218/30218), done.
remote: GitLab: You are attempting to check in one or more blobs which exceed the 100.0MiB lim it:
remote:
remote: - 57a2f68d9f5ec9a32c9e42370f7d9340aaee9957 (446 MiB)
remote: To resolve this error, you must either reduce the size of the above blobs, or utilize LFS.
remote: You may use "git ls-tree -r HEAD | grep $BLOB_ID" to see the file path.
remote: Please refer to and
remote:
remote: for further information.
To
! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 'http://zgitlab.luk.corp/hrm/RU/ru_ooo_zup.git' ПоказатьВы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 864097
Создание 18.10.18 12:27
Обновление 29.01.19 00:16
Просмотры 291817
Загрузки 0
Рейтинг
439
Комментарии 92
Код открыт Да
Рубрики Групповая разработка (Git, хранилище)
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)