S.Gromov
1a14df9366
- добавлены каноны и VitePress-сайт стратегии обновления шаблонов - подключена карточка документации на главной странице - добавлены сборочные скрипты, Caddy-маршрут и Docker-сборка - добавлена git-иконка для карточки и сгенерированы публичные артефакты
79 lines
2.6 KiB
Markdown
79 lines
2.6 KiB
Markdown
---
|
||
url: /template-sync-strategy/workflows/resolve-conflicts.md
|
||
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
|
||
```
|