Appropriate strategy for tagging and hotfixing with git

Question

I was wondering if the strategy I'm using for tagging and hotfixing tags (which then I use for deploying rails applications) with git is appropriate.

For tagging I just tag a commit of the master trunk.

If it happens I have to hotfix the tag, I'm checking out the tag (e.g. 1.0), fix the issue, commit it and re-tag it (e.g. 1.0.1). Now, if I have to do another fix on the tag, I repeat the procedure, using as first checkout the tag of the first hotfix (e.g. 1.0.1).

Now, I noted two things: 1. when I checkout the 1.0.1, I get a warning saying I'm not in branch - I assume that it's ok, but is it appropriate as strategy? 2. when I try to deploy the 1.0.2, I receive an error from capistrano (tool used for deploying rails apps) during the code update from the remote repository, saying that it can't find the object [commit of 1.0.2]. I can correct this problem checking out the master and merging 1.0.2.

Of course, I'm always pushing the tags to the repository.

Is there anything wrong/inefficient/inappropriate, or this is an appropriates strategy? I'm completely new to git and I couldn't find around a great deal of information about the deployment strategies generally used.

Answer 1

From the tag 1.0, you need to make a branch

 $ git checkout -b hotfix1.0

on which you can go every time you need to make a fix, and on which you can make a tag (1.0.1, 1.0.2, ...) every time you need to deploy.

Working on a detached HEAd is not optimal, because that commit can be pruned later on. If you are on a detached HEAD and have made some modifications, you can always merged them with a given branch:

 $ git checkout -m hotfix1.0

I would not recommend making a branch for each hotfix you need to make for the 1.0 version of your program: one branch should be enough for that purpose, with tags along the way to mark significant modifications worthy to be published.