Tag for release branch on both develop and master branch?

Question

I am trying to determine the best way to finish-off a release branch in git. I would like to take it so we could easily go back if we need to. So when I do my merge to the develop branch I create a tag and push it to the remote like so:

Tag this release
$ git tag -a "v1.6" -m "Release v1.6"
Push to remote
$ git push origin develop --follow-tags

Which appears to work great. However, I also need to merge to master and would like to take it there for the same reason. When I attempt to create the tag on release I obviously get a conflict. So, up to now I have been creating a tag like so:

$ git tag -a "v1.6-master" -m "Release v1.6"

This works fine but it seems like there should be a way to just create a tag and be able to checkout that tag on whatever branch you happen to be on. I feel like I am missing something essential.

Answer 1

but it seems like there should be a way to just create a tag and be able to checkout that tag on whatever branch you happen to be on. I feel like I am missing something essential.

If you mean you think you're missing the way to make tags behave as you describe... you're not. There isn't one. So I guess what's missing is a full understanding of how tags, branches, and commits relate in git.

A tag is a ref - a pointer to a specific commit. A branch is also a ref, but it happens to be a ref that is expected to move in a particular way.

People often want to talk about commits or tags being "on" a particular branch; this isn't really a thing in git (unlike other version control systems). A branch points to one commit, and other commits are reachable (by parent pointers) from that commit, and a tag might point to a commit that's reachable from a branch ref... but that's as far as that goes. If your commit topology conforms to certain assumptions, then you can approximate the notion of "a tag on a branch" by saying that the tag points to a commit reachable from the branch and not reachable from the parent branch - but you'd be using a bunch of concepts that git doesn't care about (including the notion of a "parent branch").

In fact, when you check out a tag, you put yourself in detached head state - which means you're not on any branch anymore.

I guess git could define a data structure that points to one commit per branch, but it doesn't.

So if you want "version x" tags on multiple commits, then what you're doing (using naming conventions to keep multiple tags straight) is the best you can do. But I would also echo the sentiments of those who suggest the "release tags on develop" aren't as useful as you might expect.

Answer 2

Tag for release branch on both develop and master branch

No. Tag release on master only. develop branch for development, it is unstable.

1 tag mapping with only 1 commit hash-string, if one, two or more branches has the commit hash-string, tag will sit in these branch(es).

Answer 3

With Git, it is a commit, not a branch, that gets tagged. Depending on your workflow, the same commit could exist in both master and develop . However, given you have those two branches, it is likely that a (merge) commit to master signifies a release. In that case, the proper thing to do would be to tag that merge commit to master .

Answer 4

Sounds pretty similiar to git flow. Did you have a look on it already?

• http://nvie.com/posts/a-successful-git-branching-model/
• https://danielkummer.github.io/git-flow-cheatsheet/index.de_DE.html
• https://github.com/petervanderdoes/gitflow-avh

The first two are the original branching model. The last one is the current development that you can also find in your favorite linux repository. It adds support branches for older versions that you need to support obviously.

Answer 5

Git tags and branches are extremely lightweight notions, the only ( only ) ( only ) model you should have of a git history is the ancestry dag and references (tags, branches, what have you) to currently-particular commits in it.

Why bother tagging a commit you can find just as (more, actually) reliably without the tag? You're after the last commit that was merged from develop into v1.6:

merge=`git rev-list v1.6 --grep="Merge branch 'develop'" --merges -1`

will get you that merge, and

git log -1 $merge^2

will get you the merged commit.