Как организован процесс работы с ветками и слияниями?
Что проверяют
Работали ли вы в команде по понятному процессу и понимаете ли, зачем он устроен именно так. Следом обычно спрашивают, как вы разрешаете конфликты и что делаете, если фича не готова к релизу, а ветку пора вливать. Этот же вопрос полезно задать работодателю самому: ответ многое скажет о зрелости команды.
Как отвечать
Опишите процесс, в котором реально работали, и назовите модель:
- GitHub Flow или trunk-based: одна основная ветка
main, короткие фиче-ветки на день-два, частые слияния. Для веб-фронтенда с непрерывным деплоем это самый частый вариант; - Git Flow: ветки
develop,release/*,hotfix/*. Оправдан, когда есть версии с отдельным циклом, например библиотека компонентов или мобильное приложение. Для сайта обычно тяжеловат.
Дальше путь изменения: ветка от свежего main с именем по задаче, коммиты по Conventional Commits, пул-реквест. На нём CI гоняет линтер, проверку типов, юнит-тесты и сборку, а многие команды поднимают превью-стенд на каждую ветку, чтобы дизайнер и тестировщик смотрели живую страницу. Защита ветки не даёт влить код без зелёного CI и одобрения ревьюера.
Скажите про стратегию слияния: squash даёт один коммит на задачу и чистую историю, обычный merge сохраняет всю историю ветки, rebase and merge выпрямляет её без коммита слияния. Незаконченную функциональность прячут за фича-флагом, а не держат в долгой ветке.
Если опыт был только в одиночных проектах, так и скажите и опишите процесс, который выстроили бы в команде, с объяснением, почему именно он.
Где спотыкаются
Называют Git Flow единственно правильным и не могут объяснить, зачем нужна develop. В команде с ежедневными релизами она добавляет лишнее слияние и ничего не даёт взамен.
Делают rebase общей ветки и git push --force, стирая чужие коммиты. Свою ветку переписывать можно, но пушить через --force-with-lease.
Разрешают конфликт в package-lock.json вручную. Правильно взять версию из main, пересоздать lock-файл через npm install и проверить сборку.