- добавлены каноны и VitePress-сайт стратегии обновления шаблонов - подключена карточка документации на главной странице - добавлены сборочные скрипты, Caddy-маршрут и Docker-сборка - добавлена git-иконка для карточки и сгенерированы публичные артефакты
2.6 KiB
url, description
| url | description |
|---|---|
| /template-sync-strategy/workflows/resolve-conflicts.md | Почему конфликты при обновлении шаблона должны решаться только в sync-ветках. |
Решение конфликтов
Конфликт при обновлении шаблона — нормальная ситуация. Важно не то, что конфликт возник, а где он возник.
Правильное место для конфликтов — временная ветка sync/*.
Пример
Шаблон поменял строку в README.md:
Base template version: template-conflict-v10
Приложение поменяло ту же строку иначе:
Base template version: application-conflict-v10
При merge origin/template в sync/update-template-v10 появится конфликт:
<<<<<<< HEAD
Base template version: application-conflict-v10
=======
Base template version: template-conflict-v10
>>>>>>> origin/template
Это правильное место конфликта: master ещё не изменён, template остаётся чистой, а итоговое решение можно проверить в PR/MR.
Как решать
- Оставайтесь в ветке
sync/*. - Разберите конфликт по смыслу: что должно остаться в приложении после обновления шаблона.
- Удалите conflict markers.
- Проверьте проект локально.
- Закоммитьте результат.
git status
git add .
git commit
Что нельзя делать
Нельзя переносить conflict resolve в template.
template должна совпадать с шаблоном. Если решение конфликта попадёт туда, она перестанет быть эталоном и дальнейшие обновления станут менее предсказуемыми.
Нельзя решать конфликт прямо в master, потому что основная ветка приложения должна получать только проверенный результат через PR/MR.
Что проверить после resolve
Посмотрите статус:
git status
Посмотрите diff относительно текущего приложения:
git --no-pager diff origin/master...HEAD
Посмотрите граф:
git --no-pager log --oneline --graph --decorate --all --max-count=50