Какой у тебя опыт работы с git и разрешением конфликтов
Что проверяют
Понимаете ли вы, откуда берётся конфликт и что происходит с историей, или просто нажимаете кнопки в IDE. Следом обычно спрашивают про разницу между merge и rebase и что делать, если конфликт в коде, который вы не писали и не понимаете.
Как отвечать
Опишите свой рабочий цикл и типичный конфликт:
- процесс в команде: короткие ветки от
main, pull request, перед слиянием подтягиваете свежийmainчерезgit fetchиgit rebase origin/mainилиgit merge, как принято в команде; - разбор конфликта:
git statusпоказывает файлы, внутри маркеры<<<<<<<,=======,>>>>>>>. Настройкаmerge.conflictStyle zdiff3добавляет общую базу, и видно, что поменяла каждая сторона. Дальшеgit addиgit rebase --continueили коммит слияния, а если что-то пошло не так,--abort; - стороны:
git checkout --oursи--theirsберут одну версию целиком. Во времяrebaseих смысл меняется местами, и это стоит сказать; - специфика Python: конфликт в
poetry.lockилиuv.lockруками не правят. Берут одну сторону и пересобирают файл черезpoetry lockилиuv lock. Две ветки с миграциями Alembic дают две головы, их находитalembic headsи объединяетalembic merge, в Django для этого естьmakemigrations --merge; - проверка: после разрешения прогоняете
pytestи линтеры. Текстуально чистое слияние может сломать логику, если одна ветка переименовала функцию, а другая добавила её вызов.
Упомяните, как уменьшаете число конфликтов: маленькие PR, частое обновление ветки, общий форматтер ruff format или black через pre-commit, чтобы конфликтов из-за пробелов и кавычек не было вовсе.
Если серьёзных конфликтов у вас не случалось, скажите об этом и разберите типичный сценарий по шагам: это честнее выдуманной истории.
Где спотыкаются
Разрешают конфликт, оставляя целиком свою версию, и молча выкидывают чужую работу.
Делают git push --force в общую ветку после ребейза. Перезапись допустима только в своей ветке и через --force-with-lease.
Не запускают тесты и считают конфликт решённым, как только исчезли маркеры.