Как обычно организован процесс слияния кода в прод — есть ли промежуточная ветка (например, develop) перед релизом?

Зачем нужна промежуточная ветка

Процесс слияния кода в прод обычно не сводится к прямому merge в main. Промежуточная ветка, например develop, служит буфером между активной разработкой и стабильным релизом. Это позволяет команде накапливать изменения, тестировать их вместе и только потом выпускать в продакшен.

Классический Git Flow

В Git Flow есть две постоянные ветки: main (или master) — всегда отражает состояние продакшена, и develop — интеграционная ветка для ежедневной работы. Когда наступает время релиза, от develop создается release-ветка (например, release/1.2.0). В ней исправляют баги, обновляют версию и документацию, но не добавляют новые фичи. После стабилизации release-ветка сливается в main и помечается тегом, а также обратно в develop, чтобы изменения попали в основную линию разработки.

Пример команд

git checkout develop
git pull origin develop
git checkout -b release/1.2.0
# стабилизация: исправления багов, обновление версии
git commit -m "Release 1.2.0"
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Version 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

Альтернативы

В более простых проектах используют GitHub Flow: только main и feature-ветки, релиз происходит сразу после merge в main. Но если нужен строгий контроль над релизами, Git Flow или его упрощенная версия с develop-веткой — стандартный выбор.

Вывод

Промежуточная ветка перед продом помогает изолировать подготовку релиза, упрощает откат и дает время на финальное тестирование. Это особенно полезно в командах с регулярными релизами и несколькими параллельными фичами.