docs/projects/template-sync-strategy/canons/concepts/model.md

title, description

title	description
Модель веток	Роли веток и remote в стратегии обновления проекта от шаблона.

Модель веток

Целевая схема:

templates/master -> template -> sync/* -> master

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

templates/master

templates/master — это master из репозитория шаблона.

В репозитории приложения он доступен через remote templates:

git remote add templates <template-repo-url>
git fetch templates

Этот remote считается источником обновлений шаблона.

template

template — чистый слепок шаблона внутри репозитория приложения.

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

В template нельзя коммитить руками изменения приложения. Эта ветка обновляется только из templates/master.

master

master — основная ветка приложения.

Она содержит:

• базу шаблона;
• продуктовый код;
• локальные настройки приложения;
• историю применения обновлений шаблона.

master не используется как место ручного решения конфликтов при обновлении шаблона.

sync/*

sync/* — временная ветка для обновления приложения от шаблона.

Она создаётся от актуального origin/master, после чего в неё вливается origin/template.

Пример:

git fetch origin
git switch -c sync/update-template-v2 origin/master
git merge origin/template

Если появляются конфликты, они решаются именно в этой ветке.

Почему нужен отдельный sync-слой

Нельзя безопасно использовать template как source branch для прямого PR/MR в master: если возникнет конфликт, решение может попасть в template.

После этого template перестанет быть чистым слепком шаблона. Git начнёт видеть в ней не только шаблон, но и локальные решения конкретного приложения.

sync/* можно пачкать conflict resolve-коммитами, проверками и правками совместимости. Эта ветка временная и удаляется после merge.