Git-репозитории для 1С-кода (опыт использования при небольших проектах)
Разработка - Групповая разработка (Git, хранилище)
Краткое содержание статьи:
- Установка Git для Windows
- Установка TortoiseGit (для удобства работы с git)
- Клонирование репозитория с файлами из облака на локальный ПК
- Внесение изменений в проект, выгрузка в файлы исходных кодов из конфигуратора
- Отправка изменений на сервер (commit и push)
- Получение измененных файлов с сервера (например, изменены другим разработчиком)
- Создание своего репозитория для новой задачи (в VSTS)
Многое уже было написано на тему контроля версий для 1С-кода, использование хранилищ конфигураций и тому подобное. Здесь я попытаюсь описать именно свой опыт и привести свои инструкции по взаимодействию с Git-репозиторием, которые писались для тех наших программистов, которые вообще никогда не работали с Git (руководства в духе "Как получить код из git-репозитория?", "Как отправить код в git-репозиторий", не будет ни форков, ни мерджа, ни фетча и т.п., только основы).
Возможно, кому-то пригодится данный опыт для начала работы.
И ни в коем случае не хочется претендовать на то, что этот опыт лучший, но для маленькой команды, он оказался довольно эффективным. С удовольствием почитаю Ваши предложения по организации работы с хранилищами при разработке "не конфигураций".
Забегая вперед, скажу, что сейчас, когда вышла вполне вменяемая и пригодная к использованию версия 1C:EDT (Enterprise Development Tools), разработку непосредственно конфигураций перенесли в него, также с выгрузкой кода в git-репозиторий. Не всё в нем гладко, но зато работа с синтаксис-помощником намного удобнее, анализ кода "на лету" и многое другое (но эта тема претендует на совершенно другую статью и не будет обсуждаться здесь, если кому станет интересно, могу выложить небольшие инструкции по работе с git из ETD не через внутренний его механизм, а также через TortoiseGit, созданию нового проекта и загрузке в него изменений, сделанных через конфигуратор).
UPDATE: статья про EDT написана, см. тут ;)
Это вместо вступления, а теперь перейдем непосредственно к теме.
Предисловие к написанным ниже инструкциям:
Основное направление разработки у нас было не создание/редактирование конфигураций, а написание отчетов, обработок и расширений. Поэтому вариант с "хранилищем конфигураций" не рассматривался, как довольно тяжелое и немного замороченное в использовании решение. Поэтому было решено использовать какое-нибудь git-хранилище для маленьких проектов (именно под отчеты/обработки/расширения).
Так как работаю в государственном образовательном учреждении с крайне ограниченным бюджетом, то выделения средств на платные репозитории у нас не предполагались. Начинали мы думать об использовании репозитория три года назад, а тогда GitHub был еще платным в случае закрытых репозиториев (сейчас, после покупки его Microsoft, закрытые репозитории сделали бесплатными, если программистов не более трех). Поэтому на тот момент мы выбрали закрытые онлайн хранилища от Microsoft (которые позволяют работать до пяти программистов бесплатно) - а именно сервисы VSTS (visual studio online).
Почему заостряю на этом внимание - скриншоты в описанных ниже инструкциях будут сделаны именно из него. Но на самом деле это абсолютно не важно. Точно также можно делать и в случае с любым другим хранилищем, например, на гитхабе. Поэтому от скриншотов из "студии" можно немного абстрагироваться и приводятся они просто, чтобы дать представление о том, что можно делать.
Если Вы захотите тоже поработать именно с этим сервисом репозиториев, то данная инструкция поможет Вам быстрее его освоить.
Итак, в нашем примере будут использоваться следующие сведения и условия:
1) Ссылка на общее хранилище (VSTS) для примера: mygit.visualstudio.com (домен третьего уровня задается при создании хранилища в данном сервисе, например, можно назвать его по имени Вашей организации)
2) Пользователь для примера: user@outlook.com (имеющий соответствующий доступ к репозиторию на чтение/запись)
3) Условимся, что в Git-репозиторий выкладывается не только исходный код, но и скомпилированная версия отчета/обработки/расширения для оперативного использования последней версии без необходимости ее "собирать из кода".
1. Установка Git для Windows
Чтобы начать работу с git, нам потребуется установить утилиту Git для Windows (рекомендуется скачивать дистрибутив с официального сайта git-scm.com/download/win).
Возможные примерные параметры при установке:
- Выбрать все компоненты
- Use Git from the Windows Command Prompt
- Use the OpenSSL library
- Checkout Windows-style, commit Unix-style line ending
- Use MinTTY (the default terminal of MSYS2)
- Enable file system caching
- Enable Git Credential Manager


