当你使用——set-upstream标志推送到一个远程分支时，git会将你要推送的分支设置为你要推送的分支的远程跟踪分支。

添加远程跟踪分支意味着git知道你将来在git fetch、git pull或git push时想要做什么。它假设您希望保持本地分支和它正在跟踪的远程分支同步，并执行适当的操作来实现这一目标。

你也可以用git分支——set-upstream-to或git checkout——track实现同样的效果。有关跟踪分支的更多信息，请参阅git帮助页面。

为了避免混淆， 最近版本的git弃用了这个有点模糊的——set-upstream选项 支持更详细的-set-upstream-to选项 使用相同的语法和行为。 [参考文献]

git branch --set-upstream-to <remote-branch>

为当前本地分支设置默认远程分支。

任何未来的git拉命令(与当前本地分支签出)， 将尝试将提交从<远程分支>引入到当前本地分支。

避免显式输入——set-upstream /——set-upstream-to的一种方法是使用其简写标志-u，如下所示:

git push -u origin local-branch

这将自动为未来的任何推/拉尝试设置上游关联。 要了解更多细节，请查看关于上游分支和跟踪的详细说明。

Git branch——set-upstream <<origin/branch>>正式不再支持，由Git branch——set-upstream-to <<origin/branch>>取代

我猜你的问题是

git推送——set-upstream <repository> <branchname>做什么?

如您所见，我假设这里的git命令是git push。我希望你是这个意思。为了简化回答，我进一步指定您所在的本地分支<branchname>与您要推入的上游存储库<repository>上的远程分支具有相同的名称。最后，我假设一个常见的git配置。

话虽如此，我的回答是:

除了没有set-upstream选项的git push操作，这个选项使git push设置至少两个配置变量:

分支。<branchname>.远程= <repository> 分支。<branchname>.merge = /ref/heads/<branchname>

这就是这个命令所做的一切。它在配置变量中为本地分支存储上游信息(即远程存储库和分支)。

上游信息存储在本地分支名称下。如果你的本地分支被称为main，相应的配置变量是branch.main.remote和branch.main.merge。根据上游信息的存储方式，本地分支最多只能拥有一组上游信息。

你可以使用git config——get-regexp ^branch\..这将输出任何以“branch”开头的变量。

当这些配置变量被git fetch, git pull或git push使用时，如果你没有在命令行上显式地指定它们，就会发生魔术。也就是说，当这些配置变量设置好后，你可以发布git push, git就会知道(使用这些变量)要使用的远程存储库和上游分支。

建议进一步阅读:

为什么我必须“git push -set-upstream origin”?

但是要注意git的怪癖:

如果<repository>被指定为URL或文件路径，请参见下面的例子:

git push --set-upstream git@gitlab.example.com:namespace/myproject.git master

Git push不会在.git/refs/remotes/<repository>中创建对远程分支头的引用

仅当上游存储库已被指定名称时使用

git remote add <repository> <URL>

而git push——set-upstream已经使用了这个名字，远程跟踪分支的全部功能在所有git命令中都可用。

建议进一步阅读:

Git:很难让现有的Git存储库跟踪新的裸远程存储库

供参考:所有命令都是用Windows上的git V2.32测试的。

——set-upstream用于将本地的分支映射到远程的分支，这样你就可以执行git push或git pull，它会知道从哪个分支推/拉

为了添加远程回购，我使用这些命令

首先，使用git remote -v检查远程存储库 如果你看不到upstream，那么使用git remote add upstream <URL> 使用git remote -v再次检查远程存储库

通过使用上面相同的命令，可以有多个远程到本地存储库。

只需更改上游名称git远程添加name <URL>

——set-upstream不仅仅是关于git branch -u或git push -u。

你还有git fetch -set-upstream和git pull -set-upstream。

如果远程成功获取，则添加upstream(跟踪)引用，用于无参数的git pull和其他命令

它将设置:

分支。<名称> .remote 分支。<名称> .merge

这将允许git push知道推到哪里，以及推到哪个远程分支。

但是:“git fetch——set-upstream”(man)没有检查当前分支是否存在，导致它在分离的HEAD上运行时出现段错误，这已在git 2.35 (Q1 2022)中得到纠正。

参见Ævar Arnfjörð Bjarmason (avar)提交的commit 17baeaf (07 Dec 2021)。 (由Junio C Hamano—gitster—在commit dcaf17c中合并，2021年12月22日)

Pull, fetch:修复——set-upstream选项中的段错误 报道:Clemens Fruhwirth 报告作者:Jan Pokorný 署名:Ævar Arnfjörð Bjarmason

Fix a segfault in the --set-upstream option added in 24bc1a1 (pull, 2019-08-19, Git v2.24.0-rc0 -- merge listed in batch #2) (pull, fetch: add(man) --set-upstream option, 2019-08-19) added in v2.24.0. The code added there did not do the same checking we do for "git branch"(man) itself since 8efb889 ("branch: segfault fixes and validation", 2013-02-23, Git v1.8.3-rc0 -- merge listed in batch #2), which in turn fixed the same sort of segfault I'm fixing now in "git branch --set-upstream-to"(man), see 6183d82 ("branch: introduce --set-upstream-to", 2012-08-20, Git v1.8.0-rc0 -- merge listed in batch #5). The warning message I'm adding here is an amalgamation of the error added for "git branch" in 8efb889, and the error output install_branch_config() itself emits, i.e. it trims "refs/heads/" from the name and says "branch X on remote", not "branch refs/heads/X on remote".

新警告:

could not set upstream of HEAD to 'X' from 'X' 
when it does not point to any branch

I think it would make more sense to simply die() here, but in the other checks for --set-upstream added in 24bc1a1, we issue a warning() instead. Let's do the same here for consistency for now. There was an earlier submitted alternate way of fixing this in this thread, due to that patch breaking threading with the original report at this thread. I didn't notice it before authoring this version. I think the more detailed warning message here is better, and we should also have tests for this behavior. The --no-rebase option to "git pull"(man) is needed as of the recently merged 7d0daf3 ("Merge branch 'en/pull-conflicting-options'", 2021-08-30, Git v2.34.0-rc0 -- merge listed in batch #2).