VonC的答案是正确的（但被否决了），但我认为从另一角度看待这个问题可能更有意义。

请注意，所有这些假设都是假设您使用的四字形式git push，即。这里的部分通常只是名称。我们稍后将定义更好。git push remote refspecremoteoriginrefspec

是什么git push呢

有什么git push需要做的（因此不）是调用了另一个Git的实例另一台机器上，¹然后给其他Git的一组引用（通常分支名称，有时标记名称）来更新。一个参考是一个简单的名称，如master或v1.2，在理想情况下应该是完全限定（refs/heads/master或refs/tags/v1.2），这样我们就可以知道是什么样的呢引用分支，标签，或什么的。

为了让其他Git更新您的Git移交的引用，您的Git还必须移交其中一些难看的SHA-1哈希值：每个引用一个。换句话说，您的Git会要求其Git将其 设置refs/heads/master为ed4f38babf3d81693a68d06cd0f5872093c009f6。（在这一点上，实际上，实际上是在此之前，您的Git和他们的Git进行了一次对话，讨论您要向其发送哪些对象，以及它们已经拥有哪些对象，这些都是由这些丑陋的哈希ID来完成的。两个控释同意这是怎么回事要送过来，你做的counting objects和compressing objects，然后将它们的对象。在“现在，请设置一些名字”的一部分发生了近即止。）

获取名称和哈希部分

请注意，您的Git请求包括两部分：（1）完全合格的参考，以及（2）大丑陋的哈希。（实际上，还有第三部分，--force标志，但是那部分很简单，我们可以忽略它。）但是，您的Git从哪里得到这些？

如果您写：

git push origin somename

你给你的Git的两条信息：名称origin，你的Git使用来查找URL和名称somename。您的Git使用它来找出全名。是somename标签吗？如果是这样，全名是refs/tags/somename。是somename分公司吗？如果是这样，全名是refs/heads/somename。无论哪种方式都行。当然，你也可以写出来的全名自己，如果名字既是一个分支和标签，你可能会想这样做，而不是让Git的挑一个给你。^2个

那么，您的Git从何而来？答案是：来自同一个名字。名称somename（无论是分支还是标记）仅命名某些特定的Git对象。如果您想自己查看哈希，则可以随时执行以下操作：

git rev-parse somename

会给你看。实际上，这就是我的工作方式ed4f38babf3d81693a68d06cd0f5872093c009f6：我去了Git的Git存储库，git rev-parse v2.1.1然后将其打印出来，因为v2.1.1自从2.1.1版本问世以来，它是Git存储库任何完整副本中的有效标记。

请注意，当您确实使用这种形式（即这种形式）时，Git会在您的存储库中查找自变量，既可用于查找其全名，又可用于获取其哈希值。无论您身在何处，都只不过是全名所指向的内容。git push remote namenameHEAD

但是Git不必使用您分支机构（或标签）的ID

的第四个参数git push称为refspec，其语法实际上允许两部分之间用冒号分隔：

 git push origin src:dst

在这种情况下，该dst部分提供名称，但该src部分提供哈希。Git运行该src部分，git rev-parse并产生哈希。这样你就可以：

git push origin mybranch:refs/tags/v42

v42使用您的分支mybranch标识的任何提交哈希在其他Git存储库中创建标签。

通常HEAD包含一个分支名称

在Git中，HEAD 始终命名当前提交。通常，它是通过命名分支并让分支命名为提交来实现的。因此，通常HEAD包含一个分支名称（例如）master，并且分支名称始终会为您提供该分支的尖端提交（这就是Git定义“ tip commit”的方式；请参见Git词汇表中的分支定义）。但始终，³ HEAD可以变成一个承诺：

$ git rev-parse HEAD
2b9288cc90175557766ef33e350e0514470b6ad4

因为HEAD它要么是一个分支名称（即尖端提交），要么是一个“分离的HEAD”，在这种情况下，Git将当前的提交ID直接存储在中HEAD。

HEAD分离时推动

请记住，为了进行推送，Git需要获取这两条信息：哈希和（全）名称。如果HEAD 不“分离”，则Git可以从中获得两者：HEAD具有分支名称（实际上是全名形式），并且分支名称具有哈希。但是，当您处于“分离式HEAD”模式时，HEAD仅具有哈希值。Git在中找不到分支名称HEAD。有可能不会是一个：你可能已经检查了提交的ID，或者你签出的标记名称，如：

$ git checkout v2.1.1