2. Для удобства работы с git (не через командную строку, а через контекстное меню проводника операционной системы) рекомендуется установить TortoiseGit (я его обычно называю просто "черепашкой").
Опять же скачиваем дистрибутив с официального сайта программы: tortoisegit.org/download
При необходимости там же можно скачать русский language pack.
Установка производится без особых дополнительных настроек. В конце рекомендуется согласиться на запуск мастера настройки, где зададим пути для запуска гит и пользователя, под которым будем работать с репозиториями:
- Проверяем, что путь к ранее установленному git.exe указан верно:

- В следующем окне мастера пишем имя (под ним будут делаться коммиты - т.е. написано, кто вносил изменения в код) и свой адрес почты (учетной записи с соответствующими правами на хранилище):

- Настройку ключей в следующем окне производить не обязательно, поэтому можно пропустить, нажав "Готово":

3. Клонирование репозитория с файлами из облака на локальный ПК:
Чтобы начать работать над проектом, нужно создать его локальную "копию" у себя в системе.
Для этого переходим на сайт общих проектов VSTS (в нашем примере mygit.visualstudio.com), выбираем нужный проект, затем нажимаем Code и указываем нужный репозиторий (в данном сервисе один проект может содержать несколько репозиториев). Далее нажимаем ссылку Clone:

В открывшемся окне копируем HTTPS ссылку на репозиторий:

В проводнике создаем папку, в которой будет локально располагаться репозиторий (лучше всего назвать ее также, как репозиторий, чтобы потом было легче ориентироваться при возросшем количестве проектов), затем в контекстном меню данной папки выбираем пункт "Git Clone…" (этот пункт появляется после установки TortoiseGit):

В открывшемся окне вводим ранее скопированный URL репозитория и обязательно проверяем правильность пути папки, в которую он будет загружен (по умолчанию программа добавляет название репозитория к пути текущей папки, поэтому удалите лишнее, если потребуется):

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

Загрузка файлов из облака (полетела "черепашка"):

В локальную папку будет загружено содержимое выбранного репозитория:

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

В случае расширений конфигурации: пункт меню "Конфигурация" - "Выгрузить конфигурацию в файлы":

В качестве места сохранения необходимо указать локальный репозиторий. Также после выгрузки файла необходимо туда же в корень разместить оригинал рабочего файла, если работа с ним происходила в другом месте (файл 1С формата erf и т.п.), на случай, если другой разработчик не сможет "собрать" его из выгруженных файлов-исходников (XML) или нужно сразу использовать результат без перекомпилирования.

Примечание: замечено, что при выгрузке в файлы, если папка и файлы уже существовали, то они не всегда перезаписываются и остаются предыдущие версии. В этом случае необходимо выгрузить файлы в другую (пустую) папку, а затем скопировать их вручную в локальный репозиторий (предварительно очищенный). В этом случае перезапись неизмененных файлов не фиксируется, как изменение, и в коммите будут фигурировать только файлы, где было изменение кода.
5. Отправка изменений на сервер: (commit и push)
После выгрузки обновленных версий файлов из 1С нужно "зафиксировать" результат, т.е. сделать коммит.
В контекстном меню папки репозитория выбираем Git Commit:

В открывшемся окне пишем комментарий к коммиту (что мы изменили/добавили/удалили из предыдущей версии, чтобы другому разработчику при первом взгляде стало примерно понятно, чтобы было сделано) и выбираем измененные и добавленные файлы (ставим галочки у всех файлов, изменения которых нужно отправить в облако репозитория):

