Question

I am looking for the best and safest way to convert a git branch to a git tag. When porting over a svn repository by hand, I basically copied over all our branches and we had a branch for each minor release (1.1, 1.2, 1.3) which in all honesty probably was not the best way of doing that but for the sake of speed, I was more comfortable with branches than tags at the time. I now have branches 1.5, 1.6, 1.7, 1.8 however since we only ever have 1 version of the code deployed at any given time, I probably only need the last version to be a branch incase any hot fixes need to go into that version that is deployed. So I am looking for the best way to convert a git branch to a git tag. I think I have a way but done sure how good it is.

What I have done so far is for each branch I want to convert to a tag, I have checked to make sure there are no commits in those branches that are not in the master branch, so I did:

git log 1.5 ^master
git log 1.6 ^master
git log 1.7 ^master

All of these return me nothing which I believe means all of the commits in those branches exist in master. I did this because I assumed if there were commits in those branches that were not in master, I would lose them when converting the branch to a tag as a tag is just a “pointer” to one commit and not a development line. With that seeming good, my assumption is that I would just have to do:

git tag 1.5v 1.5
git tag 1.6v 1.6
git tag 1.7v 1.7

Then I would just have to delete the branches locally and push those changes to the remote repository. Is this the best way of converting a git branch to a git tag?

Also one concern I have is if someone created a branch from say 1.7 (which no one should of) and they pull the changes that delete that branch, would they be able to merge those changes into another branch (say master) or would that kind of break the branch they created? This is a case that should not happen since no one should be created branches off of any branch version other than the version last one, in this case 1.8, but people do not always following procedure properly so I want to make sure there is a way to fix this if it happens.

Answer 1

Short answer: it’s not a problem. And creating tags the way you propose is okay, although I suggest you use the -m option to create an annotated tag with a comment (see man git-tag), as this will create a “first class” tag that will be used by git describe etc. without additional arguments.

Long answer:
Remote branches will not affect the local branches directly. If I create a branch from a branch or a tag from your public repo, when you delete that branch, and I fetch your repo, I will see that your branch is gone, but my branch is still complete in my repo.

Brances are only symbolic names for the a commit in a git repo, when you commit the HEAD and the branch you’re working on points to the new commit. A tag is also a symbolic name for a commit, but this is not changeable (you can delete it, though, but it cannot be changed), so it points to a fixed location in the history, while a branch point to the moving head of one line in the history. Since commits in git have zero, one or more parent commits (zero for initial commit, one for a normal commit, more than one for a merge), even if the original branch or tag is deleted from the remote your local repo still have a pointer to you local branch and from this you can find a common ancestor (assuming the branches are related in the first place), so you can still merge in changes done to any of your branches into master.

Coming from svn to git can be a bit confusing at first. It sounds like you’re still thinking in svn terms, making everything more confusing. I think it’s easier if you think of git more as an advanced filesystem (which is what Linus Torvalds were when he wrote it), instead of a source control tool. I also suggest you take some time to read (or skim through) git for computer scientists, it’s not as daunting as it sounds; and having a better understanding of how it actually works will help you thinking the “correct way”. 😉