git工作流程中的发布编号

| 我在git工作流程模型上遇到了以下出色的博客文章,该模型可与发布,开发,功能和错误修正分支一起使用:http://nvie.com/posts/a-successful-git-branching-model/ 这听起来像是一个很棒的工作流程,我真的很想在生产中尝试一下,但是有一段引起了我的注意,让我感到疑惑。   正是在发行分支的开头,为即将发布的发行版本分配了一个版本号,而不是更早的版本号。直到那一刻,develop分支都反映了“ next release”的更改,但是直到“ release”分支开始运行之前,“ next release”是否最终变为0.3或1.0还不清楚。该决定是在发布分支的开始时做出的,并且由项目的版本号增加规则来执行。 我想知道,这种工作方式如何反映在您的票务和错误跟踪系统中?在JIRA和BugZilla中,我们创建票证可以属于的“版本”。在切换到发行分支之前,票证在开发分支中属于哪个版本?您的Issuetracker中是否为每个分支都有一个版本? 那么,您知道将在即将发行的版本中而不是在即将发行的版本中实现的功能票又如何呢?我是否应该为这种票创建一个版本“即将来临”和“将来”? 对此分支工作流如何反映在票证/问题管理中的任何见解都将受到赞赏!     
已邀请:
  我是否应该为此类票创建一个版本“即将来临”和“将来” 这是基本思想。关键思想是,如果下一个版本发布,当前的开发将包括一些功能部件,而某些功能最终将过于复杂和/或未及时准备就绪和/或取决于其他功能,而这些功能在下一个版本中均未提及。发布。 这有点像git repo本身的分支\'
pu
\'和\'
next
\'。 简而言之,功能票证很少发布到特定的发行版号,而错误修复票证可以是(例如,用于修复发行版2的2.1)。     

要回复问题请先登录注册