Затем нажимаем Commit. До отправки на сервер можно сделать несколько коммитов (отправки в облако при этом не происходит).
Теперь необходимо отправить изменения в облако, для этого в контекстном меню папки репозитория выбираем Git Sync:

В открывшемся окне видим все сделанные нами коммиты. Чтобы отправить их в облачный репозиторий, нажимаем кнопку "Push":

6. Получение измененных файлов с сервера (например, изменены другим разработчиком).
Допустим, теперь нам необходимо получить изменения, сделанные другим разработчиком. Предполагается, что локальная папка проекта у нам уже имеется (если нет, то нужно выполнить пункт 3).
В проводнике в контекстном меню локальной папки репозитория выбираем Git Sync - затем Pull (будут загружены последние версии файлов репозитория):

Ждем, когда загрузятся изменения, в итоге увидим коммиты, сделанные другими программистами, затем нажимаем Close (новые версии уже будут лежать в локальной папке).
7. Создание своего репозитория для новой задачи (пример в сервисе VSTS)
Если потребовалось создать репозиторий под новый проект, то делаем следующие действия.
На сайте облачного хранилища создаем новый репозитарий - New repository:

Указываем наименование (желательно на латинице, т.к. оно используется в URL) и соглашаемся с созданием README файла:

Далее подключаемся к нему, как написано в пункте 3, и располагаем там как выгруженные XML файлы 1С-решения, так и сам исходный файл.
Заключение:
Теперь в облаке можно смотреть историю изменения кода:

