refactor: перенести сборку в проекты
All checks were successful
CI/CD Pipeline / build (push) Successful in 39s
CI/CD Pipeline / docker (push) Successful in 1m30s
CI/CD Pipeline / deploy (push) Successful in 8s

- перенесены каноны и VitePress-конфиги в projects/<slug>

- добавлены корневой и проектные build.ts для сборки артефактов

- добавлены shared-библиотеки сборки в projects/_shared/lib

- обновлены CI, Dockerfile, package.json, gitignore и README

- удалена сборка frontend-агента
This commit is contained in:
2026-05-22 19:07:10 +03:00
parent a53c5fc1b1
commit bdb99ade62
117 changed files with 442 additions and 568 deletions

View File

@@ -0,0 +1,78 @@
---
title: Решение конфликтов
description: Почему конфликты при обновлении шаблона должны решаться только в sync-ветках.
---
# Решение конфликтов
Конфликт при обновлении шаблона — нормальная ситуация. Важно не то, что конфликт возник, а где он возник.
Правильное место для конфликтов — временная ветка `sync/*`.
## Пример
Шаблон поменял строку в `README.md`:
```text
Base template version: template-conflict-v10
```
Приложение поменяло ту же строку иначе:
```text
Base template version: application-conflict-v10
```
При merge `origin/template` в `sync/update-template-v10` появится конфликт:
```text
<<<<<<< HEAD
Base template version: application-conflict-v10
=======
Base template version: template-conflict-v10
>>>>>>> origin/template
```
Это правильное место конфликта: `master` ещё не изменён, `template` остаётся чистой, а итоговое решение можно проверить в PR/MR.
## Как решать
1. Оставайтесь в ветке `sync/*`.
2. Разберите конфликт по смыслу: что должно остаться в приложении после обновления шаблона.
3. Удалите conflict markers.
4. Проверьте проект локально.
5. Закоммитьте результат.
```bash
git status
git add .
git commit
```
## Что нельзя делать
Нельзя переносить conflict resolve в `template`.
`template` должна совпадать с шаблоном. Если решение конфликта попадёт туда, она перестанет быть эталоном и дальнейшие обновления станут менее предсказуемыми.
Нельзя решать конфликт прямо в `master`, потому что основная ветка приложения должна получать только проверенный результат через PR/MR.
## Что проверить после resolve
Посмотрите статус:
```bash
git status
```
Посмотрите diff относительно текущего приложения:
```bash
git --no-pager diff origin/master...HEAD
```
Посмотрите граф:
```bash
git --no-pager log --oneline --graph --decorate --all --max-count=50
```