refactor: перенести сборку в проекты
- перенесены каноны и VitePress-конфиги в projects/<slug> - добавлены корневой и проектные build.ts для сборки артефактов - добавлены shared-библиотеки сборки в projects/_shared/lib - обновлены CI, Dockerfile, package.json, gitignore и README - удалена сборка frontend-агента
This commit is contained in:
@@ -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
|
||||
```
|
||||
Reference in New Issue
Block a user