Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою «копию» проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

Часть 1. Как подключиться к команде разработки и начать использовать Git (эта статья)

Часть 2. Реализация Git workflow в 1С-разработке по шагам

 

 Содержание

Часть 3. Создание собственного проекта на пустом месте (План выхода: январь 2024)

Часть next [Предлагайте в комментариях другие темы для новых статей].

Предисловие

Несмотря на то, что еще в 2024 году в версии платформы 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. Очень вероятно, что такой аккаунт у вас уже есть, поэтому данная часть инструкции сделана опционально. Если нет — выбирайте, что вам больше по душе:

 

GitHub

 

GitLab

 

BitBucket

Установка Git

Установка Git описана для версии 2.18.0. Процесс установки и внешний вид окон для более поздних версий может немного отличаться. Запускаем скачанный с официального сайта проекта файл установки (скачать…).

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

 

 Про Git GUI Here и Git Bash Here

На 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, готовое к работе:

 

 Как создать ключ SSH

Установка 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
eposed
Precommit1c --install

Клонирование репозитория с GitLab

.Процесс клонирования репозитория с GitLab, пожалуй, самый простой из всех, поскольку ссылка-путь и кнопка для ее копирования находятся непосредственно на главной странице проекта. Поэтому просто копируем этот путь и далее повторяем шаги, описанные в разделе "Клонирование репозитория в SourceTree".

Форкаем интересные проекты на GitHub

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

На странице интересующего проекта нажимаем кнопку fork, дожидаемся появления нового репозитория в своём аккаунте и далее выполняем его клонирования согласно описанию в разделах "Установка Precommit1C" и "Клонирование репозитория в SourceTree".

Заключение

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

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

