Как устроен процесс работы с ветками разработки и автоматическим слиянием

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

Какая модель ветвления была у вас и почему, как код попадает в основную ветку без ручной рутины и как вы живёте с конфликтами. Уточнение почти всегда такое: что будет, если два PR по отдельности зелёные, а вместе ломают сборку.

Как отвечать

Сначала модель ветвления:

• GitFlow: develop, release/*, hotfix/*. Тяжеловат, но в мобайле релизные ветки часто остаются: сборка уходит в стор и на ревью, в ней чинят баги, пока main живёт дальше;
• trunk-based: короткие ветки на день-два, незаконченное прячут за фича-флагами. Конфликтов меньше, но нужен быстрый и надёжный CI;
• хотфиксы: исправление в релизной ветке обязательно возвращается в main через back-merge или cherry-pick, иначе баг вернётся в следующем релизе.

Затем автоматизация слияния:

• защищённые ветки: прямой пуш в main закрыт, для мержа нужны апрувы и зелёные обязательные проверки, например ./gradlew assembleDebug testDebugUnitTest lint и detekt или ktlint;
• auto-merge: в GitHub и GitLab PR ставится на автоматический мерж и вливается сам, как только пройдут проверки и ревью;
• merge queue: очередь слияния в GitHub или merge trains в GitLab прогоняют CI на результате слияния с актуальной main, а не на устаревшей базе ветки. Это и есть ответ про два зелёных PR;
• зависимости: Renovate или Dependabot открывают PR с обновлениями, патч-версии можно мержить автоматически после зелёного CI.

Для Android назовите типичные места конфликтов: libs.versions.toml, build.gradle.kts, AndroidManifest.xml, strings.xml.

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

Путают auto-merge на платформе с тем, как Git сам сливает непересекающиеся изменения при трёхстороннем слиянии. Это разные вещи, и их стоит развести.

Считают, что CI «автоматически сливает PR при создании». Без ревью и проверок это не автоматизация, а отключённый контроль.

Держат фича-ветку неделями и подтягивают main через git pull с мерж-коммитами. История превращается в кашу, а конфликт в конце всё равно большой. Помогают маленькие PR и регулярный git rebase.