614

git push --tags is a separate operation to git push since pushing tags should be a conscious choice to avoid accidentally pushing the wrong one. That's fine. But how do I push them both simultaneously / atomically? (git push && git push --tags is not perfectly atomic.)

Improve this question
10
  • 9
    What's your problem with git push && git push --tags? Commented Sep 19, 2010 at 9:59
  • 32
    Nothing in particular, it's just slower since the connection has to be established twice. Commented Sep 19, 2010 at 10:56
  • 23
    See my updated answer below: there is a new --follow-tags option since git 1.8.3 Commented Apr 23, 2013 at 8:48
  • 85
    Another reason not to do these separately, is to avoid triggering two CI builds for the same commit, when you have that kind of automation in place. Commented Sep 25, 2018 at 7:31
  • 16
    @fuz git push && git push --tags will trigger the CI pipeline twice, although this may have been irrelevant 10 years ago. Commented Jun 5, 2020 at 9:13

6 Answers 6

Reset to default
834

Update August 2020

As mentioned originally in this answer by SoBeRich, and in my own answer, as of git 2.4.x

git push --atomic origin <branch name> <tag>

(Note: this actually work with HTTPS only with Git 2.24)

Update May 2015

As of git 2.4.1, you can do

git config --global push.followTags true

If set to true enable --follow-tags option by default.
You may override this configuration at time of push by specifying --no-follow-tags.

As noted in this thread by Matt Rogers answering Wes Hurd:

--follow-tags only pushes annotated tags.

git tag -a -m "I'm an annotation" <tagname>

That would be pushed (as opposed to git tag <tagname>, a lightweight tag, which would not be pushed, as I mentioned here)

Update April 2013

Since git 1.8.3 (April 22d, 2013), you no longer have to do 2 commands to push branches, and then to push tags:

The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out.

You can now try, when pushing new commits:

git push --follow-tags

That won't push all the local tags though, only the one referenced by commits which are pushed with the git push.

Git 2.4.1+ (Q2 2015) will introduce the option push.followTags: see "How to make “git push” include tags within a branch?".

Original answer, September 2010

The nuclear option would be git push --mirror, which will push all refs under refs/.

You can also push just one tag with your current branch commit:

git push origin : v1.0.0

You can combine the --tags option with a refspec like:

git push origin --tags :

(since --tags means: All refs under refs/tags are pushed, in addition to refspecs explicitly listed on the command line)

You also have this entry "Pushing branches and tags with a single "git push" invocation"

A handy tip was just posted to the Git mailing list by Zoltán Füzesi:

I use .git/config to solve this:

[remote "origin"]
    url = ...
    fetch = +refs/heads/*:refs/remotes/origin/*
    push = +refs/heads/*
    push = +refs/tags/*

With these lines added git push origin will upload all your branches and tags. If you want to upload only some of them, you can enumerate them.

Haven't tried it myself yet, but it looks like it might be useful until some other way of pushing branches and tags at the same time is added to git push.
On the other hand, I don't mind typing:

$ git push && git push --tags

Beware, as commented by Aseem Kishore

push = +refs/heads/* will force-pushes all your branches.

This bit me just now, so FYI.

René Scheibe adds this interesting comment:

The --follow-tags parameter is misleading as only tags under .git/refs/tags are considered.
If git gc is run, tags are moved from .git/refs/tags to .git/packed-refs. Afterwards git push --follow-tags ... does not work as expected anymore.

Improve this answer
Sign up to request clarification or add additional context in comments.

34 Comments

The one comment on the post you link to correctly points out that the push = +refs/heads/* line force-pushes all your branches. This bit me just now, so FYI.
Re: the --follow-tags flag added in git 1.8.3, can I configure my git installation to make that the default?
@TrevorBurnham no, only the value of push.default (git-scm.com/docs/git-config) can define default actions on push (nothing, matching, upstream, simple as in stackoverflow.com/a/10002469/6309). You need to add --follow-tag explicitly.
@VonC What if I want to force push the tag? git push --follow-tags -f didn't work for me.
@static_rtti I agree. I suspect this is mostly for historic reason. Again, for now, a global setting enable you to make that permanent, but yes, this is not the default yet.
|
29

Since Git 2.4:

git push --atomic origin <branch name> <tag>
Improve this answer

8 Comments

lol, I think I'd rather git push; git push --tags
@BlaineLafreniere lol, it’s not “simultaneous” and defies the question
why would you type all that out, when you could type something shorter, and achieve the same result?
Not the same. Atomicity. There are a couple of articles on Wikipedia
Nope, this still triggers github workflows twice.
|
14

Let's say you have created a new repo on github. So the first step would be to clone the repo:git clone {Your Repo URL}

You do your work, add some files, code etc., then push your changes with:

git add .
git commit -m "first commit"
git push

Now our changes are in main branch. Let's create a tag:

git tag v1.0.0                    # creates tag locally     
git push origin v1.0.0            # pushes tag to remote

If you want to delete the tag:

git tag --delete v1.0.0           # deletes tag locally    
git push --delete origin v1.0.0   # deletes remote tag
Improve this answer

5 Comments

I tried your solution with git-2.21.0.windows.1 and found that 3 only pushes tag
I used "git commit -m "msg" in step 1 and there was no -a parameter. This could be why. Thank you for the followup!
@RajeshGupta it does NOT push to remote. Just locally to origin. Run git status after your three commands and you will see something like "your branch is ahead of 'origin/develop' by 1 commit. (use "git push" to publish your local commits)"
@RajeshGupta actually what you suggested works (sorry for my last comment). But you have a little typo in step 3. It should be git push origin 0.1.0 - you should omit the word 'tag'. Then it works really good. And for me even better than the --follow-tags option.
However I found another issue with this approach. I wondered why I can't see any related commit on develop branch. Then I noticed in Github UI --> "This commit does not belong to any branch on this repository." This is strange. Any idea whats going wrong?
8

Just tested on git 2.31.0: git push <refspec> --tags. This has the advantage that it pushes ALL tags, not just annotated tags like --follow-tags.

Improve this answer

2 Comments

This works! This needs to explicitly name both the remote and the branch name but at least it pushes all the work in a single shot
I think this answers the question best because it pushes all tags. To be a bit more specific you can run git push origin HEAD --tags
5

To avoid triggering two CI builds for the same commit on Gitlab:

git push -o ci.skip && git push --tags

As suggested by @user1160006 here.

Improve this answer

3 Comments

On gitlab it shows a pipeline, its just in the skipped state (which breaks pipeline badges). So it saves build ressources, but it doesn't allow to have a clean view of the pipeline's state.
Thankfully (at least in this context) I don't use pipeline badges, while on the other side I'm quite sensible to resorce usage, and even more to the time required to complete the pipeline actions, expecially if the second push triggers a deployment and I'm waiting for it's completion for a final "overall" test. However @cglacet let me ask: while the first push sets the pileline to a skipped state, the second one which follow immediatly should restore the normal state, so it's just a temporary glitch
I would say the same, but for some reason badges are not taking the 2nd pipeline into account. Even when the 2nd pipeline succeed the badge shows the "unknown" tag (that I guess correspond to the skipped pipeline, or maybe its just because the commit triggered two pipelines).
1

Git GUI

Git GUI has a PUSH button - pardon the pun, and the dialog box it opens has a checkbox for tags.

I pushed a branch from the command line, without tags, and then tried again pushing the branch using the --follow-tags option descibed above. The option is described as following annotated tags. My tags were simple tags.

I'd fixed something, tagged the commit with the fix in, (so colleagues can cherry pick the fix,) then changed the software version number and tagged the release I created (so colleagues can clone that release).

Git returned saying everything was up-to-date. It did not send the tags! Perhaps because the tags weren't annotated. Perhaps because there was nothing new on the branch.

When I did a similar push with Git GUI, the tags were sent.

Tags sent with Git GUI

For the time being, I am going to be pushing my changes to my remotes with Git GUI and not with the command line and --follow-tags.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.