Представим себя на месте разработчиков многолетней давности, которые пишут на PHP и у которых разработка и продакшен находятся на одном сервере. И более того — в продакшен выполняется ровно тот же код, над которым мы работаем.
Примерно так выглядят условия, в которых возникает проблема: продакшен и разработка ме��ают друг другу. И эту проблему нужно решать изоляцией их друг от друга.
Мы можем сделать две директории — develop и prod, написать скрипт deploy.sh и запускать его при релизе. Наткнувшись на ошибки и потребность в откате, начнём бэкапить текущий продакшен перед релизом новой его версии. После проблем, требующих откатиться к какому-то из прежних состояний, начнём хранить несколько последних бэкапов и придумывать для них систему имён, чтобы не запутаться.
Если у нас есть git, то конечном итоге мы заметим, что эту проблему можно решить с его помощью, разделив процессы разработки и продакшена с помощью веток, а для деплоя используя мёржи и черипики. Ибо git уже умеет многое из того, что мы изобретаем.
Так мы и переизобрели gitflow.
Но обратим внимание на условия, в которых этот подход действительно актуален:
Разработка и продакшен находятся на одном сервере и в одной директории.
Используется интерпретируемый язык программирования — код выполняется в том виде, в котором написан.
Сегодня разработку и продакшен на одном сервере не держат даже для pet‑проектов. Существуют бесплатные тарифы на GitHub, GitLab и других платформах, которых хватает даже для промышленной разработки.
Если у нас компилируемый язык или разработка и продакшен находятся на разных серверах — у нас нет таких проблем и нет причин их решать. Следовательно, нам не нужен gitflow.
Если мы всё же называем то, что у нас стихийно сложилось именем «gitflow» только на основании того, что у нас есть ветка develop, то у нас есть проблема совсем в другого рода — это проблема нашего непонимания того, что должно вызывать рабочую активность, и поэтому мы делаем «как у всех», а не то, что требуется рабочими обстоятельствами.
