Поддержка релизов в Git, без головной боли. Как?

Question

[Anatoliy Lyovkin]

Есть проект, готовится релиз n. Задач, которые будут залиты в этот релиз осталось мало и тест затянется еще недели на две, но есть задачи которые войдут в релиз n+1, и естественно чтоб работа не останавливалась, то делаются задачи для релиза n+1. Собственно вопрос состоит в том, как это все поддерживать в Git с меньшей болью?
Пока есть вариант не мержить ветки для релиза n+1 и ждать релиза n, но веток за это время соберется штук 15-20 и будут конфликты при следующем мерже.
Или же создать две ветки release_n и release_n+1, потом ветка release_n сольется в мастер, а release_n+1 то ли рибейзить, то ли сливать в нее новые коммиты из мастера и мержить.

Answer 1

[Игорь Шевченко]

Мы тоже искали решение подобной проблемы и пришли к тому, что меньше всего боли нам доставляет вот такой модифицированный gitflow:

• Код на продакшн заливается из ветки master.
  
• Код на тестовый сервер заливается из ветки develop.
  
• Все задачи делаются в отдельных feature-бранчах. Важно, что feature-бранчи ответвляются от master.
  
• Разработчик, завершив работу над задачей, мёржит ветку этой задачи в develop.
  
• Вмёрженные в develop задачи заливаются на тестовый сервер, где их сможет проверить тестировщик.
  
• Когда приходит время релиза, feature-бранчи для всех задач, которые должны быть включены в него и успешно протестированы, мёржатся в master.
  
• develop никогда не мёржат в master, потому что там может быть непроверенный код с багами.
  

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

Этот workflow подойдет не всем, многое зависит от сложившихся в команде процессов. Но в ситуации, которая описана в вопросе, он должен помочь (возможно, с небольшими изменениями).

Answer 2

[entermix]