git push origin development 和 git push origin HEAD:development 的区别

Question

在使用 git 作为机器几个星期之后，现在我正在弄清楚 GIT 的真正工作原理。比我从一件简单的事情开始：

git checkout -b test origin/development`   //Creating new local branch from development

Create new text file called test.txt

git add . //Set files that will be committed
git commit -m "this is a test" // Committing

然后是我的疑问：

当我尝试做事时：

git push origin development

日志说：一切都是最新的

如果我尝试做事：

git push origin HEAD:development

它可以正常工作。

在进行研究时，我发现 HEAD 表示当前分支的名称。所以，如果它是正确的，那对我来说没有任何意义。

有什么区别

git push origin development

和

git push origin HEAD:development

Answer 1

git push remote-name some-name

尝试将名为some-name 的任何本地 分支推送到在remote-name/some-name 解析的名为some-name 的远程分支也。在后台，它会在每个匹配的位置（本地、远程）上查找 refs 下的分支名称。

由于您的 development 的本地副本尚未修改，您会收到一条消息，指出它是最新的，没有可推送的内容。

替代版本

git push remote-name HEAD:development

跳过关于在本地和远程 refs 中查找匹配分支名称的部分，因为您已通过 HEAD 为其提供了明确的分支。

它仍然使用远程refs 来确定远程分支development。但随后它使用当前分支的HEAD（您的新test 分支）来推送提交。

如果您想简单地从test 分支执行git push 并正确从test 推送到remote/development，您可以将push 的默认行为配置为“上游”设置（注意术语“跟踪”是“上游”的旧术语，是首选）。

做

git config --global push.default upstream

确保一个普通的git push 只会尝试从当前分支推送到其注册的上游分支。

如果没有设置，在 git 版本 2.0 之前，普通 git push 的默认模式会导致尝试将 所有 本地分支推送到在其配置的远程具有匹配名称的上游分支。对于 git 2.0 及更高版本，默认设置为 simple，其作用类似于 upstream，但如果当前分支与其配置的远程名称不同，它也无法推送。

“上游”设置是一个很好的设置，因为 (a) 它允许轻松推送分支，无论它们的名称是否与其上游名称匹配； (b) 对于 2.0 之前的版本，它将对 git push 的裸调用限制为仅影响当前分支，因此如果您在多个分支上积极开发，git push 将不再无意中推送与当前分支无关的其他工作工作; (c) 除非您尝试推送到不是为当前分支配置的上游的某个分支，否则您将不需要专门命名远程和分支的 git push 形式——我认为这是最重要的感觉：如果您不从本地分支推送到其自然的、已配置的上游目标，则只需要详细说明分支。即使是 2.0 simple 设置也不能满足这一点。

remote-name 通常是 origin，但可以是任何已配置的远程，通过各种 git 命令添加或直接在 .gitconfig 文件中添加。

Answer 2

git push origin development 推送development 分支

git push origin HEAD:development 将当前分支推送到远程的development

您很可能不在本地development 分支。考虑使用

进行检查

git status

命令。

Answer 3

git push origin development

将尝试推送您的本地开发分支。通过这种git push 命令，git 会认为本地分支和远程跟踪分支具有相同的分支名称。

来自 git push 的手册页

git push origin master Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the same ref (e.g. refs/heads/master) in origin repository with it. If master did not exist remotely, it would be created.