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

Template Sync Strategy описывает процесс, при котором приложение создаётся от шаблона и дальше регулярно получает обновления шаблона без ручного копирования файлов.

Основной маршрут:

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

Где:

Задача

Шаблон хорошо решает старт проекта: приносит CI/CD, Dockerfile, зависимости, линтер, сборку, структуру и базовую документацию. Но после старта приложения расходятся: где-то обновили CI, где-то забыли, где-то сделали локальную кастомизацию.

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

Главный принцип

Ветка template должна оставаться чистым слепком оригинального шаблона.

В неё нельзя коммитить изменения приложения и нельзя решать конфликты. Все конфликтные решения выполняются только во временных ветках sync/*.

Состав документации

',15)])])}const f=a(o,[["render",i]]);export{h as __pageData,f as default};