这使您处于“分离头”模式。

在这种情况下，Git会要求您提供两个源哈希src-你仍然可以使用名称HEAD来获得它-和在dst目的地名称。而且，如果您将其HEAD用作源，那么Git确实需要您阐明完整的目的地，因为Git在这一点上无法分辨它是分支（refs/heads/dst）还是标签（refs/tags/dst）。⁴

其他形式的 git push

您可以git push使用更少的参数来运行，例如：

git push origin

甚至只是：

git push

这里发生的是，没有refspec，Gitpush.default首先会参考您的设置。通常这是simple（自Git 2.0版以来的默认设置）。在这种情况下，Git只是HEAD用来弄清楚要推送的内容-当然，只有在HEAD不分离的情况下才起作用。这就是我们上面描述的。

（其他三个设置也使用HEAD。其中一个（在Git 2.0版之前是默认设置）没有使用，但是事实证明该特定设置容易出错，这就是为什么更改默认设置的原因。您可能不应该使用它，至少不是这样，除非您是Git大师。）

（而且，如果您省略了remote，Git会再次使用它HEAD来确定推送到的位置，如果需要的话，默认为origin。）

您还可以推送多个refspecs：

git push origin branch1 branch2 tag1 HEAD:refs/tags/tag2

在这种情况下，每个refspec都以通常的方式处理：如果需要，请获取其完全限定名称，以便您的Git每次都可以为其Git赋予一个完全限定名称；并期待其散列ID，如果你没有使用src:dst形式（或者，如果你没有使用src:dst形式，查找src的ID代替）。

您可以在refspecs中使用通配符：

git push origin 'refs/heads/*:refs/heads/*'

（有些炮弹会吃，碾压机，折叠，主轴，或毁坏的*太您可能需要使用引号，因为在这个例子中，其他贝壳不需额外或至少通常不需额外，但它不伤害引用）。这将推动您的所有分支机构，或者至少尝试这样做。这往往过于热情，推动了您所有的临时工作和实验分支，并且可能不是您想要的，但这是Git在2.0版之前默认执行的操作。

并且，您可以使用一个空的src：

git push origin :refs/heads/deleteme

这是一种特殊情况的语法，意思是“让我的Git要求其Git删除该引用”（要删除标签，请拼出标签）。与独立的HEAD一样，您这一边缺少全限定名，这意味着您应该完全限定他们这一侧的名称。（再次参见脚注4。）

力旗

如果添加--force到git push命令中，您的Git将此标志传递给他们的Git。您的Git不会发出礼貌的请求（“先生，您想将您的电话设置refs/heads/master为ed4f38babf3d81693a68d06cd0f5872093c009f6吗？”），这是一个相当坚持的要求。他们的Git仍然可以拒绝这两种方式，但是默认情况下，即使不明智，他们的Git也会这样做。

Refspec使您可以更严格地控​​制此标志。单个refspec中的力标记是一个前导加号+。例如，假设您对master和develop分支都有新的提交，并且对也有一组新的基于基础的提交experiment，其他所有人都同意允许您强制推送。

您可以这样做：

git push origin develop master; git push -f origin experiment

但您可以将所有这些组合在一起进行一次大的推动：

git push origin develop +experiment master

领先+的experiment品牌是一个命令（“更新experiment！”），同时保留其他有礼貌的请求（“请，先生，如果你喜欢，更新develop和master”）。

（对于来说push，这有点深奥，但实际上，您每天都经常使用git fetch，它会使用refspecs和+标志来创建和更新您的远程跟踪分支。）

¹如果“其他存储库”位于同一台计算机上，并且使用的是file://基于URL或本地路径的URL，则不是很正确，但是原理相同，操作也相同。

²更好的是，首先不要让自己陷入这种情况。一个名字既是分支名又是标签名，这非常令人困惑。（由于Git的缩写习惯，有类似的情况需要避免：不要使用类似于远程名称的名称来命名分支。例如，Git可以很好地处理它们，但您可能不会。:-)）

³实际上，此规则有一个例外，大多数人不会注意到：当HEAD命名“未出生的分支”时。通常，这发生在完全没有提交的新存储库中。显然，如果没有提交，则没有HEAD可以命名的提交ID 。当您用于git checkout --orphan创建新的孤立分支时，也会发生这种情况。

⁴如果您使用不合格的名称，他们的Git将查找该名称以对其进行限定。这意味着您可能不知道要尝试更新或删除的名称。无论如何，这通常不是一个好主意。