Question

When using the Feature Branch workflow with a small team (not Gitflow), is there a convention for applying a hot fix to a release that was previously tagged on master?

For example:

  1. v1.0.0 is released at a particular point in time, at which time a tag is created.
  2. Developers continue to work on feature branches which are merged into master upon completion and review in preparation for a distant future release of v1.1.0.
  3. Customers begin experiencing an issue, and it is deemed necessary to release a hotfix to v1.0.0 (call it v1.0.1) leaving out the progress made for v1.1.0.

With Gitflow, the branching structure is obvious, since master is only made up of the tagged releases -- branch from master, fix, merge fix into master, release and tag from master. With the Feature Branch workflow, I'd like to know how this is typically handled, preserving an easy-to-follow history.

Was it helpful?

Solution

One option is to make the hotfix in a branch, tag it in the branch, and then merge the branch into master. That way, you still wind up with the fix available both for the hotfix release and for future releases, but the tag for the hotfix isn't part the first-parent chain of master.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top