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