Назначение: Практическое руководство. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Оператор развёртывания · Рецензент и приёмщик · Нейросеть.

Темы: Разработка → Git · Разработка → Передача изменений.

Общий модуль хранится в своём Git-репозитории и может использоваться несколькими приложениями. Здесь описаны работа и публикация со стороны ShariX Open. Проверка и принятие изменения со стороны другого продукта поручаются его ответственному.

Модуль может быть общим для ShariX Open и других продуктов и при этом оставаться закрытым. Для каждого репозитория проверить LICENSE и COMPLIANCE. Общие закрытые компоненты описываются и дорабатываются по внутренним инструкциям; эта страница не включает их в публичную поставку.

–shared показывает роль репозиториев в установленной сборке, а не их лицензию. Набор для публичной задачи ограничивают явно с помощью –repo. Например, если задача относится только к открытым dbsynce и design_template, их состояние можно посмотреть так:

./bin/repositories.sh status --shared --repo dbsynce --repo design_template

Это пример чтения статуса, а не команда публикации всех установленных модулей. Закрытые репозитории не добавляют в выбор ради полной синхронизации. Перечень границ — владение моделями.

Корневой проект и вложенные модули могут быть самостоятельными Git-репозиториями. Из фактического корня установки посмотреть их состояние:

./bin/repositories.sh status
./bin/repositories.sh status --shared

У каждого затронутого репозитория проверить:

• изменённые файлы;
• origin;
• ветку;
• commit.

Отдельно указать уже применённые предыдущие этапы. Один корневой git status не описывает состояние всех модулей. Карта ответственности — репозитории и исходники.

1. Изменить код в его репозитории; отдельно перечислить зависимые изменения корня и модулей.
2. Проверить относящиеся к задаче данные, миграции, права и пользовательский сценарий ShariX Open.
3. Опубликовать согласованный набор репозиториев штатным repositories.sh. Если изменены несколько репозиториев, проверить публикацию каждого.
4. Записать commits и фактические результаты проверки. Публикация кода и обновление работающей установки — разные результаты.

Команды обновления ShariX Open находятся в инструкции установки, состав поставки — в передаче результата оператору.

Настроенная ветка может отличаться от OPERATIONAL_BRANCH — ветки согласованного этапа изменения. Её имя берётся из конфигурации. В ShariX Open предусмотрены следующие команды:

Согласованное правило 07.11.2026: URL и ветка установленного Git checkout из локального bin/install.cfg определяют исходники работающей установки. Remote origin остаётся за этим репозиторием и веткой. Канонический master владельца подключают отдельно как upstream/master, даже если оба remote имеют один URL. URL владельца сверяют по опубликованному каталогу исходников и поставляемому bin/install.cfg.example; чужой сервисный remote к основному checkout ради сравнения не добавляют. Для настройки достаточно штатных команд git remote add/rename, git fetch и проверки веток; исходники и скрипты установщика менять не требуется. Постоянная промежуточная ветка не нужна.

Начальная приёмка общего изменения выполняется на testopen1 в настроенной ветке office. В канонический master ShariX Open публикуют только конкретные принятые общие коммиты после review: всю office автоматически не переносить, поскольку она содержит собственную историю. Далее сервисный checkout получает опубликованный master через upstream, разрешает несовместимости в своей ветке, проверяет результат и публикует его в собственный origin. Лишь после этого обычный pull/deploy на сервере получает обновлённую настроенную ветку.

Проверять git remote -v, git branch -vv, SHA веток и наличие общего предка. install.sh deploy и repositories.sh pull обновляют настроенную ветку из origin, но сами не сливают другой remote. update-start и sync-operational также рассчитаны на ветки одного origin. При несвязанных историях, конфликтах или разных графах миграций автоматический pull/merge не объявлять успешным: нужен отдельный reviewed перенос. Подготовленный ранее патч sync-upstream отозван; его не устанавливают.

Команды update-* предназначены только для ShariX Open. Конкретный сценарий определяет репозитории и момент каждого действия; таблица не является блоком для безусловного запуска. При расхождении веток или незавершённом объединении сначала выясняют состояние. Уникальная история отдельной ветки не переносится автоматически обратно в OPERATIONAL_BRANCH.

Общие (shared) модули ShariX Open могут использоваться и в Platform. После публикации изменения нужно оповестить ответственного со стороны Platform и передать:

• репозитории и commits;
• описание изменения;
• результаты проверки.

Ответственный проверяет изменение, тестирует его и оформляет принятие в общий код по своим инструкциям в intrawiki. Действия на Platform не выполняются как продолжение публичной инструкции ShariX Open.

Передать сведения по порядку shared-изменений:

• что изменилось;
• где опубликовано;
• какие версии нужны совместно;
• какие проверки выполнены;
• нужны ли миграции или уточнение конфигурации.

Зафиксировать отправку и отдельно полученный результат рассмотрения. Отправленное сообщение не означает принятия изменения.

Для выполнения своей части разработчику ShariX Open не нужен доступ к закрытым репозиториям и серверам Platform. Её внутренние команды, пути и порядок приёмки описываются в intrawiki, а не на этой странице.

Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.

• sharix-open-webapp-base: CODING_POLICY.md — f65376cdb5a3.
• sharix-open-webapp-base: bin/repositories.sh — f65376cdb5a3.

• sharix-open-webapp-base: CODING_POLICY.md.
• sharix-open-webapp-base: bin/repositories.sh.