Branch/master tag revision increments using Git

Question

I'm trying to nail down a good system for release management, combined with the tagging practice of tagging with version numbers - for example, 1.0. Any changes after that tag will be incremented, like 1.0-1, 1.0-2, etc.

However, if I create a new branch from master for 1.0 release, and then I switch to that branch and tag it 1.0, the system as mentioned above works fine. Additional bug fixes on that branch show as expected, 1.0-1, 1.0-2

However, any work on the master, unless I re-tag the master after the first commit after making the 1.0 branch, will also show the same increment: 1.0-1, 1.0-2

Granted, the sha1 hashes will be unique, but I'd end up having the same revisions/increments from both master and branch.

Is there any way to avoid master from being tagged at all when I just tag the branches? Is there any better way of doing this? Right now, my only option after making branch 1.0 is make one minor commit on master, and then re-tag it for 1.1-dev or something.

Then repeat for each release.

However, if a branch is then tagged again, say for 1.0.1 release, that too seems like it would also tag master since that's what happened first?

Answer 1

In Git you don’t tag branches. You tag commits. If you want to “mark” a branch you already got that: the name of the branch. :)

Yes, git describe gives you commit identifiers like 1.0-2-g1ab3183 but those are not tags! Tagging is done with git tag (who’d have guessed), and the tags that are created using git tag are the base for the commit identifiers git describe creates.

Answer 2

In git a tag is an alias for a specific commit, not for a branch.

Tags and branches are independent.

So if you want to checkout a specific version to do a minor rev on it then you could do:

git checkout -b new_branch_name commit_id

Or,

git checkout -b new_branch_name tag_name

Both are simply equivalent ways of referring to a specific commit.

Make your changes, commit them and tag the commit with the minor rev.

You could then even delete the branch that you checked out.

Answer 3

In Git you cannot say that some commit belongs to some branch. Single commit can be on more than one branch; if commit A is one of ancestors of tip of branch, we say that it is on given branch.

As Bombe said in Git you don't tag branches. You tag commits. In Git tag is just (annotated) pointer to a commit.

In your case you have, I think, something like the following

                        /-- [v1.0]
                       v
---.---.---.---X---.---A     <-- master
                         \ 
                           \-.---B     <-- maint

Let's commit 'X' be comit pointed by tag 'v1.0'. This commit is both on branch 'master' and on branch 'maint'. If you run "git describe" on top of commit 'A' (top of 'master' branch) you would get something like v1.0-2-g9c116e9. If you run "git describe" on top of commit 'A' ('maint' branch) you would get something like v1.0-2-g3f55e41 (at least with default git-describe configuration). Note that this result is slightly different. v1.0-2-g9c116e9 means that we are at commit with sortened SHA-1 id of 9c116e9, 2 commits after tag v1.0. There is no tag v1.0-2!

If you want for tag to appear only on branch 'master', you can create new commit (e.g. only update default / fallback version information in GIT-VERSION-FILE) after branching point of 'maint' branch. If you tag commits on 'maint' branch with e.g. 'v1.0.3` it would be visible only from 'maint'.

HTH