import{_ as a,o as t,c as r,ae as l}from"./chunks/framework.B1nRs-GM.js";const h=JSON.parse('{"title":"Template Sync Strategy","description":"Управляемое обновление проектов от шаблона через чистую ветку template, временные sync-ветки и PR/MR.","frontmatter":{"title":"Template Sync Strategy","description":"Управляемое обновление проектов от шаблона через чистую ветку template, временные sync-ветки и PR/MR.","keywords":["template sync","шаблон проекта","обновление шаблона","git template","sync branch","template branch"]},"headers":[],"relativePath":"overview.md","filePath":"overview.md"}'),o={name:"overview.md"};function i(s,e,c,n,d,p){return t(),r("div",null,[...e[0]||(e[0]=[l('
Template Sync Strategy описывает процесс, при котором приложение создаётся от шаблона и дальше регулярно получает обновления шаблона без ручного копирования файлов.
Основной маршрут:
templates/master -> template -> sync/* -> masterГде:
templates/master — основная ветка внешнего репозитория шаблона.template — чистый слепок шаблона внутри репозитория приложения.sync/* — временная ветка, где шаблон накладывается на приложение.master — основная ветка приложения.Шаблон хорошо решает старт проекта: приносит CI/CD, Dockerfile, зависимости, линтер, сборку, структуру и базовую документацию. Но после старта приложения расходятся: где-то обновили CI, где-то забыли, где-то сделали локальную кастомизацию.
Стратегия нужна, чтобы шаблон оставался общей технической базой не только в первый день проекта, но и на всём жизненном цикле приложения.
Ветка template должна оставаться чистым слепком оригинального шаблона.
В неё нельзя коммитить изменения приложения и нельзя решать конфликты. Все конфликтные решения выполняются только во временных ветках sync/*.
templates/master, template, sync/* и master.master.