我在git工作流模型上遇到了以下优秀博客文章，该模型适用于发布，开发，功能和错误修复分支：http://nvie.com/posts/a-successful-git-branching-model/
这听起来像是一个出色的工作流程，我真的很想在制作中尝试它，但有一段引起了我的注意，让我感到疑惑。
正是在发布分支的开始，即将发布的版本被分配了版本号 - 而不是之前的版本号。直到那一刻，开发分支反映了“下一个版本”的变化，但不清楚“下一个版本”最终是否会变为0.3或1.0，直到发布分支开始。该决定是在发布分支的开始时做出的，并且由项目关于版本号冲突的规则执行。
我想知道，这种工作方式如何反映在您的票务和错误跟踪系统中？在JIRA和BugZilla中，我们创建票证可以属于的“版本”。在切换到发布分支之前，在开发分支中，故障单属于哪个版本？您的issuetracker中是否有适用于每个分支的版本？
那么您知道要在即将发布的版本中实现但在此后的版本中要实现的功能票怎么办？我应该为这种票创建一个“即将到来”和“未来”的版本吗？
对于此分支工作流程在票证/问题管理中的反映方式的任何见解表示赞赏！
答案 0 :(得分：2)
我是否应该为这种门票创建一个“即将来临”和“未来”的版本
这是基本的想法。关键的想法是，当前的开发将包括一些功能部分，如果下一个版本，一些最终将太复杂和/或没有及时准备和/或取决于其他功能将无法在下一个版本中。
这有点像branches 'pu' and 'next' in the git repo itself。
简而言之，功能票很少发布到特定版本号，而错误修复票可以是（例如，2.1修复版本2）。