На данный момент у нас в этом хранилище около 50 проектов, работа с ними ведется постоянно тремя программистами при помощи методов, описанных выше. Преимущества использования git, наверное, описывать не требуется, так как все понимают для чего это нужно и чем это полезно. Даже если Вы являетесь единственным разработчиком проекта, всё равно рекомендуется использовать систему контроля версий, хотя бы для себя (всегда будет возможность откатиться на предыдущую версию в случае случайной порчи релиза, да и всегда самому интересно после push'а зайти да посмотреть, что Вы сегодня сделали и порадоваться своей работе, ну или наоборот расстроиться…). И не важно - код 1С это или любой другой код. Плюс можно дать доступ на просмотр коммитов и истории изменений кода Вашему начальству (менеджеру проектов или любому другому заинтересованному лицу), чтобы видели процесс Вашей работы наглядно (главное, чтобы не считали зарплату по количеству написанных строк кода :).
Что мне не нравится в вышеназванном сервисе (VSTS): нет подсветки кода 1С. Поэтому если Вы только начали этим заниматься, то рекомендую воспользоваться новым предложением от GitHub (про бесплатный репозиторий) и организовывать хранилище уже там, т.к. на нем подсветка 1С-кода уже присутствует.
Пример сравнения версий файла на GitHub:

Пример подсветки кода на GitHub:

Вступайте в нашу телеграмм-группу Инфостарт
git версионирование ДляЧайников начинающим коммит репозиторий
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Разработка Инструментарий разработчика Групповая разработка (Git, хранилище) Разработчик Платные (руб)
Практический курс по работе с AI-агентами для разработчиков 1С уровня middle и senior, а также тимлидов команд: от постановки задач и передачи контекста до создания расширений, интеграций, MCP-инструментов, тестов и проверки готового решения.
50000 руб.
10.09.2026 13819 124 0
DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Системный администратор Разработчик 1С 8.3 1С 8.5 Бесплатно (free)
В прошлой статье у ERP оставалось 89 отказов загрузки, у ЗУП — 19. Теперь обе конфигурации совпали с эталонами, а собранные файлы прошли круг через платформу. Развертка выделена в открытый репозиторий cf-unwrapper: библиотека на Rust и консольная утилита. Показываю результаты, объясняю границы «100%» и приглашаю к проверкам и развитию проекта.
02.11.2026 305 oyti 1
DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Практическое руководство для команд, которые хотят уйти с хранилища конфигурации на git, не переходя на новую среду разработки. Подойдёт разработчикам и тимлидам, которые настраивают командную разработку на типовых и собственных конфигурациях.
02.11.2026 597 vanya_gonchar 2
Файловый обмен (TXT, XML, DBF), FTP DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Системный администратор Разработчик 1С 8.5 Бесплатно (free)
В прошлой статье я выгрузил Бухгалтерию в XML байт в байт и спросил, на чем проверить дальше. Вы ответили: ERP, старые релизы, зарплата. Прогнал пять конфигураций, от клиента ЭДО до ERP на 120 тысяч файлов. Рассказываю, что сломалось после Бухгалтерии, почему эталону платформы нельзя верить на слово, как выгрузить одну конфигурацию в формат трех версий платформы - и почему cf-конвертер становится отдельным продуктом, Разверткой.
02.11.2026 403 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 962 oyti 20
Рефакторинг и качество кода Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
Скрипт на Python посчитал метрики 2711 общих модулей УТ 11.5: 26 модулей длиннее 10 000 строк кода. Проверила счёт на синтетических модулях и показала, где рейтинг ошибается: самый длинный модуль оказался в нём ниже девяти коротких. Для разработчиков 1С. В архиве скрипт, тесты и журналы.
1 стартмани
26.10.2026 442 Ninel_S 8
Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
Общие модули 1С вынесла в подмодуль Git и подключила к двум проектам на выгрузке «Нано-УТ» и платформе 8.3.27. Подмодуль на весь каталог CommonModules загружается; клон без --recursive даёт код 1, а забытый указатель и смена ветки молча дают базу не той версии. Переименованная процедура прошла /CheckModules при 28 вызовах. В архиве скрипты, диагностика подмодулей, тесты и журналы.
1 стартмани
26.10.2026 425 Ninel_S 0
Всё работает в обе стороны, т.е. можно как выгрузить конфигурацию в репозиторий, так и загрузить в обычном виде из оного. Огромный минус всего этого действа - скорость. В файлы конфигурация БП у меня выгружалась 20-40 минут, из файлов - и того больше. Плюс сразу в конфигурацию загрузить из файлов не получится, надо в промежуточную, откуда выгружается цфник и уже он накатывается.
.
Правда сразу надо ставить .
И дальше поехали:
opm install precommit1c
в репозитории
precommit1c --install
а потом перед коммитом
precommit1c --git-precommit
Если сравнить историю развития двух проектов, то мне ваши слова кажутся крайне сомнительными:
Касательно выгрузки: Используйте хранилище 1С в связке с
Смотрел на релизы Евгения Сосны - там 2014 год. Поэтому сделал такие выводы.
Поправлю вашу первую ссылочку
Какое отношение к внешним обработкам/отчетам?
Использую git под linux в Visual Studio Code, и в проекте я вижу количество изменений на панели (см. скрин). А вот под Windows как не пытался, пишет система управления версиями не зарегистрирована, хотя git стоит и в консоли все работает.
В описанной здесь схеме в качестве преимущества прослеживается только код-ревью внешних обработок. Ну и может быть тренировка разработчиков для работы с гит, чтобы потом не сильно пугались )) Хотя первую задачу опять же лучше автоматизировать через precommit, а вторую сейчас уже лучше решать сразу через изучение EDT.
Например, php инструкции хранятся в файлах с расширением "php", а остальная объектная модель веб-сервиса в библиотеках. Почему нельзя так же и в 1С сделать?
Интересна тема EDT+Git, периодически к ней возвращаюсь, но натыкаюсь на одну и ту же проблему от версии к версии EDT:
Взяли произвольную типовую конфигурацию (я экспериментирую на ЗУП 3) относительно свежей версии (конфигурация №1).
Сняли с поддержки (в самой EDT этого не сделать или я не нашел как).
Сделали из нее в EDT проект.
Ничего не меняя в проекте, заливаем его в другую произвольную конфигурацию (конфигурация №2).
Выгружаем конфигурацию №2 в .cf
Через конфигуратор заходим в конфигурацию №1. Сравниваем/объединяем с .cf из предыдущего пункта
Результат: приличный набор "различий" в исходной/результирующей конфигурациях, чаще всего выражаемых в не совсем понятных мне вещах, как то отличиях свойства "Картинка календаря" на формах и т.п.
То есть, для корректировки типовых конфигураций EDT использовать крайне затруднительно из-за неизбежных проблем с обновлениями (получим кучу отличий там где их по факту нет).
Конечно, можно использовать EDT только для разработки собственных конфигураций, в расширениях и для внешних ПФ и обработок.
Но, к сожалению, функциональность расширений пока не позволяет полностью перейти к так нужным нам доработкам типовых конфигураций минуя изменения основной конфигурации. Хотя с каждой версией платформы ситуация меняется в нужную сторону...
Может кто-то сталкивался, решил и готов поделиться кейсиком?
По своему (небольшому пока опыту): EDT очень прожорлива на ресурсы. Поэтому использование мощных процессоров (I7, Rizen 2700?), большого количества оперативы (от 32 Гб? в том числе для организации RAM-диска для временных файлов EDT) и скоростных надежных SSD приличной емкости (от 500 Гб? современные типовые конфигурации достаточно велики при выгрузке их в файлы) крайне показано при работе с этой средой разработки.
Вообще, разработчики EDT очень много внимания уделяют оптимизации и ускорению работы своего продукта. Это радует и дает надежду, что продукт найдет широкое применение.
Но вот опять - что же делать с типовыми?((
А вот такие вещи бы подправили:
Отвечаю сам себе: нет, не добавили. Так что с EDT до сих пор работать нельзя и нельзя с ней будет работать до тех пор, пока они не синхронизируют поддержку новых платформ с их релизом.
Выгружать руками хранилище в xml - это именно то, что вы написали. У нас c этим успешно справляется gitsync. А уведомления о новых коммитах сразу попадают в отдельный канал mattermost. Клацнули на сообщение, перекинуло в локальный gitlab. Посмотрели, откомментировали по желанию, поставили отметку о ревью в mattermost. Таким вот нехитрым образом у нас участники группы учатся друг у друга, и всегда в курсе того, что творится в коде вне зоны их личных задач.
У меня просто ревью моего кода делать некому, а последний мой эпик фэйл был в том, что я вместо зипа завернул архив 7-зипом, служба поддержки пережила 50 телефонных звонков...
Основная проблема с обычными формами в том, что кривовато разбирается сама форма.
Причем форма переразбирается при каждом коммите.
В приложенном скриншоте пример, полученный при использовании precommit1c.
Так что с выгрузкой из конфигуратора будет тоже самое.
Для редактирования файлов выгруженных можно использовать visual studio code.
Там сейчас есть дополнения, чтобы 1С-код раскрасить и т.п.
Добрый день, а можно эту команду как то программно выполнить? Допустим сделали какое то изменение во внешней обработке, загрузили его в справочник "ВнешниеОбработки" и он при записи сразу же и выгрузился в репозиторий, а нам осталось только закоммитить?
Прочитал на курс1срф, что там можно через пакетный режим запускать конфигуратор для выгрузки. Вот думаю, если создадим батник и программно его запускать каждый раз при изменении, не будем ли нагружать систему и если у нас уже запущен будет конфигуратор сработает ли пакетный режим?
Т.к. git был хоть как-то "на слуху", а про названные Вами альтернативы я слышу практически впервые от Вас же, то ответ на вопрос очевиден ;)
Допустим есть обработка 1 и она лежит в каком-то общем репо на майкрософте.
Разработчику 1 нужно ее допилить (кто-то ему такой тикет поставил), он идет в репо и клонирует себе. У себя задачу решает и потом что? Он сдает ее в главный репо через пул реквест? Если да, то кто-то его проверяет? Или он сам себя апрувит?
Рейтинг: 1081
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1030323
Создание 28.03.19 23:10
Обновление 16.08.19 09:27
Просмотры 46083
Загрузки 0
Рейтинг
261
Комментарии 90
Код открыт Да
Рубрики Групповая разработка (Git, хранилище)
Кому
Разработчик
,
Стажер
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)