CODEWITHSUNDEEP
gitgit-flow
ScaryAardvark
ScaryAardvark

Reputation: 2965

git-flow: how to handle version numbers from changes to released branch

I'm new(ish) to git and the company I work for are moving from subversion to git. We're looking at using the git-flow workflow and am reasonably happy with how this will work. However, I have one question regarding "point" releases from the release branch. Let me explain what I mean by this.

We decide to create a release so we create a new release branch, say 1.0. We continue development on the "develop" branch, adding new feature branches, etc. The 1.0 release is issued to our test team and they find issues with it. As I understand, these issues are supposed to be fixed on the release branch, 1.0 and then when testing is finished, all changes are merged from the release 1.0 branch to master and develop, and tagged on master as an official release.

Hopefully I've got this right.

Now, during the testing of release 1.0 we may need to provide the test team with a new point release, i.e. 1.1 which includes the changes we've made to fix their issues. We need it to be called 1.1 for traceability, i.e so we can ensure they're actually testing 1.1. However, git-flow seems to suggest that this should be a separate release branch, i.e. 1.1.

I guess the question I'm asking is how to we "mark" the release branch as 1.1 even though it is called 1.0.

I'm prepared to accept that I may be coming at this incorrectly given we've previously only worked with svn, and would welcome any clarifcation offered.

Upvotes: 0

Views: 3659

Answers (1)

harmonica141
harmonica141

Reputation: 1469

You are falling victim to a misconception regarding version numbers. When you want to release v1.0 there will always only be one version 1.0 which is the final release pushed to master being crowned with a version tag of its own.

How to get there? (Using the git flow helper scripts)

  • Develop a release candidate.
  • Branch off of develop into release/vx.x. (git flow release start [release])
  • Publish the rc: git flow release publish [release]
  • Do your testing. Every other developer can now track the release branch as usual. Every change will be made to release/vx.x directly (and merged back to develop for continued work on the next release already). Do not branch off of release/vx.x for any changes. This release keeps its number until its death.
  • When you are ready testing and debugging it is time for birth: Give the last (finishing) commit on release/vx.x a version tag and merge it to master (git flow release finish [release])
  • Push with tags: git push --tags

So in a nutshell a release owns one number and one only. Bugfixing happens on this very number just before giving it a tag (essentially rendering a rc a released version) but after creating the numbered branch.

Hotfixes for this release, happening after release, will be pushed to a hotfix branch and merged to the master and develop branch after testing in the same fashion.

You can always do everything of this by hand but there are the git flow helper scripts that can be used. These are available as Windows installer or in the default repositories of almost every Linux distribution. Have a look at the git flow repository here.

For further reference see the git flow cheat sheet, a good documentation by Atlassian and this awesome graphic.

Upvotes: 2

Related Questions