CODEWITHSUNDEEP
git
SkyWalker
SkyWalker

Reputation: 14309

Git hotfixing existing tags/releases?

Suppose I roll a new version to production e.g. 1.0 using git tagging and continue working on master. What happens if I need to hotfix the 1.0 tag? I clone/fetch 1.0 and then add commits to it for the purpose of bug fixing, but isn't tagging simply a marking facility only? when I push my delta 1.0+ commits which branch do they go to?

The same use-case in SVN I would have two separate branches 1.0 and trunk and it is clear that 1.0 can diverge on its own (and then merge to trunk) but in git it is not so clear to me how this works.

Upvotes: 1

Views: 1775

Answers (2)

Andreas Wederbrand
Andreas Wederbrand

Reputation: 39981

So, the short answer (that takes some time to read) is to adopt Vincent's Git Flow model. It works really great as a starting point when first staring out with git. If nothing else it's a good read to understand more about git.

That being said. Here is how I would do it

  • checkout the tag and convert it to a branch (if such doesn't already exists)
  • make the changes and test them, retag with 1.1 (or similar)
  • release
  • merge (or cherry-pick if thats your flavour) into master to keep future releases (2.0) also have the bug fixes.

Upvotes: 3

Robin Green
Robin Green

Reputation: 33063

It is actually quite similar to SVN.

Tags are permanent - they are used to identify releases. (On Github, this is not just a convention - that is how releases are actually identified and served up.)

For bug fixes to a release, you need to use some kind of branching convention. What kind of branch convention you use is up to you, but a common one is:

master    <-- development branch, for the next release
|--1.0       <-- bug fixes to 1.0

So create a 1.0 branch starting from the 1.0 tag, and make your bug fixes on that branch, I suggest.

Upvotes: 1

Related Questions