Как устроена логика merge requests?
Что проверяют
Работали ли вы в команде с нормальным процессом ревью и понимаете ли, что происходит между «открыл MR» и «код в main». Интервьюера интересуют не кнопки GitLab, а правила: что обязано пройти до слияния и как вы решаете конфликты. Следом часто спрашивают, rebase или merge и почему.
Как отвечать
Опишите жизненный цикл MR в Android-проекте:
- ветка: от
mainилиdevelop, имя с номером задачи, небольшой объём изменений. Незаконченное открывают как Draft; - пайплайн: на каждый пуш запускается CI:
./gradlew lint, detekt или ktlint,testDebugUnitTest, сборкаassembleDebug. Инструментальные тесты на эмуляторе дорогие, их часто гоняют выборочно или ночью; - ревью: обязательные апрувы, CODEOWNERS для модулей, запрет слияния при красном пайплайне и незакрытых обсуждениях;
- слияние: в GitLab метод задаётся настройкой проекта: merge commit, merge commit с полулинейной историей или fast-forward, плюс опция squash. В двух последних режимах ветку сначала нужно ребейзнуть на целевую;
- после слияния: сборка из
main, выкладка на тестирование через Firebase App Distribution или внутренний трек Google Play.
Про конфликты скажите конкретно: в Android они чаще всего в libs.versions.toml, build.gradle.kts, strings.xml и графах навигации. Решаются ребейзом своей ветки на свежий main и повторным прогоном тестов. git push --force-with-lease допустим только в свою ветку.
Покажите свой опыт цифрами: размер типичного MR, сколько апрувов требовалось, сколько шёл пайплайн. Если работали на GitHub, объясните, что pull request это то же самое под другим названием.
Где спотыкаются
Открывают MR на две тысячи строк с рефакторингом и фичей вместе. Ревьюер такое не читает, а просто ставит апрув.
Путают git merge и git rebase или делают force push в общую ветку, переписав чужие коммиты.
Считают, что зелёный пайплайн на ветке гарантирует зелёный main. Если целевая ветка ушла вперёд, результат слияния может не собраться, поэтому GitLab умеет запускать пайплайн для merged results и выстраивать merge trains.