Зачем это нужно

Шаблон закрывает повторяющуюся техническую базу проекта: CI/CD, Dockerfile, зависимости, lint, build, структуру каталогов и базовую документацию.

Это снимает рутину на старте. Команде не нужно каждый раз заново собирать одинаковый технический каркас.

Проблема после старта

Создать проект легко. Поддерживать 10-20 проектов сложнее.

Сначала проекты похожи. Потом они начинают расходиться:

• В одном проекте обновили CI, в другом забыли.
• В одном проекте Dockerfile остался из шаблона, в другом его локально поправили.
• В одном проекте зависимости уже свежие, в другом остались старые версии.
• В одном проекте изменения шаблона перенесли руками, в другом потеряли.

Без процесса обновления шаблон перестаёт быть общей основой. Он остаётся только способом быстро создать первый коммит.

Что ломается без стратегии

Когда шаблон нельзя нормально обновлять:

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

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

Цель стратегии

Стратегия не пытается убрать конфликты полностью. Она делает так, чтобы конфликты возникали в предсказуемом месте, проходили review и не ломали чистую ветку шаблона.

Главная формулировка:

Шаблон должен обновляться так же контролируемо, как обычная фича: через ветку, проверку и PR/MR.