Git推送：HEAD:refs/heads/<branch>和<branch>有什么区别？
Git Push: What is the difference between HEAD:refs/heads/<branch> and <branch>?
命令 1 做什么而命令 2 不做什么？
1. git push <projectpath> HEAD:refs/heads/<branch>
2. git push <projectpath> <branch>
"HEAD:refs/heads/"是什么意思？
第一个命令显式推送具有给定名称的分支。例如，如果您有一个与您的分支之一同名的标签，则第二个命令将是不明确的。
区别：
git push <projectpath> HEAD:refs/heads/<branch>：本地分支提交现在可以不同于远程分支提交，因为“HEAD”可以分离（不链接到任何分支）git push <projectpath> <branch>：本地分支提交将始终与远程分支提交相同。
详细：
正确的分支（不是 detached HEAD）是存储在 HEAD 直接引用的 refname 中的提交。
这意味着 HEAD 是对 refname 的符号引用（它又包含实际的提交），或者 直接指向提交（detached HEAD)。另见“HEAD：当前提交”。
HEAD:refs/heads/<branch> 是一个 refspec，<src>:<dst>，其中 <src> 通常是您想要的分支名称想要推送，但它可以是任意的“SHA-1 表达式”，例如 master~4 或 HEAD，并且 <dst> 告诉远程端的哪个 ref 通过此推送更新。
如果您处于以下状态：
git checkout abranch
--x--Y--W--Y--Z (HEAD abranch)
|
(origin/abranch)
A git push origin aBranch 将推送分支 HEAD（此处为 Z）或原点，导致；
--x--Y--W--Y--Z (FEAD, abranch, origin/abranch)
但是如果你直接签出一个分支的新提交：
git checkout abranch~2
(HEAD)
|
--x--Y--W--Y--Z (abranch)
|
(origin/abranch)
然后你用第二种语法推送，你将更新远程跟踪分支到 W 仅提交：
git push origin HEAD:refs/heads/abranch
(HEAD)
|
--x--Y--W--Y--Z (abranch)
|
(origin/abranch)
git push origin aBranch 仍然会推送完整分支，即使 HEAD 没有引用 abranch.
是正确的（并且被赞成），但我认为另一种看待这个问题的方式可能更有意义。
请注意，所有这些都假设您使用的是 git push 的四字形式，即 git push <em>remote</em> <em>refspec</em>。这里的 remote 部分通常只是名称 origin。我们稍后会更好地定义 refspec。
git push 的作用
git push 需要做的（因此也确实如此）是在另一台机器上调用另一个 Git 实例，1 然后给另一个 Git 一组 references（通常是分支名称，有时是标签名称）来更新。 reference 只是一个名称，如 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 然后将对象发送给他们。"now, please set some names" 部分几乎发生在最后。）
获取名称和哈希部分
请注意，您的 Git 请求分为两部分：(1) 完全合格的参考，以及 (2) 丑陋的大哈希。 （其实还有第三部分，--force标志，不过这部分很简单，我们可以忽略它。）但是your 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 push <em>remote</em> <em>name</em> 表单—Git 在 your 中查找 name 参数] 用于两个目的的存储库：找出其全名，并获取其哈希值。 HEAD 在哪里并不重要，全名指向什么并不重要。
但 Git 不必使用您的分支机构（或标签）ID
git push 的第四个参数称为 refspec，其语法实际上允许两个部分用冒号分隔：
git push origin src:dst
在这种情况下，dst 部分提供 [=205=]name，而 src 部分提供散列。 Git 运行 是 src 到 git rev-parse 的部分，它会产生散列。所以你可以：
git push origin mybranch:refs/tags/v42
在另一个 Git 存储库中创建标签 v42，使用您的分支 mybranch 标识的任何提交哈希。
通常HEAD包含分支名称
在Git中，HEAD总是命名当前提交。 通常它通过命名一个分支，并让分支命名提交来实现。所以，通常 HEAD 包含一个像 master 这样的分支名称，并且分支名称总是让你得到那个分支的 提示提交 （这就是 Git 定义 "tip commit"；参见the Git glossary中分支的定义）。但是总是,3 HEAD可以变成commit:
$ git rev-parse HEAD
2b9288cc90175557766ef33e350e0514470b6ad4
因为 HEAD 要么是分支名称（然后是提示提交），要么你有一个 "detached HEAD"，在这种情况下 Git 直接存储当前提交 ID在 HEAD.
当 HEAD 分离时推动
请记住，为了推送，Git 需要获取这两条信息：哈希和（全）名称。当 HEAD 不是 "detached" 时，Git 可以从中得到两者： HEAD 有一个分支名称——在全名中形式，事实上——并且分支名称具有散列。但是当你处于 "detached HEAD" 模式时，HEAD 只有一个散列。 Git 无法 在 HEAD 中找到分支名称。可能没有 是 一个：您可能已经通过 ID 签出提交，或者您可能通过标签名称签出，如：
$ git checkout v2.1.1
这让你处于这种 "detached HEAD" 模式。
在这种情况下，Git 要求您同时提供源哈希 src——您仍然可以使用名称 HEAD 来获取它—— 和 dst 目的地名称。而且，如果你使用HEAD作为来源，Git确实需要你拼出完整的目的地，因为Git无法分辨，此时，如果应该是分支（refs/heads/dst）或者标签（refs/tags/dst）。4
其他形式的git push
您可以 运行 git push 使用较少的参数，例如：
git push origin
甚至只是：
git push
这里发生的是，如果没有 refspec，Git 会先参考您的 push.default 设置。通常这是 simple（自 Git 2.0 版以来的默认值）。在这种情况下，Git 只是使用 HEAD 来确定要推送的内容——当然，这仅在 HEAD 未分离时才有效。这正是我们上面描述的。
（其他三个设置也使用 HEAD。其中一个是 Git 2.0 版之前的默认设置，但事实证明该特定设置太容易出错，这就是为什么默认值发生变化的原因。您可能不应该使用它，至少除非您是 Git 大师。）
（并且，如果您省略了 remote，Git 再次使用 HEAD 来确定要推送到的位置，默认, 如果需要，到 origin.)
您还可以推送多个参考规范：
git push origin branch1 branch2 tag1 HEAD:refs/tags/tag2
在这种情况下，每个 refspec 都以通常的方式处理：如果需要，获取其完全限定名称，以便您的 Git 每次都可以给它们的 Git 一个完全限定名称；如果您没有使用 src:dst 形式（或者如果您 确实 使用 src:dst 形式，则查找它的哈希 ID，查找 src的 ID）。
您可以在参考规范中使用通配符：
git push origin 'refs/heads/*:refs/heads/*'
（有些 shell 会吃掉、破坏 fold, spindle, or mutilate 和 *，因此您可能需要使用引号，如本例所示；其他 shell 不会——或者至少通常不会” t——但引用也无妨）。这将推送 all 你的分支，或者至少尝试这样做。这往往过于热情，推动你所有的临时工作和实验分支，可能不是你想要的，但这是 Git 在 2.0 版本之前默认所做的。
而且，您可以使用空 src:
git push origin :refs/heads/deleteme
是一种特殊语法，意思是 "have my Git ask their Git to delete that reference"（删除标签，拼出标签）。与分离的 HEAD 一样，在 你的 端缺少完全限定名称意味着你应该为 他们的 端完全限定名称。 （再次参见脚注 4。）
力旗
如果您将 --force 添加到您的 git push 命令，您的 Git 会将此标志传递给他们的 Git。您的 Git 不是礼貌的请求——"please, sir, would you like to set your refs/heads/master to ed4f38babf3d81693a68d06cd0f5872093c009f6?"——而是一个相当坚持的要求。他们的 Git 仍然可以拒绝任何一种方式，但是他们的 Git 默认情况下会这样做，即使这不明智。
Refspecs 允许您更严格地控制此标志。单个 refspec 中的强制标志是前导加号 +。例如，假设您对 master 和 develop 分支都有新的提交，并且还有一组新的 rebased 提交 experiment，每个人else 已同意您可以强制推送。
你可以这样做：
git push origin develop master; git push -f origin experiment
但您可以将其全部合并为一个大推动：
git push origin develop +experiment master
experiment 上的前导 + 使 that 成为命令 ("update experiment!")，而将其他的留作礼貌请求 ("please, sir, if you like, update develop and master").
（这对于 push 来说有点深奥，但实际上是您每天经常使用 git fetch 的东西，它使用带有 + 标志的 refspecs 来创建和更新您的远程跟踪分支。)
1如果 "other repo" 在您的同一台机器上并且您使用的是 file:// 或基于本地路径的 URL，这不太对，但是原理是一样的，操作也是一样的
2更好的是，首先不要让自己陷入这种情况。有一个名称既是分支名称 又是标签名称 是非常令人困惑的。 （由于 Git 的缩写习惯，需要避免类似的混乱情况：例如，不要使用类似于远程名称的名称来命名分支。Git 会很好地处理它们，但是 你 可能不会。:-) )
3实际上，这条规则有一个例外，大多数人永远不会注意到：当 HEAD 命名一个 "unborn branch" 时。大多数情况下，这发生在一个根本没有提交的新存储库中。显然，如果没有提交，就没有 HEAD 可以命名的提交 ID。当您使用 git checkout --orphan 创建新的孤立分支时也会发生这种情况。
4如果您使用不合格的名称，他们的 Git 将查找该名称以对其进行限定。这意味着您可能不知道要更新或删除的名称类型。无论如何，这通常不是一个好主意。
命令 1 做什么而命令 2 不做什么？
1. git push <projectpath> HEAD:refs/heads/<branch>
2. git push <projectpath> <branch>
"HEAD:refs/heads/"是什么意思？
第一个命令显式推送具有给定名称的分支。例如，如果您有一个与您的分支之一同名的标签，则第二个命令将是不明确的。
区别：
git push <projectpath> HEAD:refs/heads/<branch>：本地分支提交现在可以不同于远程分支提交，因为“HEAD”可以分离（不链接到任何分支）git push <projectpath> <branch>：本地分支提交将始终与远程分支提交相同。
详细：
正确的分支（不是 detached HEAD）是存储在 HEAD 直接引用的 refname 中的提交。
这意味着 HEAD 是对 refname 的符号引用（它又包含实际的提交），或者 直接指向提交（detached HEAD)。另见“HEAD：当前提交”。
HEAD:refs/heads/<branch> 是一个 refspec，<src>:<dst>，其中 <src> 通常是您想要的分支名称想要推送，但它可以是任意的“SHA-1 表达式”，例如 master~4 或 HEAD，并且 <dst> 告诉远程端的哪个 ref 通过此推送更新。
如果您处于以下状态：
git checkout abranch
--x--Y--W--Y--Z (HEAD abranch)
|
(origin/abranch)
A git push origin aBranch 将推送分支 HEAD（此处为 Z）或原点，导致；
--x--Y--W--Y--Z (FEAD, abranch, origin/abranch)
但是如果你直接签出一个分支的新提交：
git checkout abranch~2
(HEAD)
|
--x--Y--W--Y--Z (abranch)
|
(origin/abranch)
然后你用第二种语法推送，你将更新远程跟踪分支到 W 仅提交：
git push origin HEAD:refs/heads/abranch
(HEAD)
|
--x--Y--W--Y--Z (abranch)
|
(origin/abranch)
git push origin aBranch 仍然会推送完整分支，即使 HEAD 没有引用 abranch.
请注意，所有这些都假设您使用的是 git push 的四字形式，即 git push <em>remote</em> <em>refspec</em>。这里的 remote 部分通常只是名称 origin。我们稍后会更好地定义 refspec。
git push 的作用
git push 需要做的（因此也确实如此）是在另一台机器上调用另一个 Git 实例，1 然后给另一个 Git 一组 references（通常是分支名称，有时是标签名称）来更新。 reference 只是一个名称，如 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 然后将对象发送给他们。"now, please set some names" 部分几乎发生在最后。）
获取名称和哈希部分
请注意，您的 Git 请求分为两部分：(1) 完全合格的参考，以及 (2) 丑陋的大哈希。 （其实还有第三部分，--force标志，不过这部分很简单，我们可以忽略它。）但是your 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 push <em>remote</em> <em>name</em> 表单—Git 在 your 中查找 name 参数] 用于两个目的的存储库：找出其全名，并获取其哈希值。 HEAD 在哪里并不重要，全名指向什么并不重要。
但 Git 不必使用您的分支机构（或标签）ID
git push 的第四个参数称为 refspec，其语法实际上允许两个部分用冒号分隔：
git push origin src:dst
在这种情况下，dst 部分提供 [=205=]name，而 src 部分提供散列。 Git 运行 是 src 到 git rev-parse 的部分，它会产生散列。所以你可以：
git push origin mybranch:refs/tags/v42
在另一个 Git 存储库中创建标签 v42，使用您的分支 mybranch 标识的任何提交哈希。
通常HEAD包含分支名称
在Git中，HEAD总是命名当前提交。 通常它通过命名一个分支，并让分支命名提交来实现。所以，通常 HEAD 包含一个像 master 这样的分支名称，并且分支名称总是让你得到那个分支的 提示提交 （这就是 Git 定义 "tip commit"；参见the Git glossary中分支的定义）。但是总是,3 HEAD可以变成commit:
$ git rev-parse HEAD
2b9288cc90175557766ef33e350e0514470b6ad4
因为 HEAD 要么是分支名称（然后是提示提交），要么你有一个 "detached HEAD"，在这种情况下 Git 直接存储当前提交 ID在 HEAD.
当 HEAD 分离时推动
请记住，为了推送，Git 需要获取这两条信息：哈希和（全）名称。当 HEAD 不是 "detached" 时，Git 可以从中得到两者： HEAD 有一个分支名称——在全名中形式，事实上——并且分支名称具有散列。但是当你处于 "detached HEAD" 模式时，HEAD 只有一个散列。 Git 无法 在 HEAD 中找到分支名称。可能没有 是 一个：您可能已经通过 ID 签出提交，或者您可能通过标签名称签出，如：
$ git checkout v2.1.1
这让你处于这种 "detached HEAD" 模式。
在这种情况下，Git 要求您同时提供源哈希 src——您仍然可以使用名称 HEAD 来获取它—— 和 dst 目的地名称。而且，如果你使用HEAD作为来源，Git确实需要你拼出完整的目的地，因为Git无法分辨，此时，如果应该是分支（refs/heads/dst）或者标签（refs/tags/dst）。4
其他形式的git push
您可以 运行 git push 使用较少的参数，例如：
git push origin
甚至只是：
git push
这里发生的是，如果没有 refspec，Git 会先参考您的 push.default 设置。通常这是 simple（自 Git 2.0 版以来的默认值）。在这种情况下，Git 只是使用 HEAD 来确定要推送的内容——当然，这仅在 HEAD 未分离时才有效。这正是我们上面描述的。
（其他三个设置也使用 HEAD。其中一个是 Git 2.0 版之前的默认设置，但事实证明该特定设置太容易出错，这就是为什么默认值发生变化的原因。您可能不应该使用它，至少除非您是 Git 大师。）
（并且，如果您省略了 remote，Git 再次使用 HEAD 来确定要推送到的位置，默认, 如果需要，到 origin.)
您还可以推送多个参考规范：
git push origin branch1 branch2 tag1 HEAD:refs/tags/tag2
在这种情况下，每个 refspec 都以通常的方式处理：如果需要，获取其完全限定名称，以便您的 Git 每次都可以给它们的 Git 一个完全限定名称；如果您没有使用 src:dst 形式（或者如果您 确实 使用 src:dst 形式，则查找它的哈希 ID，查找 src的 ID）。
您可以在参考规范中使用通配符：
git push origin 'refs/heads/*:refs/heads/*'
（有些 shell 会吃掉、破坏 fold, spindle, or mutilate 和 *，因此您可能需要使用引号，如本例所示；其他 shell 不会——或者至少通常不会” t——但引用也无妨）。这将推送 all 你的分支，或者至少尝试这样做。这往往过于热情，推动你所有的临时工作和实验分支，可能不是你想要的，但这是 Git 在 2.0 版本之前默认所做的。
而且，您可以使用空 src:
git push origin :refs/heads/deleteme
是一种特殊语法，意思是 "have my Git ask their Git to delete that reference"（删除标签，拼出标签）。与分离的 HEAD 一样，在 你的 端缺少完全限定名称意味着你应该为 他们的 端完全限定名称。 （再次参见脚注 4。）
力旗
如果您将 --force 添加到您的 git push 命令，您的 Git 会将此标志传递给他们的 Git。您的 Git 不是礼貌的请求——"please, sir, would you like to set your refs/heads/master to ed4f38babf3d81693a68d06cd0f5872093c009f6?"——而是一个相当坚持的要求。他们的 Git 仍然可以拒绝任何一种方式，但是他们的 Git 默认情况下会这样做，即使这不明智。
Refspecs 允许您更严格地控制此标志。单个 refspec 中的强制标志是前导加号 +。例如，假设您对 master 和 develop 分支都有新的提交，并且还有一组新的 rebased 提交 experiment，每个人else 已同意您可以强制推送。
你可以这样做：
git push origin develop master; git push -f origin experiment
但您可以将其全部合并为一个大推动：
git push origin develop +experiment master
experiment 上的前导 + 使 that 成为命令 ("update experiment!")，而将其他的留作礼貌请求 ("please, sir, if you like, update develop and master").
（这对于 push 来说有点深奥，但实际上是您每天经常使用 git fetch 的东西，它使用带有 + 标志的 refspecs 来创建和更新您的远程跟踪分支。)
1如果 "other repo" 在您的同一台机器上并且您使用的是 file:// 或基于本地路径的 URL，这不太对，但是原理是一样的，操作也是一样的
2更好的是，首先不要让自己陷入这种情况。有一个名称既是分支名称 又是标签名称 是非常令人困惑的。 （由于 Git 的缩写习惯，需要避免类似的混乱情况：例如，不要使用类似于远程名称的名称来命名分支。Git 会很好地处理它们，但是 你 可能不会。:-) )
3实际上，这条规则有一个例外，大多数人永远不会注意到：当 HEAD 命名一个 "unborn branch" 时。大多数情况下，这发生在一个根本没有提交的新存储库中。显然，如果没有提交，就没有 HEAD 可以命名的提交 ID。当您使用 git checkout --orphan 创建新的孤立分支时也会发生这种情况。
4如果您使用不合格的名称，他们的 Git 将查找该名称以对其进行限定。这意味着您可能不知道要更新或删除的名称类型。无论如何，这通常不是一个好主意。