上游原点<分支>“？
我创建了一个本地分支来测试Solaris和Sun Studio。 然后我将分支推向上游。 提交更改并尝试推送更改后：
$ git commit blake2.cpp -m "Add workaround for missing _mm_set_epi64x"
[solaris 7ad22ff] Add workaround for missing _mm_set_epi64x
1 file changed, 5 insertions(+)
$ git push
fatal: The current branch solaris has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin solaris
为什么我必须为此做一些特别的事情？
是否有任何合理的使用情况下有人会创建<branch> ，按<branch>远程，然后要求提交关于<branch>不应该是<branch> ？
我遵循这个问题，并在Stack Overflow上回答：将一个新的本地分支推送到远程Git存储库并进行跟踪。 我猜测它是另一个不完整或错误的接受答案。 或者，它的另一个Git实例承担了一项简单的任务并使其变得困难。
这是不同机器上的视图。 该分支显然存在，所以它被创建并推送：
$ git branch -a
alignas
* master
remotes/origin/HEAD -> origin/master
remotes/origin/alignas
remotes/origin/arm-neon
remotes/origin/det-sig
remotes/origin/master
remotes/origin/solaris
TL; DR： git branch --set-upstream-to origin/solaris
你问的问题的答案 - 我将重新修改一下“我必须设置上游” - 是的：不，你根本不需要设置上游。
但是，如果没有当前分支的上游，Git会在git push和其他命令上更改它的行为。
这里的完整推送故事漫长而无聊，历史上可以追溯到Git 1.5版之前。 为了缩短它很多， git push实现效果很差。从Git 2.0版开始，Git现在有一个配置旋钮，拼写为push.default ，现在默认为simple 。 对于2.0之前和之后的几个Git版本，每次运行git push ，Git都会发出很多噪音，试图说服你设置push.default ，以便让git push闭嘴。
你没有提到你运行的是哪个版本的Git，也没有提到你是否配置了push.default ，所以我们必须猜测。 我的猜测是，你正在使用的Git版本2点东西，并已设置push.default以simple得到它闭嘴。 正是Git的版本，以及如果你有什么push.default设置，那很重要，因为这段漫长而无聊的历史，但最终，你从Git收到另一个投诉的事实表明，你的Git被配置为避免过去的错误之一。
什么是上游？
上游是另一个分支名称，通常是远程跟踪分支，与（常规，本地）分支关联。
每个分支都有一个上游设置的选项。 也就是说，每个分支都有一个上游，或者没有上游。 没有分支可以有多于一个上游。
上游应该但不一定是有效的分支（无论是远程跟踪，如origin/B还是本地master ）。 也就是说，如果当前分支B具有上游U，那么git rev-parse U应该可以工作。 如果它不起作用 - 如果它抱怨U不存在 - 那么大部分Git的行为就好像上游根本没有设置。 一些命令，比如git branch -vv ，会显示上游设置，但将其标记为“不存在”。
上游有什么好处？
如果您的push.default设置为simple或upstream ，则上游设置将会使git push ，而不需要其他参数就可以使用。
就是这样 - 这就是git push的全部功能。 但这是相当重要的，因为git push是一个简单的错字导致重大头痛的地方之一。
如果您的push.default设置为nothing ， matching或current ，则设置上游对git push没有任何作用。
（所有这些都假设你的Git版本至少2.0。）
上游会影响git fetch
如果你运行没有额外参数的git fetch ，Git会通过查询当前分支的上游来确定从哪个远程获取。 如果上游是远程跟踪分支，Git将从该远程获取。 （如果上游没有设置或者是本地分支，Git将尝试获取origin 。）
上游会影响git merge和git rebase
如果你运行没有附加参数的git merge或git rebase ，Git使用当前分支的上游。 所以它缩短了这两个命令的使用。
上游影响git pull
你不应该使用git pull ，但如果你这样做， git pull使用上游设置来确定从哪个远程获取，然后使用哪个分支进行合并或重新绑定。 也就是说， git pull与git fetch执行的操作相同 - 因为它实际上运行git fetch - 然后执行与git merge或git rebase ，因为它实际上运行了git merge或git rebase 。
（你通常应该手动执行这两个步骤，至少在你知道Git足够好以至于当任何一步失败时，他们最终会认识到出了什么问题并知道该怎么做）。
上游影响git status
这实际上可能是最重要的。 一旦你有一个上游设置， git status可以报告你的当前分支和上游之间的差异，就提交而言。
如果和通常情况一样，你在分支B ，将它的上游设置为origin/B ，并且你运行git status ，你将立即看到你是否有可以推送的提交和/或提交你可以合并或重新绑定到。
这是因为git status运行：
git rev-list --count @{u}..HEAD ：你在B上有多少提交不在origin/B上的提交？ git rev-list --count HEAD..@{u} ：你有多少提交origin/B不在B ？ 设置上游给你所有这些东西。
master已经有一个上游集？
当你第一次从一些远程克隆时，使用：
$ git clone git://some.host/path/to/repo.git
或类似的，Git最后一步就是git checkout master 。 这会检查您的本地分支master只有您没有本地分支master 。
另一方面，您确实有一个名为origin/master的远程跟踪分支，因为您刚克隆它。
Git猜测你一定是这样说的：“让我成为一个新的本地master ，指向与远程跟踪origin/master相同的提交，并且在你处于此位置时，将master的上游设置为origin/master 。”
发生这种情况的每一个分支您git checkout ，你还没有。 Git创建分支并使其“跟踪”（具有上游）相应的远程跟踪分支。
但是这对于新的分支机构不适用，即没有远程跟踪分支的分支机构。
如果你创建一个新的分支：
$ git checkout -b solaris
目前还没有origin/solaris 。 您的本地solaris无法追踪远程追踪分支origin/solaris因为它不存在。
当你第一次推新的分支时：
$ git push origin solaris
从origin上创建solaris ，因此也会在您自己的Git存储库中创建origin/solaris 。 但已经太晚了：你已经有了一个没有上游的本地solaris
Git现在应该自动设置上游吗？
大概。 看到“实施得不好”和脚注1.现在很难改变：有数百万个使用Git的脚本，有些可能依赖于它的当前行为。 改变行为需要一个新的主要版本，nag-ware迫使你设置一些配置字段，等等。 简而言之，Git是自己成功的受害者：它今天的错误只有在变化大部分是看不见的，明显好得多，或者随着时间的推移慢慢完成的时候才能解决。
事实是，它不会在今天，除非在git push过程中使用--set-upstream或-u 。 这就是信息告诉你的。
你不必这样做。 那么，正如我们上面提到的那样，你根本不必这样做，但是让我们假设你想要一个上游。 您已经创建分支solaris上的origin ，通过较早的推动，并为您git branch输出显示，你已经有origin/solaris的本地资源库。
你只是没有把它设置为solaris的上游。
要设置它，而不是在第一次推送时，使用git branch --set-upstream-to 。 --set-upstream-to子命令采用任何现有分支的名称，例如origin/solaris ，并将当前分支的上游设置为该其他分支。
就是这样 - 仅此而已 - 但它具有上述所有影响。 这意味着你可以运行git fetch ，然后环顾四周，然后根据需要运行git merge或git rebase ，然后进行新的提交并运行git push ，而不需要额外的额外烦恼。
1公平地说，目前还不清楚最初的实施是否容易出错。 当每个新用户每次都犯同样的错误时，这一点就变得清晰了。 现在它“不太可怜”，这并不是说“很好”。
2“Never”有点强烈，但我发现当我分离出这些步骤时，Git新手理解的更好，特别是当我可以向他们展示git fetch实际做法时，他们可以看到git merge或git rebase接下来会做。
3如果你运行你的第一个git push作为git push -u origin solaris -ie，如果你添加了-u标志，那么Git会在你的当前分支的上游设置origin/solaris ，如果（并且只是）推送成功。 所以你应该首先提供-u 。 事实上，你可以在以后的任何推动中提供它，它会在那个时候设置或改变上游。 但是我认为git branch --set-upstream-to更容易，如果你忘记了。
4无论如何，由Austin Powers / Dr Evil方法只是简单地说“一个MILLLL-YUN”。
一个基本完整的命令就像git push <remote> <local_ref>:<remote_ref> 。 如果你只运行git push ，git不知道该做什么，除非你做了一些可以帮助git作出决定的配置。 在一个git仓库中，我们可以设置多个遥控器。 我们也可以推送一个本地裁判给任何远程裁判。 完整的命令是最直接的推送方式。 如果你想输入更少的单词，你必须先配置，比如--set-upstream。