git - Git Push:HEAD:refs/heads/和有什么区别？

Question

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

1. git push <projectpath> HEAD:refs/heads/<branch>
2. git push <projectpath> <branch>

“ HEAD：refs / heads /”是什么意思？

Answer 1

VonC's answer是正确的（并且被否决），但是我认为从另一角度来看这可能更有意义。

请注意，所有这些都是假设您使用的是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 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是Git存储库的任何完整副本中的有效标记，因为2.1.1版问世。

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

但是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标识的提交哈希在另一个Git存储库中创建标签 mybranch。

通常 HEAD包含分支名称

在Git中， HEAD总是命名当前提交。通常通过命名分支并让分支命名为提交来实现。因此，通常 HEAD包含一个类似于 master的分支名称，而分支名称总是使您获得该分支的尖端提交（这就是Git定义“尖端提交”的方式；请参见 the Git glossary中的分支定义）。但总是，3 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）还是标签（< cc>）。4

其他形式的 refs/tags/dst

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

git push origin

甚至只是：

git push

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

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

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

您还可以推送多个refspecs：

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

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

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

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

（在此示例中，有些外壳会吃掉，弄乱 fold, spindle, or mutilate src，因此您可能需要使用引号；其他外壳不会（或至少通常不会），但是这样做对引用）。这将推动您的所有分支机构，或者至少尝试这样做。这往往过于热情，推动了所有临时工作和实验分支，可能不是您想要的，但这是Git在2.0版之前默认执行的操作。

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

git push origin :refs/heads/deleteme

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

力旗

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

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

您可以这样做：

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

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

git push origin develop +experiment master

experiment上的前导 +使该命令成为命令（“ update experiment！”），而其他命令则保持礼貌的请求（“请先生，如果愿意，请更新 experiment和 develop”） 。

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



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

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

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

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