git 工作流程中的发布编号答案

【问题标题】：Release numbering in a git workflowgit 工作流程中的发布编号
【发布时间】：2011-04-22 21:05:37
【问题描述】：

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

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

正是在发布分支的开头，为即将发布的版本分配了一个版本号——而不是更早的版本。直到那一刻，develop 分支反映了“下一个版本”的变化，但不清楚“下一个版本”最终会变成 0.3 还是 1.0，直到发布分支启动。该决定是在发布分支开始时做出的，并由项目的版本号调整规则执行。

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

您知道您不会在即将发布的版本中而是在之后的版本中实施的功能票呢？我应该为这种票创建一个“即将到来”和“未来”的版本吗？

如果您能深入了解此分支工作流程如何反映在工单/问题管理中，我们将不胜感激！

【问题讨论】：

【解决方案1】：

我应该为这种票创建一个“即将到来”和“未来”的版本

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

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

【讨论】：