Работали ли вы с GitLab и GitLab Flow
Что проверяют
Насколько вы самостоятельны в поставке: доводите изменения до окружения сами или передаёте кому-то. Вопрос сдвоенный, поэтому проверяют и работу с самим GitLab, и понимание модели ветвления, которую он предлагает.
Как отвечать
Про GitLab Flow скажите главное: это упрощение Git Flow без долгоживущей ветки разработки. Основная ветка одна, задача живёт в короткой ветке и приезжает через merge request, а окружения или версии представлены отдельными ветками. Изменения текут в одну сторону: сначала в основную ветку, потом в ветку окружения. Срочная правка тоже делается в основной ветке и переносится в релизную отдельным коммитом, иначе она пропадёт в следующем релизе.
Про CI покажите, что настраивали конвейер сами: стадии, кэш, артефакты, rules вместо устаревших условий, needs для параллельного графа, ручная джоба на выкладку, окружения с историей деплоев.
Для Go добавьте специфику, её и ждут: кэш модулей между запусками, go vet и линтер отдельной стадией, go test -race с профилем покрытия, сборка статического бинарника с отключённым cgo, многоступенчатый Dockerfile и версия внутри бинарника через флаги линковщика.
Где спотыкаются
Называют GitLab Flow, а описывают Git Flow: отдельная ветка разработки, релизные ветки, ветки исправлений. Модели разные, и путаница сразу показывает, что название пришло из статьи, а не из работы.
Не кэшируют модули и инструменты. Каждая джоба заново скачивает зависимости и ставит линтер, конвейер растягивается на десятки минут, и команда перестаёт дожидаться зелёного статуса перед слиянием.
Гоняют тесты без детектора гонок и на общем стенде. Пакеты в Go тестируются параллельно, поэтому общая база или фиксированный порт дают плавающие падения, которые лечат перезапуском джобы вместо исправления теста.