Групповая разработка и система контроля версий Git

Этот раздел описывает общие вопросы групповой разработки, а также принципы построения и работы системы контроля версий Git.

Перспектива «Git»

Перспектива Git — это основное рабочее пространство для работы с системой контроля версий Git.

Открыть перспективу «Git»
Открыть эту Git можно несколькими способами:
  • В панели перспектив нажмите (Открыть перспективу)—Git;
  • В главном меню основного окна нажмите Окно > Перспектива > Открыть перспективу > Другое... > Git.

В стандартный состав перспективы Git входят следующие элементы:

  1. Панель Репозитории Git — это главный инструмент, который позволяет управлять одновременно несколькими репозиториями;
  2. Область редакторов — в этой области, например, может открываться панель просмотра коммита;
  3. Панели:
    • История — эта панель показывает ресурсы репозитория, акцентируя внимание на коммитах;
    • Синхронизация — эта панель позволяет вам проверять различия между ресурсами в локальной директории и ресурсами, находящимися в локальной или удаленной ветке;
    • Журнал ссылок Git — эта панель показывает журнал ссылок для выбранного репозитория;
    • Свойства — эта панель показывает свойства локальных и удаленных репозиториев, выбранных в панели Репозитории Git.

Конфигурация хранится в виде файлов

1C:EDT хранит конфигурацию в виде файлов собственного формата на диске. Это дает несколько технологических преимуществ.

Самым главным преимуществом, конечно же, является простая возможность использования сторонних систем контроля версий. В 1C:EDT существует встроенная поддержка Git, поэтому с этой системой можно работать сразу же и без оговорок.

Технология плагинов Eclipse позволяет вам использовать и другие системы контроля версий. Можно использовать их в индивидуальных целях для создания архива своих разработок и их версионирования. Однако пользоваться функциями объединения изменений или групповой разработки не рекомендуется. Без специальной адаптации «родное» объединение .xml-файлов может не всегда корректно работать с точки зрения «1С:Предприятия». В случае с Git такая адаптация была выполнена, и всеми его функциями можно пользоваться в полном объеме.

Лицензирование разработок при использовании публичных репозиториев

В этом разделе коротко описаны положения лицензионной политики фирмы «1С», которые вам нужно учитывать при публикации своих разработок в публичных репозиториях, а также при использовании стандартных библиотек, поставляемых фирмой «1С».

Свою собственную конфигурацию, не содержащую фрагментов, поставляемых фирмой «1С», можно публиковать на GitHub (подробнее см. вопрос 62).

Свою разработку, содержащую фрагменты, поставляемые фирмой «1С» (например, вы модифицировали типовую конфигурацию), публиковать на GitHub нельзя (подробнее см. вопрос 71).

Отдельными правилами регулируется распространение и использование стандартных библиотек, поставляемых фирмой «1С» (БСП и других).

Начиная с версии 3.0.2 БСП имеет собственную лицензию, которой нужно руководствоваться при ее распространении и использовании ( подробнее см. вопрос 70). Фирма «1С» планирует постепенно выпустить с лицензиями и другие стандартные библиотеки.

Лицензию БСП 3.0.2 можно посмотреть в файле %AppData%\1C\1cv8\tmplts\1C\SSL\3_0_2_164\ExtFiles\Docsnews.htm (после установки шаблона конфигурации) или на сайте (ссылка). Также лицензия указана в шапке каждого модуля, входящего в состав БСП.

Смысл лицензии Attribution 4.0 International (CC BY 4.0) заключается в том, что можно распространять (например, публиковать на GitHub), редактировать, исправлять и брать БСП 3.0.2 за основу для собственных конфигураций, в том числе предназначенных для распространения на коммерческой основе. При этом вы должны указывать правообладателя (Copyright © ООО «1С-Софт», 2009-2024), а также указывать, что именно было изменено, если вы внесли в нее изменения.

В том случае, когда стандартная библиотека не имеет собственной лицензии, фирма «1С» разрешает использовать ее только официальным пользователям продуктов «1С:Предприятия» версии ПРОФ и выше, имеющим действующий договор 1С:ИТС, а также партнерам фирмы «1С» в рамках заключенного ими договора с «1С» (подробнее см. вопрос 72).

