Git и 1с как работать

Обновлено: 22.01.2025

1С:ГитКонвертер

Конфигурация предназначена для односторонней синхронизации хранилища конфигурации "1С:Предприятия" с репозиторием Git и последующим переходом на разработку в 1C:Enterprise Development Tools (1C:EDT) с сохранением истории.

Основные возможности

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

Выгружать только изменения конфигурации.

Доступно для Платформы 8.3.10 и выше, для версий ниже 8.3.15 требуется использовать "очереди".

Поддержка конвертации хранилищ расширений конфигураций. Возможность связи с базовым проектом 1С:ГитКонвертера или независимо.

Необходимые компоненты

Конфигурацию можно запустить, используя 1C:Enterprise Development Tools 2020.6 (https://releases.1c.ru/project/DevelopmentTools10)
Платформа "1С:Предприятие" версии 8.3.12 и выше (https://releases.1c.ru/project/Platform83)
СУБД, поддерживаемая "1С:Предприятием"
OS Windows 7 или выше, ОС Linux и macOS - в бета-режиме.

Начальная настройка

Настройка базы ГитКонвертера

Настройка сервера "1С:Предприятия"

Для информационной базы ГитКонвертера на сервере "1С:Предприятия" рекомендуется настроить удаление, перенос в архив или полностью отключить журнал регистрации, т.к. интенсивность событий в информационной базе может быть очень высокой, а ценность истории журнала регистрации за прошлые периоды - низкая.

Для легкого удаления и архивирования журнала регистрации можно переключить его формат на старый режим. Для этого необходимо в каталог журнала регистрации информационной базы скопировать пустой файл с именем: 1Cv8.lgf .
Для больших проектов рекомендуется выполнить такую настройку (удаление/резервное копирование файлов журнала регистрации).

Также рекомендуется переключить регистрацию событий - только ошибки. Для этого следует выбрать команду в Конфигураторе Администрирование - Настройка журнала регистрации. = Регистрировать ошибки и в открывшемся диалоге установить минимально необходимую вам периодичность.

Настройка конвертации хранилища "1С:Предприятия"

Рекомендуется использовать сервер хранилищ конфигураций "1С:Предприятия".

Для оптимальной работы сервера хранилищ настройте Размер глобального кэша в "Администрировании" в 1,5-2 раза больше количества параллельных потоков (если используются "копии хранилища") получения версий * размер одной версии, Мб .

Параметры конвертации

Дополнительная настройка репозитория Git

По умолчанию создается файл исключений .gitignore , в который добавляются файлы DumpFilesIndex.txt и ConfigDumpInfo.xml - не требуемые для работы с исходными файлами конфигурации "1С:Предприятия".

Если репозиторий был создан с помощью кнопки в карточке хранилища, в локальный конфиг репозитория добавляются настройки для более комфортной работы:

Символы окончания строк

Если разработчики, работающие с репозиторием, используют разные операционные системы (Microsoft Windows, Linux, macOS), нужно настроить конвертацию символов окончания строк при чтении из репозитория. Следующие команды настраивают Git таким образом, что в рабочей копии разработчика будут использоваться "родные" для его операционной системы символы, а в репозитории всегда будет использоваться LF.

Для операционной системы Microsoft Windows:

git config --global core.autocrlf true
git config --global core.safecrlf true

Для операционных систем Linux и macOS:

git config --global core.autocrlf input
git config --global core.safecrlf true

Git LFS

Если используется сервер репозиториев Git, необходимо убедиться, что он поддерживает это расширение и включить настройки для проекта. Например, GitLab, GitHub, BitBucket - поддерживают.

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

git lfs install

Включить отслеживание бинарных файлов конфигурации:

git lfs track "*.cf"
git lfs track "*.bin"
git lfs track "*.jpg"
git lfs track "*.jpg"
git lfs track "*.bmp"
git lfs track "*.jpg"
git lfs track "*.zip"

В этом примере - все файлы конфигураций поставщиков, файлы макетов с "Двоичными данными" и картинки из конфигурации попадут в lfs.

Например, чтобы переносить в LFS только некоторые типы файлов с расширением "*.bin" можно включить отслеживание только шаблонов и модулей без исходного кода по маске:

git lfs track "*/Ext/Template.bin"
git lfs track "*/Ext/Module.bin"

Копии хранилища

Копии хранилища используются для ускорения получения версий из хранилища.

Можно использовать тот же адрес серверного хранилища конфигураций, но с разными пользователями. Количество "копий" влияет на размер создаваемого глобального кэша версий на сервере хранилища "1С:Предприятия". Желательно установить кэш в настройках сервера хранилищ "1С:Предприятия" в полтора раза больше, чем количество копий в ГитКонвертере.

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

Укажите расписание получения версий из этой копии. Если в "копии" указан адрес основного хранилища, необходимо в расписании учесть возможность работы разработчиков с хранилищем - запуски на получение выполнять с промежутками, обеспечивающими комфортную работу разработчиков.

Очереди выполнения

Если включена константа "Использовать очереди выполнения", то для каждого хранилища конфигураций необходимо указать 2 очереди:

Выгрузка метаданных . Начиная с версии Платформы версии 8.3.10 возможно использовать выгрузку изменений - для этого необходимо выгружать версии строго последовательно и не рекомендуется создавать более одной очереди на выгрузку.
Загрузка метаданных .

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

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

Очередь может быть общей на всю базу или привязанной к конкретному хранилищу. Для очереди общего типа выбор версий для обработки выполняется по дате версии - это следует учитывать при конвертации проектов с длинной историей и более "молодых" проектов в одной базе ГитКонвертера.

Информация пользователей

Хранилище конфигураций "1С:Предприятия" использует для идентификации Пользователя , а в репозитории Git основным идентификатором является email и имя пользователя. Для этих целей предназначен регистр сведений Информация пользователей , позволяющий указать соответствие пользователей хранилищ пользователям репозитория Git.

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

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

Обновление с версии 1.0.4

Внимание! Конвертация хранилища 1С в формат выгрузки xml 1С:Предприятия является устаревшей функциональностью и не доступна для новых настроек конвертации хранилища. Текущие настройки синхронизации хранилища, конвертирующие в формат выгрузки xml 1С:Предприятия будут работать корректно, но рекомендуется выполнить разовую конвертацию в формат 1C:EDT (см. тут) и продолжить синхронизацию в этом формате.

Функциональность конвертирования в формат xml 1С:Предприятия будет удалена в 1.0.6 .

Если что-то пошло не так (FAQ)

Расписание конвертации включено, но список версий пуст

Проверьте, что задана константа "Путь к версиям платформы на сервере" и в настройках хранилища указана версия, соответствующая версии сервера хранилища конфигураций "1С:Предприятия".
Проверьте файл логов log.txt в каталоге выгрузок - там может быть написано что-то вразумительное.
Проверьте журнал регистрации базы 1С:ГитКонвертера - на наличие ошибок.

Версии в списке ИБ 1С:ГитКонвертера есть, но конкретная версия зависла (зациклилась) на этапе выгрузки конфигурации в xml

Можно посмотреть в лог пакетной операции для этой версии /каталог выгрузки версий/ХХХ/log.txt - пакетная операция Конфигуратора может сообщить что-то полезное.
Если база версии "развалилась" в контекстном меню формы списка версий сбросить состояние версии - она будет получена заново из хранилища.

Версии обрабатываются, но не коммитятся в Git

Коммиты не появляются на сервере Git

Адрес Git-сервера был добавлен после создания хранилища? Нужно нажать кнопку "Установить адрес репозитория Git" чтобы настройки появились в config-файле.
Откройте гит-клиент - проверьте, есть ли коммиты в локальном репозитории.
Посмотрите лог коммита на Git-сервер, расположенные /каталог выгрузки версий/gi_log_ver_XXX.txt.
Выполните команду git push -u origin <branch name> в консоли, чтобы проверить push вручную.
Проверьте права доступа для пользователя, от имени которого запущен сервер "1С:Предприятия" - от его имени выполняется запуск скриптов *.bat/*.sh и глобальные настройки Git для этого пользователя.

В какой-то версии произошел сбой и файлы версии закоммичены не полностью

Т.е. в этой версии часть файлов или все были сначала удалены в репозитории, а следующая версия добавила файлы заново - сквозная история была потеряна:

Можно установить контроль минимального количества файлов в выгрузке, чтобы такого не случалось в будущем.
Т.к. это "односторонняя синхронизация" - то можно беспрепятственно откатить изменения git reset --hard <commit> на версию, до проблемной.
- Далее в карточке хранилища установить поле "Версия в Git" на текущую в Git.
- Для всех версий, начиная с "проблемной" и последующих, выполнить команду в контекстном меню "Сбросить состояние".
- В каталоге src удалить файлы DumpFilesIndex.txt и ConfigDumpInfo.xml, т.к. они не хранятся в репозитории и не откатились.
- Проверить что командные файлы *.bat (или *.sh ) удалены для всех версий, начиная с проблемной.
- Если была установлена настройка Git-сервера, необходимо на сервере отключить защиту ветки (если есть такое) и выполнить git push -u -f origin <branch name> принудительную передачу данных с заменой репозитория на сервере.
В хранилище версия есть, а в Git она пропущена
- Хранилище конфигураций "1С:Предприятия" позволяет сохранять новую версию без фактического изменения содержимого файлов, если меняется внутренняя версия объекта метаданных. Для Git в этом случае нечего коммитить.
- Откройте файлы логов и убедитесь в том, что версия была обработана корректно.
Файл конфигурации GitConverter находится в каталоге \1CITS\EXE\GitConverter

В 1С для хранения кода, его истории и ведения совместной работы используется хранилище конфигурации. Для других языков программирования тоже используются системы управления версиями кода. На данный момент одной из наиболее распространенных систем управления версиями является git. Историю git можно также узнать в сети, но, думаю, достаточно будет сказать, что на данный момент разработка ядра Linux ведётся при помощи этой системы, чтобы убедить: git - это серьёзно.

Если сравнить возможности git и хранилища конфигурации 1С, то для git можно выделить ряд полезных особенностей:
1. git -- распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.
2. git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.
3. Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая "git flow".
4. Хранение любой информации. В отличие от хранилища 1С, в git можно хранить любую информацию (желательно текстовую, но это не обязательно). Поэтому при использовании git возникает возможность хранить не только конфигурацию, но и все внешние отчеты, обработки и другую сопутствующую информацию.
Возникает вопрос, а можно ли при текущем варианте разработки, без использования EDT, использовать git? Ответ на этот вопрос: "да".

В этой статье я не буду касаться вопросов установки git, его использования и других широко освещенных в сети тем. Будем считать, что базовые знания по работе с git у вас уже есть и вы умеете пользоваться github'ом, а также умеете устанавливать программы на компьютер, создавать службы и выполнять другие административные операции.

Git & 1С

Для начала зафиксируем стандартный процесс разработки решений для платформы 1С:Предприятие:
1. Разработка ведётся коллективом разработчиков при помощи конфигуратора;
2. В качестве системы управления версиями используется хранилище конфигурации;
3. При доработке кода, в коде, как правило, оставляются комментарии с информацией, кто, когда и почему изменил код. При этом прокомментировать таким образом изменения в формах или макетах вообще не представляется возможным.
4. Управление внешними обработками осуществляется вручную, а сами обработки хранятся в файловой системе. Получить предыдущие версии обработок, скажем для старых версий продукта, зачастую, если такая возможность заранее не была предусмотрена процессом, невозможно.
Разумеется, таким образом процесс разработки организован не у всех, но это наиболее распространённая схема совместной работы.

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

Итак, что мы можем получить от использования git в проекте разработки продукта на основе 1С:Предприятие?

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

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

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

Давайте определим, каким должен быть процесс разработки, исключим из существующего процесса лишние элементы, а какие-то элементы изменим и, возможно, введём новые.
1. Разработка должна вестись в конфигураторе, как и раньше.
2. Если возможно, вести разработку без хранилища конфигурации, ведь ему на замену мы решаем ввести git. Забегая вперёд скажу: это, к сожалению, сделать будет нельзя, по крайней мере, без существенного усложнения процесса разработки, но ведь мы добиваемся обратного -- его упрощения!
3. Отсутствие необходимости комментировать изменения кода в самом коде. Описание изменений хранить отдельно от кода. По правде сказать, это можно делать и сейчас, заполняя комментарий версии при помещении объектов в хранилище конфигурации, однако в текущем виде комментарии могут дать ответ на вопрос, что было изменено в текущей версии, но нет инструмента, позволившего бы ответить на вопрос, в какой версии был изменён конкретный кусок кода.
4. Внешние отчеты и обработки должны храниться вместе с кодом разрабатываемого продукта. При этом они также должны версионироваться по общим правилам версионирования кода git.
5. Документация к продукту (пользовательская и разработческая) также должна располагаться в хранилище продукта. В конечном итоге, история изменения документации также представляет интерес, как и история изменения кода продукта.
Что можно сделать уже сейчас?

"Превращение" конфигурации в исходный код. Это делается при помощи меню конфигуратора "Конфигурация/Выгрузить конфигурацию в файлы" или использования ключа запуска конфигуратора "/DumpConfigToFiles". Однако следует помнить, что при работе без хранилища конфигурации возможны одновременные изменения одних и тех же объектов несколькими разработчиками, поэтому перед выгрузкой своих изменений нужно сначала произвести их слияние с изменениями других разработчиков.

Другими словами, при изменении конфигурации необходимо:
1. выгрузить свою текущую конфигурацию в файлы;
2. собрать из текущего состояния кода продукта конфигурацию (делается также через меню конфигуратора "Конфигурация/Загрузить конфигурацию из файлов" или ключа запуска конфигуратора "/LoadConfigFromFiles");
3. выполнить получение изменений в локальный репозиторий продукта (pull);
4. произвести сравнение/объединение текущей конфигурации продукта со своими изменениями;
5. выполнить сохранение конфигурации в файлы, расположенные в локальном репозитории продукта;
6. произвести commit изменений с указанием комментария изменений;
7. выполнить push изменений в центральный репозиторий. При этом нужно быть готовым к тому, что с момента начала помещения Ваших изменений в git-репозиторий кто-то мог сделать это быстрее и при помещении изменений могут возникнуть конфликты, требующие ручного их разрешения. Для этого описанный здесь алгоритм нужно будет выполнять повторно.
Согласитесь, не самый простой способ до того так просто выполняющейся операции. Причём основную массу проблем вызывает именно асинхронные изменения кода, если их исключить, можно существенно упростить описанный процесс публикации изменений. Таким образом мы вынуждены вернуться к идее использования хранилища при разработке, к тому же у нас возникает единая точка возникновения изменений: не отдельная база разработчика, а само хранилище конфигурации. Каждое помещение изменений в хранилище и является отдельным коммитом в git-репозиторий. В результате, процесс помещения изменений в git-репозиторий существенно не изменяется:
1. разработчик помещает изменения в хранилище конфигурации;
2. производится выгрузка помещенных изменений в git.
Последний пункт не обязательно выполнять разработчику, его можно автоматизировать при помощи того же jenkins, в результате чего процесс разработки вообще останется без изменений.

Правда теперь выгрузку конфигурации придётся производить немного по-другому. Для выгрузки версии хранилища нужно сначала получить базу данных с нужной версией хранилища и затем уже выполнять её выгрузку в файлы. Для загрузки нужной версии конфигурации из хранилища используется ключ запуска конфигуратора "/ConfigurationRepositoryUpdateCfg". Выгрузку можно производить периодически или по факту изменения хранилища. При этом нужно "помнить" номер последней выгруженной версии хранилища и последовательно выгружать только те версии, которые появились после последней выгруженной.

Алгоритм выгрузки конфигурации получается следующим (я рассматриваю вариант с использованием git-сервера):
1. клонируем репозиторий продукта в пустой каталог. Это необходимо, чтобы исключить влияние локальных изменений и выгружать конфигурацию в репозиторий, содержащий все изменения;
2. определяем номер последней выгруженной версии хранилища;
3. создаём пустую базу (команда запуска "CREATEINFOBASE") и подключаем её к хранилищу (ключ запуска конфигуратора "/ConfigurationRepositoryBindCfg")
4. для каждой версии, большей, чем определённая на втором шаге, последовательно производим:
  1. обновление конфигурации на следующую версию хранилища;
  2. выгрузку конфигурации в каталог исходников в локальном git-репозитории;
  3. выполняем commit изменений с комментарием, указанном в хранилище конфигурации;
  Таким образом в git-репозитории продукта у нас окажутся все версии хранилища со всей историей. Однако в процессе выгрузки изменений нужно будет решить вопрос с авторством коммитов, т. к. исходя из целей, в git-репозитории нам важно знать, кто произвёл те или иные изменения. Коммиты необходимо выполнять от имени их авторов с указанием их e-mail'ов.
  
  gitsync
  
  Безусловно, подобный функционал может реализовать почти каждый разработчик, и было бы странно, если бы эту функцию реализовывала каждая команда разработчиков и ни одна не поделилась бы результатами: готовым решением для синхронизации хранилища конфигурации и git-репозитория.
  
  Такое решение существует, называется оно gitsync и реализовано на языке OneScript. Благодаря привычному синтаксису языка 1С:Предприятие, программы на OneScript будут понятны любому 1С-разработчику. Более того, на этом языке уже реализована масса инструментов предназначенных для автоматизации разработки на платформе 1С:Предприятие. В этой статье описаны существующие библиотеки для данного языка.
  
  Здесь я продемонстрирую, как выполнить синхронизацию хранилища с git-репозиторием.
  
  Для начала надо установить сам OneScript. Отсюда берём сам интерпретатор (в удобном для Вас виде и под Вашу платформу) и устанавливаем его в систему. Я буду демонстрировать использование на примере платформы Windows. По умолчанию OneScript устанавливается в каталог "C:\Program Files (x86)\OneScript" и в переменную "PATH" прописывается путь к каталогу исполняемых файлов OneScript "C:\Program Files (x86)\OneScript\bin". Если ы устанавливали OneScript не при помощи установщика, то вам придётся прописать путь к этому каталогу самостоятельно.
  
  Далее нужно установить gitsync (возможно он уже установлен вместе с OneScript, но в будущих версиях OneScript gitsync может быть убран из стандартной поставки). Установка библиотек и приложений OneScript, производится специальной утилитой "opm" (OneScript Package Manager, поставляется вместе с интерпретатором) из специально созданного хаба, куда разработчики помещают эти библиотеки и приложения. Разумеется, это не единственный способ устанавливать библиотеки и приложения. Их можно разработать самому или скачать из сети и сохранить в любой каталог, предварительно "сообщив" интерпретатору, что библиотеки и приложения нужно искать ещё и в нём.
  
  На всякий случай выполним обновление библиотек оскрипта (данный шаг выполнять не обязательно, если у вас уже установлены последние версии библиотек):
  
  Нужно помнить, что в большинстве случаев данные команды надо выполнять с правами администратора, т. к. обновляемые библиотеки располагаются в иерархии каталога установки OneScript, в который запрещена запись простым пользователям.
  
  После установки, gitsync доступен для запуска, т. к. скрипт запуска создаётся в каталоге исполняемых файлов OneScript. Ознакомиться с параметрами запуска gitsync можно при помощи команды
  
  Теперь нужно настроить git-репозиторий для работы с gitsync. Для этого надо создать в репозитории каталог, в котором будут храниться исходники конфигурации (примем, что это будет каталог "cf" в корне репозитория), инициализировать gitsync в данном репозитории, настроить пользователей хранилища и указать версию хранилища, начиная с которой нужно выполнять синхронизацию.
  
  В результате выполнения этой команды в каталоге "cf" создались два файла: "AUTHORS" и "VERSION". В файле "AUTHORS" указаны все пользователи хранилища, здесь надо проверить правильность указания e-mail адресов этих пользователей. Все коммиты в git-репозиторий будут производиться от имени пользователей с этими e-mail'ами. Файл "VERSION" имеет формат xml и содержит единственный узел "VERSION", в который нужно записать номер версии хранилища, начиная с которой необходимо выполнять синхронизацию. Делать это вручную не обязательно, для этого у gitsync есть команда "set-version". Выполняем
  
  где "cf": -- каталог, в котором расположен файл "VERSION", а 0: -- номер версии, начиная с которой нужно выполнять синхронизацию.
  
  К этому моменту к синхронизации всё готово. Выполняем команду
  
  и ждём. Если у вас большая конфигурация или в хранилище достаточно много версий, ждать придётся ощутимо долго, будьте к этому готовы. Однако можно разбить синхронизацию хранилища с git-репозиторием на несколько этапов, выгружая за один запуск gitsync по небольшому количеству версий, указав ему параметры "-minversion" и "-maxversion". Также при запуске gitsync следите за версией платформы 1С:Предприятие (по умолчанию будет запускаться последняя версия), указать конкретную версию можно при помощи ключа "-v8version".
  
  Всё. На данный момент в локальном git-репозитории мы имеем всю историю хранилища конфигурации и можно выполнить push в центральный репозиторий продукта на сервер, если у вас такой есть.
  
  Для упрощения коллективной работы с репозиторием продукта я настоятельно рекомендую держать этот репозиторий на каком-либо git-сервере, но помните, что не всякий продукт можно выкладывать в общедоступные репозитории, например на github, из-за лицензионных ограничений. При этом есть возможность "поднять" свой собственный git-сервер внутри локальной сети. Есть разные git-серверы с разными возможностями, лицензиями и стоимостью, я использую простой и бесплатный gogs, но, наверное, сейчас остановил бы свой выбор на gitlab.
  
  precommit1c
  
  Теперь вернёмся к вопросу версионирования внешних отчётов и обработок. В последних версиях платформы есть возможность редактирования внешних отчётов и обработок в "иерархическом XML формате". В этом случае никаких особых действий производить не требуется. Правка отчетов и обработок, находящихся в репозитории продукта производится, как обычно, в конфигураторе, после чего осуществляется коммит изменений. При этом может возникнуть конфликт изменений, когда в репозитории на сервере находится более новая версия отчета/обработки, чем та, которая была изменена разработчиком. Здесь от разработчика потребуется произвести слияние изменения или внести свои изменения повторно, после получения свежей версии отчета/обработки. Впрочем, данный подход для git является штатным и к нему нужно привыкнуть, нужно только не забывать перед началом правки чего-либо получить свежие изменения в репозитории, а после изменений осуществлять коммит этих изменений и push на сервер.
  
  Если же ваша платформа не поддерживает редактирование отчетов/обработок в "иерархическом XML формате", то можно воспользоваться специальной "утилитой" "precommit1c", которая является, по сути, набором git-"перехватчиков" (git hooks), выполняемых при какой-либо операции с репозиторием. В данном случае действия выполняются при коммите изменений в репозиторий. Для использования precommit1c необходимо его установить и настроить локальный репозиторий для работы с ним.
  
  Установка самого precommit1c на компьютер производится через opm командой
  
  Эту операцию, как уже говорилось выше, нужно выполнять с правами администратора системы. Настройка локального репозитория для работы с percommit1c выполняется командой
  
  запущенной в каталоге локального репозитория. Важно помнить, что данную операцию нужно выполнять в локальном репозитории каждого разработчика, в противном случае изменения обработки не отразятся в исходном коде этой обработки.
  
  При коммите изменённой обработки в репозитории, precommit1c производит её разбор на файлы и помещает эти файлы в каталог "src" репозитория. Например, если обработка располагалась по пути "./epf/Внешние обработки/Моя обработка.epf", то исходники будут выгружены в каталог "./src/epf/Внешние обработки/Моя обработка". Также следует иметь ввиду, что формат выгрузки precommit1c не совместим с форматом хранения обработок в "иерархическом XML формате".
  
  Собрать обработку обратно в epf файл можно при помощи того же precommit1c, используя команду "--compile", Например команда
  
  создаст в каталоге "D:/epf" файл "Моя обработка.epf". Рекомендую при указании путей использовать прямые слеши ("/"), а не принятые в windows обратные. Это сэкономит вам массу времени и нервов при дальнейшей автоматизации процессов.
  
  Структура репозитория
  
  В процессе работы с продуктом у вас выработаются свои стандарты хранения информации внутри репозитория продукта. Вы для себя определите, где хранить файлы конфигурации, где хранить файлы внешних отчетов и обработок, где хранить документацию и прочие правила. Однако можно воспользоваться готовым шаблоном структуры репозитория продукта. В частности Введение в CI для 1С
  
  Как Git работает?
  
  Да ничего особенного: выбираете каталог с исходниками ПО или просто файлами и «говорите» Git, что для этого
  
  Для чего он нам нужен?
  
  «Продвинутые» разработчики 1С уже, наверное, задумались: зачем 1С-нику нужен Git, если есть собственная VCS, встроенная в платформу «Хранилище конфигурации»? На самом деле огромное спасибо компании 1С за данный функционал. Стоит также отметить, что собственная VCS есть далеко не во всех даже более «продвинутых» современных ERP-системах и платформах для разработки бизнес-систем.
  
  К сожалению, у хранилища конфигурации 1С есть определенные недостатки:
  
  Code review
  
  Пожалуй, самым важным процессом, который из-за недостатка инструментария в командах разработчиков 1С практически никогда не практикуется, является так называемый Code review. На тему, для чего это нужно и как это правильнее делать, уже написаны тома литературы. Можно посмотреть, к примеру, перевод популярной провокационной статьи.
  По сути, Code review позволяет сделать лучше следующие моменты:
  - Программист, зная, что его код с пристрастием посмотрят, больше заботится о качестве кода, пишет его более корректно и аккуратно.
  - В процессе обсуждения и корректировки кода после ревизии происходят одновременно сразу два полезных действия: улучшается качество продукта и квалификация программистов, его разрабатывающих
  Что нам нужно для Code review? Сразу хочется ответить «только сам код и больше ничего». Но, к сожалению, это не так. Code review хорошо бы проводить только для недавно написанного кода. Кроме того, специфика разработки в 1С заключается в том, что в большинстве случаев решение не разрабатывается «с нуля». Есть достаточно большой объем начального кода, который, как правило, превышает в разы объем разработки, выполняемой проектной командой. Поэтому смотреть в чистом виде все модули не имеет никакого смысла.
  Таким образом, нам нужна история изменения по всем модулям, с быстрым доступом и анализом ее. Вот тут как раз и напрашивается использование Git. Осталось только определиться со средством представления итоговой информации, чтобы с ним было удобно работать.
  
  GitLab
  
  Что нужно сделать?
  
  4) Чуть настроим репозиторий. Желательно бы убрать оттуда все, что не содержит код, а именно вносим в файл .git/ info/exclude следующие строки:
  
  Перед началом совместной работы над большим проектом желательно выполнить некоторые настройки Git. Они помогут вам избежать проблем, связанных с использованием больших файлов, разных операционных систем и разных кодировок.
  
  Эти настройки вы можете выполнить в параметрах 1C:EDT или из командной строки в консоли Git, если Git уже установлен у вас на компьютере.
  
  Например, чтобы указать адрес электронной почты нужно добавить следующую пару ключ - значение:
  
  Те же самые действия выполняются из командной строки следующей командой:
  
  Результат будет один и тот же.
  
  Далее все настройки будут описаны для работы с параметрами 1C:EDT и в качестве справки будут даны консольные команды.
  
  Имя и адрес электронной почты
  
  При первом коммите 1C:EDT попросит вас указать имя и адрес электронной почты, которыми она будет идентифицировать ваши коммиты. Чтобы другие разработчики могли понимать, кто именно внес те или иные изменения.
  - user.name — ваше имя;
  - user.email — ваш адрес электронной почты.
  При работе из командной строки используйте следующие команды:
  
  Длинные имена файлов
  
  На вашем компьютере может существовать ограничение на длину имени файла, например 260 символов в операционной системе Windows. Поэтому при клонировании репозиториев или при создании локальных репозиториев вы можете получить ошибку Filename too long .
  - располагайте локальные репозитории как можно ближе к корню диска;
  - запустите 1C:EDT от имена администратора и добавьте следующий параметр на вкладке Настройки пользователя :
    - core.longpaths — true .
    При работе из командной строки используйте следующую команду (консоль Git должна быть запущена от имени администратора):
    Большие файлы
    
    При работе из командной строки используйте следующую команду:
    
    Символы окончания строк
    
    Если разработчики, работающие над проектом, используют разные операционные системы (Microsoft Windows, Linux, macOS), нужно настроить конвертацию символов окончания строк при помещении в репозиторий и чтении из него. Следующие команды настраивают Git таким образом, что в рабочей копии разработчика будут использоваться "родные" для его операционной системы символы, а в репозитории всегда будет использоваться LF.
    
    Читайте также:

gitsync

precommit1c

Структура репозитория

Как Git работает?

Для чего он нам нужен?

Code review

GitLab

Что нужно сделать?

Имя и адрес электронной почты

Длинные имена файлов

Большие файлы

Символы окончания строк