Как происходит процесс слияния и тестирования в команде

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

Знаете ли вы, какие проверки стоят между вашим коммитом и основной веткой и почему именно в таком порядке. Следом часто спрашивают про стратегию ветвления и про то, чем merge отличается от rebase и squash.

Как отвечать

Опишите конвейер своей команды от ветки до релиза:

• ветвление: короткоживущие feature-ветки от main (trunk-based) или GitFlow с develop и релизными ветками. Чем дольше живёт ветка, тем больнее конфликты;
• merge request: main защищена, напрямую туда не пушат, нужны одно или два одобрения и зелёный пайплайн;
• CI на каждый пуш в MR: сборка Maven или Gradle, юнит-тесты на JUnit 5 и Mockito, интеграционные на Testcontainers с настоящими PostgreSQL и Kafka в Docker. В Maven юнит-тесты гоняет maven-surefire-plugin, интеграционные (*IT) обычно maven-failsafe-plugin;
• статический анализ: SonarQube с quality gate, Checkstyle или SpotBugs, покрытие через JaCoCo;
• способ слияния: squash даёт один коммит на задачу, rebase сохраняет линейную историю, merge commit оставляет ветку видимой;
• после слияния: сборка артефакта или образа, выкладка на стенд, регресс силами QA или автотестов, затем прод.

Важная мысль: тесты запускаются до слияния, на ветке, а не после ревью и тем более не после merge. Ревьюер смотрит на код, который уже собирается и проходит тесты, и тратит время на логику, а не на опечатки.

Расскажите про реальный случай: как ловили нестабильный тест, как решали конфликт миграций от двух веток, сколько идёт пайплайн.

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

Говорят, что тесты гоняет QA после выкладки на стенд. Это ручной регресс, он не заменяет автоматические проверки на каждом MR.

Мокают всё подряд, включая базу. Тест с мок-репозиторием не поймает ошибку в SQL или в маппинге Hibernate, для этого и нужен Testcontainers.

Не могут объяснить разницу между rebase и merge или делают rebase уже опубликованной общей ветки, переписывая историю коллегам.