我是 git 的初学者。我读过 git push --set-upstream origin master 只能执行一次 - 当 repo 为空时。
但是，我忘记并第二次使用--set-upstream origin master 推送。现在，当我执行git branch -a 时，我得到了
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
这是什么意思，我现在应该做什么？
【问题讨论】：
标签： git
在 GitHub，您可以选择默认签出的分支（即当您克隆时）。默认情况下，origin/HEAD 会指向那个位置。
请参考此链接了解更多详情 Why is "origin/HEAD" shown when running "git branch -r"?
【讨论】：
我是 git 的初学者。我读过
git push --set-upstream origin master必须只执行一次 - 当 repo 为空时。
这不太对，有两种不同的方式。其中之一是这样可以：
但是，我第二次忘记并用
--set-upstream origin master推送了。
您可以多次执行此操作。
原始声明中的第二个缺陷是你从来没有必须做一次。在第一个git push 上执行一次既方便又好主意，但这不是要求。1此外，它是对每个新的分支，2 执行一次是个好主意，而不仅仅是上游存储库为空。也就是说，“first push”并不意味着“first push ever”，而是“first push per new branch”。
每次您将-u 或--set-upstream 选项与git push 一起使用时，您设置或重新设置（即不更改），甚至做 更改，upstream 设置。将分支 B 推送到名为 origin 的远程会创建或更新您的 origin/<em>B</em> 远程跟踪分支，3 然后设置 B 在origin/<em>B</em> 的上游。如果已经这样设置，没问题！如果根本没有设置，现在设置：耶！如果设置不同，现在设置为origin/<em>B</em>. 如果这是您想要的设置：耶！这只有在 不是 你想要的方式设置时才不好（这似乎不太可能）。
要了解为什么您要设置或更改上游，请参阅this answer 相关问题。请注意，您还可以取消设置任何给定分支的上游。
要了解更多历史，了解过去使用 Git 1.7 及更早版本时它是如何工作的，请参阅 this question 和 this one。
Dhiraj's answer 解释了您现在看到的内容。
1使用-u 本身并不是必需的。但是，如果您要推送的另一个 Git 存储库没有同名分支，并且您的 push.default 配置为 simple ，git push -u origin master 的替代选择是git push origin master:master，即，您必须指定分支名称两次。写一次-u 更短，并且将你的master 的上游设置为新创建的origin/master，这是一件好事——所以使用一次-u 更短更好，但它不是必需的。
2当您运行 git push 或 git fetch — 或 git pull，它们只运行 git fetch 和第二个 Git 命令 — 您的 Git 会调用另一个 Git。其他 Git 有自己的 分支。这些分支有自己的提交，可能与您在分支上的提交匹配，也可能不匹配。显然，一个新的、完全空的存储库有 no 提交（因此没有分支），4 但是如果您创建了一个名为 zorg 的新分支，他们的 Git 可能还没有zorg：分支对他们来说是新的。
3您的远程跟踪分支（例如 origin/master）是 您的Git 记住的一种方式，方便您您的 em> Git 从 他们的（起源）Git 获得关于 他们的 分支的信息，上次你运行 git fetch 或 git push 到 origin。这就是他们的目的。使用git fetch（或git remote update）不时更新它们，只要你认为它们可能已经改变并且你想找出答案。
4哲学问题：分支存在但没有提交意味着什么？ 是否有“空分支”之类的东西？ （Git 的答案大多是不，没有这样的东西，但还有其他版本控制系统——我只是说“大部分”......）
【讨论】：