發佈在Git的工作流程編號

Question

我遇到的Git工作流模型與發佈，開發，功能和bug修正分行工作如下優良的博文：http://nvie.com/posts/a-successful-git-branching-model/

這聽起來像一個優秀的工作流程，我真的很渴望在生產中嘗試它，但有一段引起了我的注意，讓我感到疑惑。

恰好在發佈分支的開始處，即將發佈的版本被分配了一個版本號 - 沒有任何更早版本。直到那一刻，開發分支反映了「下一個版本」的變化，但是尚不清楚這個「下一個版本」是否最終會變爲0.3或1.0，直到發佈分支開始。該決定是在發佈分支開始時做出的，並且由項目關於版本號碰撞的規則來執行。

我想知道，這種工作方式如何反映在您的票務和錯誤跟蹤系統？在JIRA和BugZilla中，我們創建一張票可以屬於的「版本」。在切換到發佈分支之前，在開發分支中時，哪個版本屬於哪個版本？你在每個分支的issuetracker有沒有版本？

那麼你知道你要實現的功能票不是在即將到來的版本中，而是在之後的版本中實現？我是否應該爲這種票製作一個版本「即將到來」和「未來」？

對於這種分支工作流程如何體現在票據/問題管理中的任何洞察力，我們都非常感謝！

Answer 1

我應該爲這種票

這是基本的想法創建一個版本「即將到來」和「未來」。關鍵的想法是，當前的開發將包括一些功能部件，如果下一個版本，以及一些最終將過於複雜和/或未及時準備好和/或取決於其他功能（它不會在下一個版本中實現） 。
這有點像branches 'pu' and 'next' in the git repo itself。

簡而言之，功能票據很少發佈到特定的版本號，而錯誤修復權證可以是（例如2.1版，用於修復版本2）。