Поддержка возможностей Git при разработке приложений «1С:Предприятия»

Работа с системой контроля версий Git подразумевает частое создание веток, переключение с одной ветки на другую, запуск и отладку приложения в каждой из веток. 1C:EDT содержит ряд механизмов, которые помогают вам использовать Git при разработке приложений «1С:Предприятия».

Разные информационные базы для разных веток

Особенность платформы «1С:Предприятие» заключается в том, что конфигурация, которая может разрабатываться в разных ветках, содержит не только исполняемый код, но и описание структур данных, с которыми эта конфигурация работает. При запуске или при отладке приложения 1C:EDT всегда помещает разрабатываемую конфигурацию в информационную базу, связанную с проектом. Если описание структур данных, которое помещается, отличается от того, которое имеется в информационной базе, платформа выполняет реструктуризацию базы данных.

С одной стороны, это удобно, поскольку вы всегда можете быть уверены: что структура базы данных в точности соответствует той, которую ожидает «увидеть» запущенное приложение. С другой стороны, в разных ветках Git у вас может быть разный состав объектов конфигурации. Поэтому вам необходимо иметь разные информационные базы для каждой из веток, чтобы запуск приложения из одной ветки не влиял на данные, которые вы подготовили, запуская приложение из другой ветки.

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

Все эти доработки находятся в нескольких местах:

  • Для создания новой ветки Git мы рекомендуем использовать не стандартную команду EGit, а собственную команду 1C:EDT — (Создать новую ветку...). Она находится, например, в панели Навигатор в контекстном меню проекта в группе Групповая разработка > (подробнее). Эта команда не только создаст ветку Git, но и свяжет ее с новой информационной базой или с одной из существующих баз ( подробнее).
  • В редакторе конфигураций запуска и отладки для новых конфигураций установлено стандартное значение: Использовать информационную базу по умолчанию для проекта ( подробнее). Это значит, что, когда вы переключите проект на другую ветку Git и решите запустить его, 1C:EDT создаст конфигурацию запуска с той информационной базой, которая соответствует текущей ветке Git.
  • Для просмотра связей между проектом, ветками Git и информационными базами можно использовать панель Разработка (подробнее).
  • Для удаления веток, а также (при необходимости) для удаления информационных баз, которые с ними связаны ( подробнее), можно использовать контекстную команду Удалить ветку..., которая находится, например, в панели Разработка в контекстном меню задачи ( подробнее).
  • Настроить стандартные имена и типы веток, способы создания информационных баз можно в группе параметров V8 > Командная разработка (подробнее).
Оптимизация формата хранения данных проекта

1C:EDT при переходе от версии к версии может менять внутренний формат .xml-файлов проекта. Когда вы работаете с одной и той же веткой проекта проблем не возникает. При открытии старой рабочей области новая версия 1C:EDT, если в этом есть необходимость, выполняет миграцию проекта на новый внутренний формат.

Однако если вы ведете разработку в разных ветках или работаете вместе с другими разработчиками, можно столкнуться со следующей неудобной ситуацией. Когда вы вливаете старую ветку в ветку master, вы неожиданно видите, помимо собственных изменений, большое количество изменений, которые вы не делали. Эти изменения как раз и могут быть результатом того, что мы, разработчики 1C:EDT, изменили внутренний формат файлов проекта. Получается, что в одной ветке у вас проект в новом формате, а в другой ветке - в старом. Никаких функциональных отличий между ними нет, но средства сравнения показывают большое количество изменений, которые затрудняют анализ кода для разработчиков.

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

При использовании оптимизации нужно помнить о двух особенностях.

Во-первых, на больших проектах она может занять значительное время.

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

Книга «Групповая разработка в 1C:Enterprise Development Tools»

Эта книга позволит вам «с нуля» освоить систему контроля версий Git. Все возможности и приемы работы с Git проиллюстрированы на основе среды разработки 1C:Enterprise Development Tools.

Если вы никогда не работали с Git, эта книга для вас. Она имеет удобный указатель и поиск.

Эту книгу можно посмотреть на портале 1C:EDT по этой ссылке.

Некоторые теоретические разделы, которые могут быть полезны: