3

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

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

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

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

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

任何有关此分支工作流程如何反映在工单/问题管理中的见解都值得赞赏！

4

1 回答 1

2

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

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

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

于 2011-04-22T22:43:30.510 回答