git 工作流程中的版本编号
我发现了以下关于 git 工作流程模型的优秀博客文章，该模型适用于发布、开发、功能和错误修复分支：http://nvie.com/posts/a-successful-git-branching-model/
这听起来像是一个出色的工作流程，我真的很想在生产中尝试它，但是一个段落引起了我的注意并让我感到好奇。
正是在发布分支的开始处，即将发布的版本被分配了版本号，而不是更早的版本号。直到那一刻，开发分支反映了“下一个版本”的变化，但在发布分支启动之前，尚不清楚“下一个版本”最终会变成 0.3 还是 1.0。该决定是在发布分支开始时做出的，并根据项目的版本号碰撞规则执行。
我想知道这种工作方式如何反映在您的票务和错误跟踪系统中？在 JIRA 和 BugZilla 中，我们创建票证可以所属的“版本”。在切换到发布分支之前，工单在开发分支中属于哪个版本？您的问题跟踪器中是否有每个分支的版本？
如果您知道您不会在即将发布的版本中实现，而是在之后的版本中实现，那么功能票据又如何呢？我是否应该为此类门票创建“即将推出”和“未来”版本？
任何有关此分支工作流程如何反映在票证/问题管理中的见解都将受到赞赏！
I've come across the following excellent blogpost on a git workflow model that works with release, develop, feature and bugfix branches: http://nvie.com/posts/a-successful-git-branching-model/
It sounds like an excellent workflow and I am really eager to try it in production but one paragraph caught my attention and leaves me wondering.
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.
I'm wondering, how does this way of working reflect in your ticketing and bugtracking system? In JIRA and BugZilla we create "versions" that a ticket can belong to. Prior to switching to a release branch, what version does a ticket belong to when in the development branch? Do you have a version in your issuetracker for every branch?
And what about feature tickets that you know you are going to implement not in the upcoming release but in the release thereafter? Am I supposed to create a version "upcoming" and "future" for this kind of tickets?
Any insight in how this branching workflow reflects in ticket/issue management is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是基本想法。关键的想法是，当前的开发将包括下一个版本中的一些功能部分，以及一些最终会过于复杂和/或未及时准备好和/或取决于其他功能而不会在所述下一个版本中出现的功能。 .
这有点像 分支 '
pu< git 存储库本身中的 /code>' 和 'next'。简而言之，功能票证很少发布到特定的版本号，而错误修复票证则可以（例如，2.1 用于修复版本 2）。
This is the basic idea. The key idea is that a current development will include some features part if the next release, and some which will ultimately be too complex and/or not ready in time and/or depending on other features which won't make it in said next release.
This is a bit like branches '
pu' and 'next' in the git repo itself.In short, a feature ticket is rarely issued to a specific release number, while a bug fix ticket can be (2.1 for fixing release 2 for instance).