Пожалуйста, дайте мне знать, какой подход правильный ...
Нет правильного подхода, но некоторые лучше, чем другие.
... и будет иметь минимальное требование к объединению.
Как ни парадоксально, вы хотите, чтобы ветвление и слияние больше часто, но с меньшими изменениями.
Долгоживущие ветви, которые накапливают множество изменений, накапливают сложность, затрудняя их контроль, управление и объединение. Месяцы между выпусками также накапливают множество функций, которые должны быть добавлены пользователям одновременно. Все это делает процесс слияния, интеграции и выпуска медленным и сложным.
Тогда у вас сейчас такая проблема: у вас есть неполная, большая октябрьская ветка выпуска. График выпуска был включен в процесс разработки. Теперь вас просят выпустить августовский выпуск, что вы делаете со всем этим кодом в октябрьской ветке? Это негибко.
Вместо этого имейте одну долгоживущую ветвь, на которой все разработано. Разрабатывайте функции индивидуально в изолированных, недолговечных ветвях функций. QA их до слияния. Это дает вам одну долгоживущую ветвь, которая всегда готова к выпуску.
Это может выглядеть примерно так.
I - J L - M - N [feature1]
/ \ /
A - B - C ----- F - G ----- K [master]
\ / \
D - E O - P [feature2]
Здесь показаны две завершенные функции, D - E и I - J, которые уже прошли QA и были объединены в master. Поскольку QA уже был выполнен в ветвях компонентов, master развернут в производство. Есть две открытые ветки. Разработчики этих веток периодически запускают git rebase master, поэтому они в курсе последних полностью проверенных кодов master. Это упрощает процесс слияния, всегда сохраняя их ветвь на кончике master и обрабатывая конфликты постепенно, а не большим фрагментом в конце.
Обратите внимание, что нет прямых коммитов для мастера, они изменяются только через слияние ветвей функций. Это означает, что мастер всегда проверен, надежен и готов к развертыванию. Отдельные выполняемые функции не мешают друг другу и могут полагаться на стабильную главную ветвь; если что-то ломается, они знают, что это из-за их работы, а не потому, что кто-то сломал ветку dev.
Теперь вы можете отпустить, когда захотите, master всегда готов к работе. График выпуска и процесс разработки не зависят друг от друга. Вы можете развертывать с master по заданному расписанию или сразу после объединения.
Вы работаете над функциями октябрьского выпуска в виде отдельных веток и QA и объединяете их. Если происходит внезапное изменение приоритета, например, набор функций для августовского выпуска, вы переключаетесь на эти функции, как и раньше. Когда наступает крайний срок в августе, master готов к работе и развертывается.
Если в августе есть функции, которые вы не хотите развертывать, оставьте код в августе, но отключите его с помощью переключателя конфигурации.
Это позволяет избежать необходимости управлять несколькими долгоживущими ветвями с параллельными изменениями и слиянием между ними. Вместо этого у вас есть несколько кратковременных ветвей для каждой функции. Если вы хотите отслеживать, что было развернуто, используйте теги, а не ветви.