2

I'll preface this with I'm fairly new to git, having migrated from a SVN background. I've been using a git-flow based workflow and tagging releases with a numerical standard like v0.2.0

Tonight I went to deploy from my sandbox to main site and noticed that if I did a git checkout -b tags/v0.2.2 that it actually pulled that latest commit from the master branch. But if I check out the same tag in a detached head state i.e. git checkout /tags/v0.2.2 it checks out from master based on the proper commit.

[ calllog]$ git branch
* master
[ calllog]$ git checkout tags/v0.2.2
Note: checking out 'tags/v0.2.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d5b4c5e... Merge branch 'feature/password' into develop
[ calllog]$ git describe
v0.2.2
[ calllog]$ git checkout master
Previous HEAD position was d5b4c5e... Merge branch 'feature/password' into develop
Switched to branch 'master'
[ calllog]$ git checkout -b tags/v0.2.2
Switched to a new branch 'tags/v0.2.2'
[ calllog]$ git describe
v0.2.4-5-gb2cfa6a

This behavior only seems to happen when checking out a tag that is not the most current

[calllog]$ git tag
v0.1.1
v0.1.2
v0.1.3
v0.1.4
v0.2.0
v0.2.1
v0.2.2
v0.2.3
v0.2.4

Am I missing something or is this normal behavior? What's the recommended paradigm for promoting from a git-flow tag based workflow into your production environment?

Jchieppa
  • 126
  • 1
  • 2
  • 9

2 Answers2

2

What I'm unclear about is why a git checkout -b tags/v0.2.2 creates a new branch that references the most current commit of master (as shown above in the original question)

Because that is interpreted as the name of the new branch you are creating with that command git checkout -b:

git checkout -b <new_branch> [<start_point>]
git checkout -b tags/v0.2.2

Since you don't specify the "start point", git takes the current one (where HEAD is)

Remember that it is possible to have hierarchical branch names (branch names with slash).

If you want to create a new branch based on a tag, then:

git checkout -b newBranchName v0.2.2

And you won't be in a detached HEAD (as explained in "Checkout GIT tag").
You will be on newBranchName, based on tag v0.2.2.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I didn't do a `git checkout -b /tags/v0.2.2` that was a typo which I've corrected above. I understand why a `git checkout tags/v0.2.2` checks it out in a detached state. What I'm unclear about is why a `git checkout -b tags/v0.2.2` creates a new branch that references the most current commit of master (as shown above in the original question) when it's the accepted answer in [link](http://stackoverflow.com/questions/5582208/checkout-git-tag)? The idea of checking out a tag in a detached head is fine in theory, but eventually a commit or worse a roll back to prior version is usually needed. – Jchieppa Jun 11 '14 at 16:37
2

[ calllog]$ git checkout -b tags/v0.2.2

Here's your problem. checkout -b says make a "new branch for what I'm checking out" and the next arg is the new branch's name. You can see it in the response to that command:

Switched to a new branch 'tags/v0.2.2'

You gave it the new branch name, and it made it, but you didn't actually checkout a branch. git treats a no-branch checkout as "a glorified no-op with a rather expensive side-effects to show only the tracking information, if exists, for the current branch" so your new branch is based off your current checkout.

So why do a no-branch checkout that way at all? Because most branches are off the current checkout.

What you want is

git checkout -b $newbranch v0.2.2

(edit: I see your tags don't have that tags/ prefix, you want the new branches based on them to have that prefix. fixing.)

jthill
  • 55,082
  • 5
  • 77
  • 137
  • @VonC The first two paragraphs of that answer are wrong, the third, the first one that addresses his question, tells him to do something that won't create a new branch, which is plainly what he wants. I bailed at that point. I didn't even see you wrote it, that's not like your usual answers. – jthill Jun 11 '14 at 17:49
  • Ok, I removed the old answer based on the original question (before edits by the OP). You will find the rest (the part where "you bailed") "like my usual answer", and quite similar to yours. Anyway, +1 for explaining the no-op part. Always a pleasure to read your instructive answers. – VonC Jun 11 '14 at 17:57
  • Thanks! +1 for yours because you've got the right lead, I buried mine, and back atcha. – jthill Jun 11 '14 at 18:12