命令1不执行命令2的功能？

" HEAD：refs / heads /"是什么意思？

VonC的答案是正确的(但被否决了)，但我认为从另一角度来看这可能更有意义。

好。

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

好。

git push的作用

git push需要做的(并因此做的)是在另一台机器1上调用另一个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来完成的。两个Git同意要发送的内容，您的counting objects和compressing objects然后将对象发送给他们。"现在，请设置一些名称"部分几乎在最后发生。)

好。

获取名称和哈希部分

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

好。

如果您写：

好。

您已经为Git提供了两条信息：名称origin(您的Git用于查找URL)和名称somename。您的Git使用它来找出全名。 somename是标签吗？如果是这样，全名是refs/tags/somename。 somename是分支吗？如果是这样，全名是refs/heads/somename。不管哪种方法。当然，您也可以自己写出全名-如果名称既是分支又是标签，则可能要这样做，而不是让Git为您选择一个。2

好。

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

好。

会给你看。事实上，这就是我得到ed4f38babf3d81693a68d06cd0f5872093c009f6的方式：我去了Git的Git存储库并做了git rev-parse v2.1.1并打印出了该哈希值，因为v2.1.1是Git存储库的任何完整副本中的有效标记，因为2.1.1版问世。

好。

请注意，当您使用这种形式(git push remote name形式)时，Git会在存储库中查找name参数，以实现两个目的：查找其全名并获取其哈希。 HEAD的位置无关紧要，仅是全名所指向的内容。

好。

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

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

好。

在这种情况下，dst部分提供了名称，而src部分提供了哈希。 Git通过git rev-parse运行src部分，并生成哈希。所以你可以：

好。

使用分支mybranch标识的提交哈希在另一个Git存储库中创建标签v42。

好。

通常HEAD包含分支名称

在Git中，HEAD总是命名当前提交。通常通过命名分支并让分支命名为提交来实现。因此，通常HEAD包含一个类似于master的分支名称，并且分支名称始终会为您提供该分支的尖端提交(这就是Git定义"尖端提交"的方式；请参见Git词汇表中的分支定义)。但始终可以将3 HEAD转换为提交：

好。

因为HEAD是分支名称(即提示提交)，否则您具有"分离的HEAD"，在这种情况下，Git将当前提交ID直接存储在HEAD中。

好。

HEAD分离时推动

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

好。

这使您处于"分离头"模式。

好。

在这种情况下，Git要求您同时提供源哈希src(您仍然可以使用名称HEAD来获取它)和dst目标名称。而且，如果您使用HEAD作为源，那么Git确实需要您拼出完整的目的地，因为Git在这一点上无法分辨它是分支(refs/heads/dst)还是标签()。4

好。

git push的其他形式

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

好。

甚至只是：

好。

这里发生的是，没有refspec，Git首先会查询您的push.default设置。通常这是simple(自Git 2.0版以来的默认值)。在这种情况下，Git仅使用HEAD来确定要推送的内容-当然，只有在未分离HEAD时，该功能才起作用。这就是我们上面描述的。

好。

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

好。

(并且，如果省略了remote，Git会再次使用HEAD找出要推送到的位置，如果需要，默认使用origin。)

好。

您还可以推送多个refspecs：

好。

在这种情况下，每个refspec都以通常的方式处理：如果需要，请获取其全限定名称，以便您的Git每次都可以为其Git命名一个全限定名称；如果不使用src:dst表单，则查找其哈希ID(或者，如果使用src:dst表单，则查找src的ID)。

好。

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

好。

(某些shell会吃掉，破坏，折叠，纺锤或破坏*，因此您可能需要使用引号，如本例所示；其他shell不会(或至少通常不会)，但是它不会)伤害报价)。这将推动您的所有分支机构，或者至少尝试这样做。这往往过于热情，推动了所有临时工作和实验分支，可能不是您想要的，但这是Git在2.0版之前默认执行的操作。

好。

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

好。

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

好。

力旗

如果在git push命令中添加--force，则Git将此标志传递到其Git上。而不是礼貌的请求-"先生，您想将refs/heads/master设置为ed4f38babf3d81693a68d06cd0f5872093c009f6吗？"-您的Git会将其发送为一个相当持久的需求。他们的Git仍然可以拒绝任何一种方式，但是默认情况下，即使不明智，他们的Git也会这样做。

好。

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

好。

您可以这样做：

好。

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

好。

experiment上的前导+使该命令成为命令(" update experiment！")，而其余命令则保持礼貌的请求("请先生，如果愿意，请更新develop和master") 。

好。

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

好。

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

好。

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

好。

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

好。

4如果您使用不合格的名称，他们的Git会查询该名称以使其合格。这意味着您可能不知道要更新或删除的名称。无论如何，这通常不是一个好主意。

好。

好。

正确的分支(意味着不是分离的HEAD)是存储在直接由HEAD引用的refname中的提交。 这意味着HEAD是对refname的符号引用(反过来又包含实际的提交)，或者直接指向提交(分离的HEAD)。另请参见" HEAD：当前提交"。

HEAD:refs/heads/是带有:的refspec，其中通常是您要推送的分支的名称，但是它可以是任意的" SHA-1表达式"，例如master~4或，然后告诉远程方的哪个ref通过此推送进行更新。

如果您具有以下状态：

git push origin aBranch将推动分支HEAD(在此为Z)或原点，结果为：

但是，如果您直接签出Abranch的新提交之一：

然后使用第二种语法推送，您将更新远程跟踪分支，直到仅提交W：

即使HEAD不引用abranch，git push origin aBranch仍将推送完整分支。

第一个命令显式推送具有给定名称的分支。例如，如果您有一个名称与您的分支之一相同的标签，则第二个命令将是不明确的。