import{_ as a,o as t,c as i,ae as l}from"./chunks/framework.B1nRs-GM.js";const u=JSON.parse('{"title":"Зачем это нужно","description":"Почему шаблону нужен процесс обновления, а не только быстрый старт нового проекта.","frontmatter":{"title":"Зачем это нужно","description":"Почему шаблону нужен процесс обновления, а не только быстрый старт нового проекта."},"headers":[],"relativePath":"concepts/why.md","filePath":"concepts/why.md"}'),o={name:"concepts/why.md"};function r(n,e,p,c,d,s){return t(),i("div",null,[...e[0]||(e[0]=[l('
Шаблон закрывает повторяющуюся техническую базу проекта: CI/CD, Dockerfile, зависимости, lint, build, структуру каталогов и базовую документацию.
Это снимает рутину на старте. Команде не нужно каждый раз заново собирать одинаковый технический каркас.
Создать проект легко. Поддерживать 10-20 проектов сложнее.
Сначала проекты похожи. Потом они начинают расходиться:
Без процесса обновления шаблон перестаёт быть общей основой. Он остаётся только способом быстро создать первый коммит.
Когда шаблон нельзя нормально обновлять:
Это особенно больно, когда приложений много. Для одного проекта ручной перенос ещё можно пережить. Для набора проектов нужен единый маршрут обновления.
Стратегия не пытается убрать конфликты полностью. Она делает так, чтобы конфликты возникали в предсказуемом месте, проходили review и не ломали чистую ветку шаблона.
Главная формулировка:
',17)])])}const _=a(o,[["render",r]]);export{u as __pageData,_ as default};Шаблон должен обновляться так же контролируемо, как обычная фича: через ветку, проверку и PR/MR.