72 Comments

  1. Lok`Tar

    Круто, плюс однозначно, спасибо за информацию

    Reply
  2. int18h

    «Меня часто спрашивают… с хранилища на использование системы контроля версий (СКВ)? Отвечаю на первую часть вопроса. …»

    тут нужно остановиться и воспроизвести слово «зачем»

    зачем тонна софта в инфраструктуре по типу карточного домика и для каких задач?

    Я бы понял если нужно разгребать тучу коммитов и форков драйвера или утилиты для Linux (для чего собсто git и делался),

    а в 1С зачем? Устраивать самому себе стрельбу в ногу — когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул, а ты такой полдня в поиске проблемы вместо нажатия на кнопку «Поместить в хранилище»?

    Да ну подождите вы EDT

    Reply
  3. DPotapov90

    Крутота. Давно хотел поковырять Git, после прочтения руки зачесались еще сильнее. Спасибо, жду продолжения 🙂

    Reply
  4. herfis

    В части стартового пинка одинэсников в сторону СКВ все очень круто. Толково написано, все по делу, очень емко и информативно — пять с плюсом короче.

    Много вопросов за кадром, но вероятно они будут освещены в следующих статьях.

    Но один все же меня мучает: «Использования Visual Studio Code в качестве основного инструмента при работе с Git-проектом в 1С» — это как? Хоть в двух словах? Как, например, быть с созданием и редактированием форм в «основном инструменте»?

    Reply
  5. gradi

    (4) Хороший вопрос, самому интересно зачем нужен VSCode в работе с 1С. Сам активно использую Git в своих проектах. Как-то обхожусь без студии и о-скрипт.

    Reply
  6. Захаров_Николай

    (2) Что-то не жду я уже EDT.

    (5) VSCode нужен для написания скриптов OScript и для Gerkin.

    «Зачем?» — статья только основание дальше станет понятно.

    Reply
  7. DoctorRoza

    Да, это реально круто! Жду остальных статей!

    Reply
  8. 🅵🅾️🆇

    Отличная серия статей намечается.

    Гитом активно пользуюсь, но все руки никак не доходили настроить настроить разбор обработок на исходный код, так и храню бинарниками.

    Было бы здорово, если бы 1с добавила в конфигуратор кнопочку для выгрузки в git (EDT очень не нравится).

    Ну а пока, видимо, придется заморочиться и разобраться с Precommit1C

    Reply
  9. gradi

    (6) до написания скриптов я как-то не добрался. Если честно, пока не нашел где их применить.

    Reply
  10. t.v.s.

    (8) Эта кнопочка называется «Выгрузить конфигурацию в файлы»

    Reply
  11. 🅵🅾️🆇

    (5) Насколько наблюдал за чужим опытом на инфостарте.

    VSCode используют в двух сценариях:

    1) В паре с OneScript

    2) Когда вы выгрузили свою конфигурацию в git разобрав её на исходный код — для поиска нужной вам информации. Тк поиск в самом конфигураторе может быть несколько продолжительным.

    Reply
  12. t.v.s.

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

    Reply
  13. 🅵🅾️🆇

    (10) Так и как мне выгружать ей обработки в автоматическом режиме?

    Разобрать обработку сейчас можно очень большим количеством способов.

    Но так чтоб из коробки, одной кнопкой из ide и без гемороя — таких я не знаю.

    Reply
  14. gradi

    (12) Согласен. Я одну проблему решил только через выгруженные в xml файлы. Решения через конфигуратор я так и не нашел.

    Reply
  15. t.v.s.

    (13)

    Ключи командной строки вам в помощь.

    /DumpExternalDataProcessorOrReportToFiles — разбирает обработку на исходники

    /LoadExternalDataProcessorOrReportFromFiles — собирает из исходников

    Reply
  16. 🅵🅾️🆇

    (15) Вы, кажется, меня не понимаете.

    Я не утверждаю, что невозможно положить исходники обработки в git.

    Утверждать подобное было бы вдвойне глупо в комментариях такой статьи.

    Судя по всему все сведется к попытке подружить precommit1C с gitKraken.

    Просто руки до сих пор не дошли.

    Я говорю об отсутсвии «пердолинга»:

    Reply
  17. ImHunter

    (8) Особой заморочки с precommit вроде и нет.

    Как было написано в статье, скопировать его файлы в каталог хуков. И все на этом.

    Потом держать открытым SourceTree и время от времени делать commit (и пуш может быть).

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

    Reply
  18. 🅵🅾️🆇

    (17) Ага, именно так я и планировал поступить очень давно.

    Только вместо SourceTree (нет под линь, а я какт предпочитаю инструменты которые есть и под пингвина и под форточку) использую GitKraken

    Нужно было придумать некий git hook (как написано в статье) который перед коммитом будет разбирать обработки.

    Эта статья вышла очень кстати и вероятно поможет наконец сделать то, что стоило сделать давным-давно.

    Reply
  19. Darklight

    Хорошая статья, не хватает только сравнения разных git-серверов (хостингов), в чем плюсы минусы, какие особенности у тех и у других. И ещё, хорошо бы уделить внимание не только к подключению к существующим проектам, но о создании собственных проектов и репозиториев (с уже имеющимися локальными исходниками).

    Reply
  20. int18h

    (15) Да не нужно чтоб разбирало ВСЮ обработку/конфигу… Нужен инструмент, чтоб только изменения в тексты пихало прям из конфигуратора 1С, а лучше вообще сразу их в git коммитила.

    Reply
  21. 🅵🅾️🆇

    (19)

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

    Все что есть, реализует git, по сути это как сравнивать одноклассники с вк, вроде интерфейс разных цветов, а суть одна и таже.

    GitLab вы можете поднять на локальном сервере. GitHub довольно популярен для публичных репозиториев.

    Если хотите практически бесплатно и большой любитель похардкодить приватные данные — используйте GitLab.

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

    Самый простой способ:

    1) Создаете новый репозиторий прям через web интерфейс

    2) Клонируете его к себе на диск

    3) Закидываете свои локальные данные в появившуюся папку, коммитите (git commit -m «first push»)

    4) Толкаете (git push)

    Reply
  22. Vladimir Litvinenko

    Классная статья, с нее начинал работу с этими инструментами. Хорошо, что теперь есть и на Инфостарте.

    Пара моментов. Функционал 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С.

    Reply
  23. CSiER

    https://learngitbranching.js.org — интерактивный учебник по git — отлично подходит для ознакомления с основными возможностями.

    Reply
  24. herfis

    (22)

    Очень интересно было бы прочитать про разработку Конфигуратор 1С + Git без хранилища , если у Вас есть такой опыт.

    Меня наоборот, очень интересуют реальные схемы работы Git + Хранилище. Чтобы рабочая база не из гита напрямую собиралась, а чтобы релизы через хранилище шли. Общая схема вроде понятна, но про реальные наработки было бы интересно послушать.

    Reply
  25. AntonSm

    (24) Поясните, какую схему вы хотите получить в итоге. Может удастся что-то подсказать дельное.

    Где будут разработчики? В гите или хранилище?

    Reply
  26. herfis

    (25) Я же сказал вроде. Разработчики в гите, а релизы в рабочую — через хранилище.

    ЗЫ. Я вообще не понимаю, как люди на самом деле работают. Неужели все продакшн напрямую из гита заливают?

    Reply
  27. AntonSm

    (26)

    Я же сказал вроде. Разработчики в гите, а релизы в рабочую — через хранилище.

    Цитата отсюда:

    https://xdd.silverbulleters.org/t/izmenyaetsya-configdumpinfo-xml-pri-kompilyaczii-cf/2271/5

    собрать cf, захватить все объекты, объединить с cf через MergeConfig.xml, выполнить коммит. все через пакетный запуск конфигуратора или v8runner или vanessa-runner

    Т.е. из гита собрать cf, cf в хранилище, из хранилища в рабочую. Вроде всё реально.

    Вот vanessa-runner.

    Reply
  28. herfis

    (27) Сам знаю, что вроде все реально 🙂 Интересует боевой опыт бывалых офицеров 🙂

    объединить с cf через MergeConfig.xml

    Что-то этот пункт мне не сильно нравится. Почему не собирать штатно напрямую в конфу с подключенным хранилищем и захваченными объектами?

    Судя по всему, при подключенном хранилище это сделать не получится… Тогда понятно.

    Reply
  29. paybaseme

    Спасибо за статью! Надеюсь, как 1сник далекий от гитов и едт’ов, что в следующих статья будут практические кейсы, когда гиты помогают, а хранилище или не умет, или не тянет, или еще что. Чтобы можно было как-то оценить, что да — хранилище в этом случае фигня, а гиты — торт!

    Я пока сижу в хранилищах, и не шибко понимаю, вот эти все описанные в итоге в статье, действия, они по итогу — какое существенное преимущество дают, относительно того же хранилища. Читал ресурс по едт от 1С, типа объект могут править сразу несколько человек и на этапе мерджа, или как-то так, можно типа разрулить все круто. Но опять же, я пока не столкнулся с этими проблемами.

    Может кто из коллег подскажет уже сейчас, когда есть смысл в практической работы переезжать с хранилищ на эти гиты, деплойки, какие-то в раннеры и все что в статье и комментах описано?

    Reply
  30. 🅵🅾️🆇

    (29)

    Если сравнить возможности git и хранилища конфигурации 1С, то для git можно выделить ряд полезных особенностей:

    git — распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.

    git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.

    Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая «git flow».

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

    Reply
  31. GreenDragon

    (2) Они запилят в EDT поддержку обычных форм? Нет? Чего тогда мне и сотням тысяч других разработчиков ждать?

    Reply
  32. nayd

    (26)


    ЗЫ. Я вообще не понимаю, как люди на самом деле работают. Неужели все продакшн

    Я релизы делаю из хранилища.

    Для подготовки файлов поставки есть отдельная файловая база (1С:ERP), напрямую неподключенная к хранилищу. Когда нужно выпустить релиз, в командной строке выполняю следующую команду:

    deployka loadrepo /FD:1C_Dataerp_delivery D:1C_Storageerp -storage-user Администратор -v8version 8.3.10

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

    Спрашивайте, если что-то осталось непонятно.

    Reply
  33. kuzyara

    (5)

    зачем нужен VSCode в работе с 1С

    сценарии gherkin

    Reply
  34. kuzyara

    Замечательный step-by-step guide! Когда-то сам хотел написать такое 😉

    Reply
  35. ipoloskov

    (31) ждать, очевидно, естественной смерти УПП и иже с ними. Я тоже жду.

    Reply
  36. triviumfan

    Сотая тема.

    Reply
  37. Ovkay

    Спасибо за отличную подробную статью!

    Reply
  38. GreenDragon

    (35) А это тут при чём? Не совсем понял мысль

    Reply
  39. ipoloskov

    (38) отомрет УПП — и необходимость поддержки обычных форм исчезнет.

    Reply
  40. stas_ganiev

    (2) никто не утверждает, что описанная метода — панацея. Нравится хранилище и кажется более надежным? — пожалуйста, никто по рукам бить не будет.

    Но лично я ощутил на себе и своих разработчиках массу плюсов в использовании Git, поэтому и родилась идея этой серии статей.

    Куча софта? Да не такая уж и куча, если учесть, какой кучей вы уже пользуетесь. Просто для вас это стало естественным. Пройдёт совсем немного времени, и так же естественно будет открыть VS Code для редактирования модуля.

    Глюки? Бугага! За два года ни разу ничего не глюкануло! А вот хранилище глючит с завидной регулярностью. И приходится сидеть ждать, пока админы что-то починят на серверах и роутерах, пока можно будет снова захватить или поместить объект. А это время, а это деньги.

    Reply
  41. stas_ganiev

    (9) У вас ещё всё впереди))

    Reply
  42. stas_ganiev

    (4) возможно, погорячился с заголовком. Формы — пока никак, хотя знаю, что в некоторых кругах работы над этим ведутся. Подумаю над корректировкой, спасибо за замечание.

    Reply
  43. stas_ganiev

    (11)

    (12)

    (14)

    (33) Всем спасибо, добавить нечего ))

    Reply
  44. stas_ganiev

    (16) Precommit — это хук, и не зависит от используемой среды, работает напрямую с Git. Хоть gitKrsken, хоть cmd — велкам!

    Reply
  45. stas_ganiev

    (20) По результату так и получается — коммитятся только изменения

    Reply
  46. stas_ganiev

    (19) Мысль о сравнительном анализе была, но быстро отпала. Так же как нет смысла сравнивать разные GUI. Тут на вкус и цвет…

    А эта тема будет освещена в третьей части.

    Reply
  47. stas_ganiev

    (22) Как написано в самой статье, я не ставлю цель рассматривать бест-практики, моя задача — расширить аудиторию пользователей Git. Но за мысли и идеи спасибо, подумаю над дальнейшим развитием тем.

    Reply
  48. stas_ganiev

    (29) смотрите мой ответ к первому комментарию и ждите следующих статей ))

    Reply
  49. GreenDragon

    (39) Когда отомрёт УПП, наша организация перестанет использовать УТ 10.3? Не совсем понял ход мысли. Конкретно в нашей организации используется git + precommit. Основная конфигурация на базе сильно переписанной УТ 10.3

    Что у нас должно поменяться со смертью УПП и для чего нам EDT?

    Reply
  50. ArchLord42
    когда надо сдать подсистему а у тебя отвалилось что-то вроде v8Reader или v8files-extractor.os глюкнул

    Да ну подождите вы EDT

    тем временем в комментах с новостями про EDT люди пишут.

    «зачем нам EDT, вдруг он у нас отвалится и мы не сможем сдать подсистему»

    Я заметил, что 1Сники очень консервативные люди и очень сильно боятся чего-то нового, постоянно аргументируя тем, что все атвалицтся и они бедненькие не успеют чего-то там, при этом то же хранилище, скажем так, немного не стабильно порой, да в принципе все кто связан с 1С уже привыкли страдать

    Юзеры, которые уже давно не удевляются тому, что «1С глючит», разработчики, которые ходят по отделам и спрашивают, «а кто это написал» и тд.

    Собственно хайп вокруг git + 1C возник именно на этой почве, людям и бизнесу в целом надоело страдать в то время, когда коллеги из других направлений разворачивают «гиты», «сиай», пишут тесты и крепко спят по ночам, при этом еще и на выходных отдыхают.

    Есть конечно 1 кейс, при котором git скорее будет излишним усложнением:

    Количество разработчиков ~1 и в вашей компании баги и простои 1С не сильно сказываются на работоспособности бизнеса, если это так, то тут действительно git возможно не нужен, хотя даже при таком раскладе, версионировать обработки ВПФ и тд без гита в принципе сложно сейчас.

    Reply
  51. Dementor

    Прошу автора более полно раскрыть идею использования (упомянутого им чуть ли не как мастхэв) VS Code. Так как это не очевидно (комментарии других это подтверждают).

    По чисто субъективной оценке взятой с потолка 95% коллективной работы программистов 1С сводится к изменению структуры метаданных, доработке форм и макетов (в первую очередь СКД, но и обычных печатных форм тоже море). Как тут может помочь этот умный блокнот? Пара комментаторов заметила, что там скорость текстового поиска выше, но лично для меня во всех рабочих конфигурациях это не является проблемой (с ERP не работал — возможно там поиск действительно долгий особенно без SSD-диска и с маленькой оперативкой).

    Reply
  52. nayd

    (51) очень похоже, что статья написана по результатам прохождения курса Профессиональная разработка в 1С от Серебряной Пули (вольный пересказ).

    В курсе использовали VSCode для вспомогательных целей (не для редактирования исходников 1С): например, для подготовки настроечных файлов для вспомогательных утилит тестирования, подготовки поставок, написания пайплайн-файлов для дженкинса и чего-то еще.

    Reply
  53. 🅵🅾️🆇

    (0)

    У кого не регистрируется в переменной пути onescript делаем следующее:

    Reply
  54. 🅵🅾️🆇

    (46) Если что, установка gitlab’а на домашнем/рабочем сервере крайне проста, только он из коробки жрет очень много.

    Можете сразу списывать 4 гига оперативы. Но мне не жалко, ведь жаба давит ежемесячно платить гитхабу 7$ за приватных репозиториев (а мне нужно больше) С:

    Reply
  55. nvv1970

    (40) вывод: плохие админы мотивировали перейти на git))

    У нас сотни хранилищ по http, централизованно, по интернету. За много лет нигде ничего не отвалилось.

    Reply
  56. webvolunteer

    Подскажите, пожалуйста, как отключить данные всплывающие окна при прекоммите ?

    Reply
  57. webvolunteer

    (56) Нашла, нужно в файле conf.cfg который лежит в каталоге установки 1С, например C:Program Files1cv8conf

    добавить строчку

    DisableUnsafeActionProtection=.*;

    Здесь «.*» — регулярка, определяющая имена баз, для которых проверка отключена

    Reply
  58. manuzin

    Добрый день, когда планируете продолжение банкета? 🙂 Последующие части будут?) Спасибо за материал.

    Reply
  59. Makushimo

    Скажите сразу, вы в следующих статьях расскажете о практической стороне (step-by-step) как выполнять слияния в git вручную и в EDT?

    Нигде в подобных статьях или циклах статей я не нашел ответа на этот вопрос.

    Три ветки maste, release, develop. от develop на задачу делаем ветку, потом сливаем ветку задачи с develop.

    Слияние — как его делать? Ведь код модуля это далеко не все, что есть в разработке на 1С. То есть мы текстовые файлы конфигурации вручную объединяем или все таки cf сравнением-объединением вливаем в develop? может EDT умеет это делать из коробки и понятно и наглядно?

    Затем, когда из develop в release сливаем тоже — как? и затем в master.

    Сидит специально обученный человек с квадратной головой, который все конфликты и мержи разрешает?

    Делается ли сборка cf из файлов конфигурации или файлы отдельно для комментариев и Jira. а cf отдельно для нормального объединения изменений?

    Эти вопросы все гуры по git как-то обходят стороной, а именно они не дают принять решение о переходе на трушные технологии разработки.

    Reply
  60. palsergeich

    (55) Гит позволяет очень быстро ответить на вопрос — кто и когда добавил эту строчку кода. git-blame

    После одного случая, где для поиска автора и породившей изменение задачи потребовалось более 6 ти часов, для меня это стало очень большим преимуществом.

    С хранилищем — при большой истории изменения объекта — печаль и боль.

    Reply
  61. nvv1970

    (60) в этой части — полностью с вами согласен.

    Я бы и без мотивации перешел, но не с кем ((((

    Reply
  62. AntonSm

    (60) gitsync позволяет и при работе в хранилище получить эту фичу.

    gitsync

    Reply
  63. stas_ganiev

    (51) VS Code — вовсе не must-have, прошу прощения, если после прочтения у кого-то сложилось такое впечатление.

    О причинах его использования уже не раз было написано тут же в комментах.

    Reply
  64. stas_ganiev

    (52) Отнюдь, уважаемый! Курс я не проходил, более того — намеренно избегаю знакомства с ним, дабы не прослыть плагиатом. Тут, как говорится, все совпадения — случайны :)))

    Reply
  65. stas_ganiev

    (58) Спасибо за отзыв! Работа над второй частью идёт полным ходом, наберитесь немного терпения.

    Reply
  66. caponid
    Часть 2. Реализация Git workflow в 1С-разработке по шагам (План выхода: 10.12.2018)

    ждем…

    Reply
  67. Viktor_Ermakov

    уже 17.12.2018 г. а второй части все нет!)))

    Ждемс..)

    Reply
  68. stas_ganiev

    (66)

    (67)

    Новая часть выйдет по занавес года ))

    Reply
  69. stas_ganiev

    (59)

    Этой теме внимание будет уделено совершенно точно, но не обещаю, что результат будет таким, каким его ожидаете именно вы )) В частности, EDT пока не планирую рассматривать.

    Reply
  70. AlexPC

    Помогите с precommit1c и v8reader: при выгрузке внешнего отчета в исходные файлы почему-то не выгружается управляемая форма отчета в виде xml-файла, только код модуля формы.

    Reply
  71. user1162167

    Основные Git команды. Можно использовать как шпаргалку:

    Рекомендую к прочтению: https://use-web.ru/news.php?id=138&tid=3

    Reply
  72. 1cProfit

    Уже 26.07.2019 а третьей части все нет !…

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *