6

This is an example of how my git repo is right now:

v1.0    v1.1    v1.2
  |       |       |
  a   -   b   -   c
  |               |
master           HEAD

I usually commit, tag and push tags like this:

git commit -a -m "Commit msg"
git tag -a v1.3 -m "Tag msg"
git push --tags

The main problem I have is that the master branch doesn't move to the latest tag, so I'm always in a Detached HEAD state. Is there any way to fix this so the master branch will be always pointing to the latest pushed tag?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Peter
  • 359
  • 2
  • 4
  • 16
  • 2
    What is your workflow? Why are you always in a detached HEAD state? Why aren't you working on a branch? I think this is more a problem with your workflow than anything else. – John Szakmeister Dec 27 '12 at 12:38
  • 1
    If you don't check out a tag directly, this won't happen. Only make new commits after checking out a *branch*, never a *tag*. – cdhowie Dec 27 '12 at 13:18
  • To be able to generate package files in the repo I need to tag them, else they become 'a3fsr2' for example, thats why I need to use tags. – Peter Dec 27 '12 at 13:56

5 Answers5

9

In this particular case, I had to do the following:

  1. First set the master branch to point to the latest tag (where HEAD is pointing), because it is the most recent tag. To do so I created a new branch and merged master to it.
git branch -b exp
git merge -s ours master
git checkout master
git merge exp

Now master is the same as latest tag:

v1.0    v1.1    v1.2
  |       |       |
  a   -   b   -   c
                  |
                 HEAD
                  |
                master
  1. Once we have master back in place, we need to push both master and tags whenever we do a new commit:
git commit -a -m "Commit msg"
git tag -a v1.4 -m "Tag msg"
git push master --tags

This way we avoid being in a Detached HEAD mode and the master branch is updated.

SherylHohman
  • 16,580
  • 17
  • 88
  • 94
Peter
  • 359
  • 2
  • 4
  • 16
4

Various answers/comments already given about why to not do things this way, but here's how you fix this particular scenario:

git checkout -b tmpbranch       # creates a branch called tmpbranch at HEAD
git checkout master             # switch back to master branch
git merge --ff-only tmpbranch   # fast-forward merge master to tmpbranch, fail if not possible
git branch -d tmpbranch         # delete tmpbranch, it's not needed anymore

Then, going forward, don't check out a tag, except for this way:

git checkout -b somebranch refs/tags/tagname    # creates a new branch starting at tag

That way, you will not be in detached HEAD state, and any new commits will be added starting at the tag in question, which seems to be what you want... After making a commit you can git tag newtag to create additional tags at the right points.

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • The problem with this solution is that I would have a branch for every tag I have in the repo. – Peter Dec 29 '12 at 15:19
  • 1
    @Peter Only if your tags are all on separate lines of development, which it doesn't appear is the case from your original question. You would have one branch, like `master`, with a tag `v2.0` pointing to a recent commit on that branch, and earlier tags (e.g. `v1.9`, `v1.8` ....) pointing to earlier commits on that same branch. A branch is supposed to point to "what will be the parent of the next commit I make". The above `checkout` command is for when you need to check out an old(-er) tag in order to prepare a bug fix for it or something, not for current development... – twalberg Dec 29 '12 at 21:36
3

A branch doesn't reference a tag.
A tag references a fixed commit.

So as long as you git checkout master, you are not in a detached HEAD mode.
You can then commit and tag: the tag will be created on the LATEST of the current branch.

If you were in a detached HEAD mode, see "Git: How can I reconcile detached HEAD with master/origin?" for various way of reconciling a detached commit with a branch.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Current master branch is outdated, so if I checkout to it, I'm loosing changes applied in v1.1 and v1.2. – Peter Dec 29 '12 at 15:18
  • 1
    @Peter did you merge your changes to master for v1.1 and v 1.2? – stanley_manley Sep 01 '21 at 08:17
  • 1
    @stanley_manley Peter has not connected to Stack Overflow in... five years (Last seen 6/15/2016). He might or might not answer ;) – VonC Sep 01 '21 at 10:18
0

Tags are used for creating stable releases. To create a tag for using with the Git Drupal Repository, first, ensure that you're following the tag naming convention if you're using this tag for making a release. From inside the directory of the project, an example is:

git tag 7.x-1.0

Once the tag is created, you need to push the tag up to the master repository. By itself, push doesn't send the tags up, you also need to tell it to include the tags in the push by appending the --tags flag:

git push --tags

If you don't want to push all your tags, you can also be specific: Example:

git push origin tag 7.x-1.0

To check and confirm remote tags, the command is : -

git tag -l

user128364
  • 4,533
  • 3
  • 20
  • 12
0

I resolved the problem like this:

git checkout -B master HEAD
git push --force origin master
Jan Wilamowski
  • 3,308
  • 2
  • 10
  • 23
Ines Ayadi
  • 1
  • While SO will accept code-only responses as an Answer, it is discouraged. Good answers include an explanationas to how/why the essential parts of your code suggestion solves the OP's issue. Consider [editing](https://stackoverflow.com/posts/71082125/edit) to add and explanation and/or links to documentation. Good solutions receive more upvotes over time, as users are able to easily extrapolate the insights you provide to solve their own coding issues, or prevent issues in the first place. – SherylHohman Feb 16 '22 at 17:20