issue-tracking - git 工作流程中的发布编号

Question

我看到了以下关于与发布、开发、功能和错误修复分支一起工作的 git 工作流模型的优秀博文:http://nvie.com/posts/a-successful-git-branching-model/

这听起来是一个很棒的工作流程，我真的很想在生产中尝试它，但有一段引起了我的注意并让我感到疑惑。

It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

我想知道，这种工作方式如何反射(reflect)在您的票务和错误跟踪系统中？在 JIRA 和 BugZilla 中，我们创建了票据所属的“版本”。在切换到发布分支之前，开发分支中的工单属于哪个版本？您的问题跟踪器中是否有每个分支的版本？

那么您知道您不会在即将发布的版本中而是在之后的版本中实现的功能票证呢？我是否应该为这种门票创建一个“即将到来”和“ future ”的版本？

任何有关此分支工作流如何反射(reflect)在工单/问题管理中的见解都将受到赞赏!

Answer 1

Am I supposed to create a version "upcoming" and "future" for this kind of tickets

这是基本思想。关键思想是，如果下一个版本，当前的开发将包括一些功能部分，而某些功能最终将过于复杂和/或未及时准备好和/或取决于其他不会在下一个版本中实现的功能.
这有点像branches 'pu' and 'next' in the git repo itself .

简而言之，功能票很少颁发给特定的版本号，而错误修复票可以是(例如 2.1 用于修复版本 2)。