import{_ as a,o as s,c as t,ae as i}from"./chunks/framework.B1nRs-GM.js";const k=JSON.parse('{"title":"Модель веток","description":"Роли веток и remote в стратегии обновления проекта от шаблона.","frontmatter":{"title":"Модель веток","description":"Роли веток и remote в стратегии обновления проекта от шаблона."},"headers":[],"relativePath":"concepts/model.md","filePath":"concepts/model.md"}'),p={name:"concepts/model.md"};function l(n,e,d,o,h,r){return s(),t("div",null,[...e[0]||(e[0]=[i(`
Целевая схема:
templates/master -> template -> sync/* -> masterЭто логическая модель ответственности. Она не требует физически разделять файлы шаблона и приложения по папкам.
templates/master — это master из репозитория шаблона.
В репозитории приложения он доступен через remote templates:
git remote add templates <template-repo-url>
git fetch templatesЭтот remote считается источником обновлений шаблона.
template — чистый слепок шаблона внутри репозитория приложения.
Его задача — показать, какая версия шаблонной базы сейчас доступна приложению.
В template нельзя коммитить руками изменения приложения. Эта ветка обновляется только из templates/master.
master — основная ветка приложения.
Она содержит:
master не используется как место ручного решения конфликтов при обновлении шаблона.
sync/* — временная ветка для обновления приложения от шаблона.
Она создаётся от актуального origin/master, после чего в неё вливается origin/template.
Пример:
git fetch origin
git switch -c sync/update-template-v2 origin/master
git merge origin/templateЕсли появляются конфликты, они решаются именно в этой ветке.
Нельзя безопасно использовать template как source branch для прямого PR/MR в master: если возникнет конфликт, решение может попасть в template.
После этого template перестанет быть чистым слепком шаблона. Git начнёт видеть в ней не только шаблон, но и локальные решения конкретного приложения.
sync/* можно пачкать conflict resolve-коммитами, проверками и правками совместимости. Эта ветка временная и удаляется после merge.