Нумерация релизов в рабочем процессе git - PullRequest
3 голосов
/ 23 апреля 2011

Я встречал следующий отличный пост в блоге о модели рабочего процесса git, которая работает с ветками выпуска, разработки, функций и исправлений: http://nvie.com/posts/a-successful-git-branching-model/

Звучит как отличный рабочий процесс, и я действительно хочу попробовать его в производстве, но один абзац привлек мое внимание и заставляет задуматься.

Именно в начале ветки релиза следующему релизу присваивается номер версии, а не ранее. До этого момента ветвь разработки отражала изменения для «следующего релиза», но неясно, станет ли этот «следующий релиз» в конечном итоге 0.3 или 1.0, пока не будет запущена ветвь релиза. Это решение принимается в начале ветки релиза и выполняется в соответствии с правилами проекта по изменению номера версии.

Мне интересно, как этот способ работы отражается в вашей системе создания билетов и отслеживания ошибок? В JIRA и BugZilla мы создаем «версии», к которым может принадлежать билет. До перехода на ветку релиза, к какой версии относится тикет в ветке разработки? У вас есть версия в вашем издателе для каждой ветки?

А как насчет функциональных билетов, которые, как вы знаете, вы собираетесь реализовать не в следующем выпуске, а в следующем выпуске? Должен ли я создавать версии "предстоящие" и "будущие" для этого вида билетов?

Любое понимание того, как этот рабочий процесс ветвления отражается в управлении тикетами / проблемами, приветствуется!

1 Ответ

2 голосов
/ 23 апреля 2011

Должен ли я создать версию "предстоящих" и "будущих" для этого вида билетов

Это основная идея.Ключевая идея заключается в том, что текущая разработка будет включать в себя часть функций в следующем выпуске, а некоторые - в конечном итоге будут слишком сложными и / или не готовыми вовремя и / или в зависимости от других функций, которые не появятся в следующем выпуске..
Это немного похоже на ветви 'pu' и 'next' в самом репозитории git .

Короче говоря, билет на функцию редко выдаетсяконкретный номер выпуска, в то время как билет исправления ошибки может быть (2.1 для исправления выпуска 2, например).

...