I've adopted a tagging system of x.x.x.x, and this works fine. However, you also need to leave a comment with your git tag. I've been using descriptions such as "fixes bug Y" or "feature X", but is this the best sort of comment to be leaving? Particularly, what if a tag encompasses several fixes, it seems not to make sense to have a very long tag comment. Does this mean that I should be creating a tag for every bug fix or feature, or should the tag comments be reflective of something else? I have a few ideas that may be good, but I'd love some advice from seasoned git tagging veterans 🙂
For those who prefer specific examples:
1.0.0.0 - initial release
1.0.0.1 - bug fix for issue X
1.0.0.2 - (what if this is a bug fix for multiple issues, the comment would be too long, no?)
Another example, in this example, the comments are more or less the same as the tags, it seems redundant. Is there something else we could be describing?
Best Answer
A tag should be created for significant commits — something meaningful. This is a bit open-ended, but most times a tag corresponds to a release, and this is why you tend to see tags like
v1.3.5.X
or1.4.0.X
. You should not be creating release tags for commits that are not actually releases.Comments on release tags should give you a short description of what is included in that release, like an "elevator pitch" or "executive summary." You can optionally include a link to the release notes for that release, but this can be risky if your project ever changes its URL. This can happen frequently with open source projects.
If the repository has a text file for the release notes, then your tag comments can refer people to that text file, which is a much more stable way to refer to this information.
An example release tag comment with new features and bug fixes:
An example release tag comment with just bug fixes:
Another example release tag comment outlining new features:
Short and sweet.
You can tag other significant commits that do not correspond to a release. If the tag name is descriptive enough, then don't add a comment:
If the tag name is not sufficient to explain why the tag exists, then add whatever comments are required in order to give team members come context. For example, let's say you created the
before_framework_migration
tag and added comments: