217

I want to force push, for example, my tag 1.0.0 to my remote master branch.

I'm now doing the following:

git push production +1.0.0:master

I want to force the push, because all I care about is that the code inside the 1.0.0 tag is pushed to the master branch on the remote repository.

What am I doing wrong?

Update #1

When I SSH into my server where my Git repository is and execute git branch -l, I don't see the master branch listed either.

Update #2

After running git tag -l from inside the remote Git repository, I see that master is listed, meaning that when I ran the following:

git push production 1.0.0:master

It actually pushed the tag and created a tag named master rather than a new branch.

I want to basically push the contents of the tag 1.0.0 into the master branch of the remote Git repository.

Michael van Rooijen
  • 6,683
  • 5
  • 37
  • 33
  • Can you clarify what "not working" means? Does Git give an specific error, or does it have a null effect? – vcsjones Oct 31 '10 at 01:51
  • I'm sorry. Yes, so basically when I SSH into my server, into the git repository, and run __git branch -l__ to list the branches, I only see my other branch. However, the __git push production +1.0.0:master__ did push, an when I re-push it says __Everything up-to-date__, but I don't see the master branch on the remote server. – Michael van Rooijen Oct 31 '10 at 01:55
  • 5
    You should change the accepted answer. The second answer is much simpler than the one which is marked as accepted. – Pedro Rolo Sep 14 '12 at 15:55
  • Sorry for the late response. I agree and have now changed the accepted answer. – Michael van Rooijen Dec 22 '12 at 12:27
  • 1
    @MichaelvanRooijen I don't understand how [the accepted answer that you chose](http://stackoverflow.com/a/4061529/456814) actually solves this problem. It doesn't overwrite a branch with a tag, it just pushes your tags to the remote. –  Apr 27 '14 at 20:08
  • Also, if all you wanted to do was to force the remote `master` branch to be at tag `1.0.0`, all you had to do was temporarily hard reset a local `master` to that tag, then force-push that local `master`. Would that have solved your original problem? –  Apr 27 '14 at 20:08
  • For more answers on how to push tags to a remote repository, see [Push a tag to a remote repository using Git?](http://stackoverflow.com/q/5195859/456814). –  Jun 06 '14 at 18:11

4 Answers4

469
git push --tags production
bstpierre
  • 30,042
  • 15
  • 70
  • 103
  • 4
    If the tag already exists on the remote you will need to delete the remote tag first with `git push production :1.0.0`. – respectTheCode Jan 23 '13 at 14:38
  • 1
    If by any occasion you'll have branch with same name: '1.0.0' this push will fail so better use: `git push production :refs/tags/1.0.0` to delete tag only – Vladimir Apr 19 '13 at 20:08
  • Does this push commits too, or just tags? – Nerian Jul 20 '13 at 08:19
  • 1
    @Nerian: I think it just pushes tags – bstpierre Jul 20 '13 at 17:09
  • 7
    How does this actually solve the original poster's problem about overwriting a branch with a tag by force-pushing it? This just pushes all of your tags to a remote, it won't overwrite any branches. –  Apr 27 '14 at 19:53
  • 1
    Isn't the question asking how to push *one* tag? This command does a whole lot more than that. – Chris Martin Sep 11 '14 at 06:27
64

It is probably failing because 1.0.0 is an annotated tag. Perhaps you saw the following error message:

error: Trying to write non-commit object to branch refs/heads/master

Annotated tags have their own distinct type of object that points to the tagged commit object. Branches can not usefully point to tag objects, only commit objects. You need to “peel” the annotated tag back to commit object and push that instead.

git push production +1.0.0^{commit}:master
git push production +1.0.0~0:master          # shorthand

There is another syntax that would also work in this case, but it means something slightly different if the tag object points to something other than a commit (or a tag object that points to (a tag object that points to a …) a commit).

git push production +1.0.0^{}:master

These tag peeling syntaxes are described in git-rev-parse(1) under Specifying Revisions.

Chris Johnsen
  • 214,407
  • 26
  • 209
  • 186
  • 1
    This solved the problem! However the __master__ branch needs to exist already. This isn't an issue on my end however. Thanks a lot for your help! – Michael van Rooijen Oct 31 '10 at 02:42
  • 2
    @Michael: Ahh. Yes, if *master* does not exist (as a branch or a tag), then `git push rep +tag:master` will create a tag named *master* instead of a branch. `git push rep +tag~0:master` (again, when *master* does not exist as a branch or a tag) will fail with “error: unable to push to unqualified destination”. The command that would have done what you wanted (before any *master* branch/tag existed) is `git push rep +tag~0:refs/heads/master` (`refs/heads/` is the namespace under which branches are stored). – Chris Johnsen Oct 31 '10 at 03:13
  • GREAT! That will help me out amazingly well. Very convenient! Thanks a lot for posting that information as well. – Michael van Rooijen Oct 31 '10 at 09:44
  • Can you explain the shorthand? I'm a bit confused here. If my tag points to an object that points to a commit, what happens if I put the wrong commit after `~` than what the tag points to? I assume then that `~0` finds the proper commit, thus is safer?? – brad Aug 25 '11 at 15:42
  • 4
    @brad: The `~{commit}` syntax is literal (i.e. always those nine characters); the word `commit` is not a placeholder here. – Chris Johnsen Aug 25 '11 at 20:41
  • 1
    ah ok! sorry, I was thinking you meant to put in the particular commit, makes more sense now. – brad Aug 29 '11 at 14:45
  • The syntax is "tag^{}", not ~{}. (Are Git developers hostile enough to users to change this syntax?) – Glenn Maynard Jul 15 '13 at 16:11
  • @GlennMaynard: Thanks for catching that. The peeling syntax certainly does use a circumflex, not a tilde. I doubt Git changed this syntax, it was probably just my typo from the start. – Chris Johnsen Jul 15 '13 at 19:55
61

I create the tag like this and then I push it to GitHub:

git tag -a v1.1 -m "Version 1.1 is waiting for review"
git push --tags

Counting objects: 1, done.
Writing objects: 100% (1/1), 180 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:neoneye/triangle_draw.git
 * [new tag]         v1.1 -> v1.1
neoneye
  • 50,398
  • 25
  • 166
  • 151
  • 4
    it push all your tags – Gelldur Oct 01 '13 at 18:55
  • 3
    Note that this won't actually solve the original poster's problem about overwriting a branch with a tag, it will just push your tags to a remote, without affecting branches. –  Apr 27 '14 at 19:54
10

For pushing a single tag: git push <reponame> <tagname>

For instance, git push production 1.0.0. Tags are not bound to branches, they are bound to commits.

When you want to have the tag's content in the master branch, do that locally on your machine. I would assume that you continued developing in your local master branch. Then just a git push origin master should suffice.

koppor
  • 19,079
  • 15
  • 119
  • 161
  • 7
    Note that this won't actually solve the original poster's problem about overwriting a branch with a tag, it will just push your tags to a remote, without affecting branches. –  Apr 27 '14 at 19:55