Как работать с ветками в Git

Что проверяют

Умеете ли вы работать с ветками в команде, а не только создавать их. Следом обычно спрашивают, чем merge отличается от rebase и как вы разрешали конфликт в package-lock.json.

Как отвечать

Базовые команды назовите быстро и в современном виде:

• создание и переключение: git switch -c feature/login и git switch main. Команды switch и restore появились в Git 2.23 и разгрузили перегруженный checkout;
• список и удаление: git branch -a; git branch -d удаляет только слитую ветку, -D принудительно; ветку на сервере убирает git push origin --delete;
• слияние: git merge делает fast-forward, если история линейна, иначе создаёт merge-коммит. Флаг --no-ff сохраняет merge-коммит всегда;
• rebase: переносит ваши коммиты поверх свежего main, история получается линейной. git rebase -i помогает склеить мелкие коммиты перед ревью;
• публикация после rebase: только git push --force-with-lease, он не затрёт чужие коммиты, появившиеся на сервере.

Потом про процесс. Короткие ветки на день-два и trunk-based или GitHub Flow подходят большинству фронтенд-команд; Git Flow с develop и release-ветками оправдан при редких версионированных релизах. Хорошо упомянуть preview-деплой каждой ветки (Vercel, Netlify или свой стенд), чтобы дизайнер и тестировщик смотрели вёрстку до слияния, и защиту main с обязательным ревью и зелёными проверками.

Конфликт: git status показывает файлы, вы правите блоки между маркерами, делаете git add и продолжаете через git merge --continue или git rebase --continue. Передумали: git merge --abort.

Где спотыкаются

Делают rebase общей ветки, с которой уже работают другие, и переписывают им историю.

Правят конфликт в package-lock.json руками. Надёжнее взять одну сторону, перегенерировать файл через npm install и проверить, что сборка проходит.

Держат ветку неделями. Чем дольше она живёт, тем больнее слияние, особенно в общих стилях и конфиге сборки.