Я встречал следующий отличный пост в блоге о модели рабочего процесса git, которая работает с ветками выпуска, разработки, функций и исправлений: http://nvie.com/posts/a-successful-git-branching-model/
Звучит как отличный рабочий процесс, и я действительно хочу попробовать его в производстве, но один абзац привлек мое внимание и заставляет задуматься.
Именно в начале ветки релиза следующему релизу присваивается номер версии, а не ранее. До этого момента ветвь разработки отражала изменения для «следующего релиза», но неясно, станет ли этот «следующий релиз» в конечном итоге 0.3 или 1.0, пока не будет запущена ветвь релиза. Это решение принимается в начале ветки релиза и выполняется в соответствии с правилами проекта по изменению номера версии.
Мне интересно, как этот способ работы отражается в вашей системе создания билетов и отслеживания ошибок? В JIRA и BugZilla мы создаем «версии», к которым может принадлежать билет. До перехода на ветку релиза, к какой версии относится тикет в ветке разработки? У вас есть версия в вашем издателе для каждой ветки?
А как насчет функциональных билетов, которые, как вы знаете, вы собираетесь реализовать не в следующем выпуске, а в следующем выпуске? Должен ли я создавать версии "предстоящие" и "будущие" для этого вида билетов?
Любое понимание того, как этот рабочий процесс ветвления отражается в управлении тикетами / проблемами, приветствуется!