Home/ Questions/Q 4539750
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T14:59:23+00:00

I’ve come across the following excellent blogpost on a git workflow model that works

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

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

    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).

    • 0