Skip to content

Instantly share code, notes, and snippets.

@adonaldson

adonaldson/gist:1205902

Created September 9, 2011 10:23
Show Gist options
  • Star 10 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save adonaldson/1205902 to your computer and use it in GitHub Desktop.
Save adonaldson/1205902 to your computer and use it in GitHub Desktop.
Download ZIP
Fixing a bug in a tagged release
Raw
gistfile1.txt
I have a process for fixing bugs in tagged releases, but it always seems such a faff. This makes
me think I'm doing it wrong. So imagine this scenario:
- I tag a release (v1) and push it onto staging
- I continue work in master
- Client comes back with an issue on v1
- I create a branch based off v1
- I fix the bug
- ...
What is the best process from here on out?
What I (think I) want:
- To retag the v1 bugfix branch (as v1.1) and deploy it to staging
- For my v1 bugfix to be rolled into master
What process do you follow?
@djcsdy
Copy link

djcsdy commented Sep 9, 2011

Your process sounds reasonable to me. It think that working with stable and development branches is inherently a bit of a faff. It’s the price you pay for stability combined with continuous development. Just be glad you aren’t using Subversion, which makes the process absolutely excruciating.

What I would tend to do is roughly:

git tag release-1.0 # tag version 1.0
# (continue to work in master)
# (time passes)
# (client reports bug in version 1.0)
git checkout -b series-1.x release-1.0 # create and check out 1.x release branch
# fix and commit bug
git tag release-1.1 # tag version 1.1, assuming we’re immediately doing another release
git checkout master # switch back to master
git merge series-1.x # merge fix into master

You could also fix the bug in master first and cherry-pick it into the branch, but the trouble with that is that cherry-picks aren’t recorded in the history as merges because they’re non-linear. IMHO, you only want to do it that way round if you happen to have already fixed the bug in master when the client reports it.

You can reduce the amount of faffing by merging from the stable branch into master on a regular interval (say, once a day, or whatever’s appropriate to the amount of development that’s happening on the stable branch), instead of doing a merge once for every change. If you’re personally doing a lot of development on both branches then you probably also want to keep two separate checkouts, instead of constantly switching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment