S.Gromov
bdb99ade62
- перенесены каноны и VitePress-конфиги в projects/<slug> - добавлены корневой и проектные build.ts для сборки артефактов - добавлены shared-библиотеки сборки в projects/_shared/lib - обновлены CI, Dockerfile, package.json, gitignore и README - удалена сборка frontend-агента
79 lines
2.6 KiB
Markdown
79 lines
2.6 KiB
Markdown
---
|
||
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
|
||
```
|