Какие команды Git используются для работы с ветками и слияниями
Что проверяют
Работали ли вы в команде с ветками, а не только коммитили в main. Интервьюер ждёт не список команд, а понимание разницы между merge и rebase и умение разрешить конфликт. Следом спрашивают, как вы обновляете свою ветку от основной.
Как отвечать
Сгруппируйте команды по задачам:
- создание и переключение:
git switch -c feature/xсоздаёт ветку и переходит на неё,git switch mainпереключает.git checkout -bработает по-прежнему, ноswitchпоявился, чтобы развести переключение веток и восстановление файлов (git restore); - обзор:
git branch -aвместе с удалёнными ветками,git log --oneline --graph --allдля картины истории; - обновление от основной ветки:
git fetch, затемgit rebase origin/mainилиgit merge origin/main; - слияние:
git merge --no-ffсохраняет коммит слияния,git merge --ff-onlyсливает только перемоткой и падает, если истории разошлись; - перенос отдельных коммитов:
git cherry-pick <sha>; - публикация:
git push -u origin feature/x, а после rebasegit push --force-with-lease, который не затрёт чужие коммиты на удалённой ветке; - удаление:
git branch -dдля слитой ветки,-Dпринудительно.
Конфликт: Git помечает файлы, вы правите маркеры, делаете git add и git merge --continue или git rebase --continue, а передумав, git merge --abort.
Для Python-проекта назовите частый случай: конфликт в uv.lock или poetry.lock. Руками такой файл не правят, берут одну из версий, пересобирают его через uv lock или poetry lock и прогоняют тесты.
Где спотыкаются
Считают, что git pull на своей ветке подтягивает изменения из main. Он обновляет ветку от её собственного upstream, а свежий main нужно явно влить или сделать rebase.
Делают rebase ветки, в которой уже работают коллеги, и пушат через --force. Чужие коммиты пропадают с удалённой ветки.
Не могут объяснить разницу merge и rebase. Короткий ответ: merge сохраняет историю как есть и добавляет коммит слияния, rebase переносит ваши коммиты на новую базу, создавая новые коммиты с другими хэшами.