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
|
|||
|
|
```
|