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?

Pavior

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.

Engenia

I completely understand what tags, branches, etc are, and how they're used. The problem is when you add a new tag to an existing branch. Let's say I create a support branch for 1.0 - master continues on with new features, etc. Bugfixes for 1.0 happen on that specific branch. Let's say I want to tag that or re-branch/tag again for release 1.0.1. If I tag that revision on any branch, then my MASTER starts showing 1.0.1-1, 1.0.1-2, when I only intended to tag the branch the commit occurred on. I don't want master and branches sharing tags like that. – Pavior

Do you mean git describe shows 1.0.1-1, -2, etc? Because it should not be influenced by tags that are not an ancestor of the current commit (and it shouldn’t be if it’s on another branch and you have committed to both branches). – Engenia

Answer 2

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 the commit pointed to 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

Antares

I guess I'm just not being clear enough. I'm aware of everything you and the others have said, but my problem is if I create a new tag while on a branch, git describe on the master will begin to reflect that new tag. Essentially, I could end up with two 1.0-1, 1.0-2, 1.0-3 versions in both the branch and the master, when in reality, they represent two different releases that should be more like 1.0-1, 1.1-dev-1, etc. I think my only way around this is to just re-tag the master after doing one commit, after making a branch for a release. – Pavior

That would happen only if tagged comit is available also from 'master' (is among ancestors of 'master'). – Tache

Don't use 1.0-1 from git-description; tag maintenance releases with 1.0.1 – Tache

Answer 3

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.

Robtrobust