'--set-upstream' 有什么作用？

为避免混淆，最新版本的 git 弃用了这个有点模棱两可的 --set-upstream 选项，转而使用具有相同语法和行为的更冗长的 --set-upstream-to 选项。 [ 参考 ]

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

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

任何未来的 git pull 命令（已签出当前本地分支）
将尝试将来自 <remote-branch> 的提交引入当前本地分支。

避免显式键入 --set-upstream / --set-upstream-to 的一种方法是使用其速记标志 -u，如下所示：

git push -u origin local-branch

这会自动为将来的任何推/拉尝试设置上游关联。
有关更多详细信息，请查看此detailed explanation about upstream branches and tracking。

---

当您推送到远程并使用 --set-upstream 标志时，git 会将您推送到的分支设置为您正在推送的分支的远程跟踪分支。

添加远程跟踪分支意味着 git 知道您将来 git fetch、git pull 或 git push 时要做什么。它假设您希望保持本地分支和它正在跟踪的远程分支同步，并采取适当的措施来实现这一点。

您可以使用 git branch --set-upstream-to 或 git checkout --track 实现相同的目的。有关详细信息，请参阅 tracking branches 上的 git 帮助页面。

---

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

---

--set-upstream 用于将本地分支映射到远程分支，以便您只需执行 git push 或 git pull 即可知道从哪个分支推/拉

为了添加远程仓库，我使用这些命令

首先，使用 git remote -v 检查您的远程存储库

如果看不到上游，请使用 git remote add upstream

使用 git remote -v 再次检查您的远程存储库

一个人可以有多个远程到他们的本地存储库，并且可以使用上面相同的命令添加它。

只需更改上游名称 git remote add NAME <URL>

---

我假设你的问题是：

git push --set-upstream 做什么？

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

话虽如此，这是我的回答：

除了没有选项 --set-upstream 的 git push 所做的操作之外，this option 使 git push set 至少有两个 configuration variables：

分支.<分支名称>.remote = <存储库>

分支.<分支名称>.merge = /ref/heads/<分支名称>

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

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

您可以查询是否使用 git config --get-regexp ^branch\. 设置了这些配置变量。这将输出以“分支”开头的所有变量。

如果您没有在命令行上明确指定它们，那么当 git fetch、git pull 或 git push 等使用这些配置变量来确定本地分支的上游存储库和远程分支时，就会发生奇迹。也就是说，当设置了这些配置变量时，您只需发出 git push，git 就会知道（使用这些变量）远程存储库和要使用的上游分支。

建议进一步阅读：

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

但要注意 git 怪癖：

如果<存储库>以 URL 或文件路径的形式给出，例如 this example：

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 branch -u 或 git push -u。

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

如果远程获取成功，添加上游（跟踪）引用，由无参数 git pull 和其他命令使用

它将设置：

分支.<名称>.remote

分支.<名称>.merge

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

但是：“git fetch --set-upstream”^(man) 没有检查当前分支是否存在，导致在 { 上运行时出现 segfault 3}，已在 Git 2.35（2022 年第一季度）中更正。

请参阅 Ævar Arnfjörð Bjarmason (avar) 的commit 17baeaf（2021 年 12 月 7 日）。
^{（由 Junio C Hamano -- gitster -- 在 commit dcaf17c 中合并，2021 年 12 月 22 日）}

pull, fetch: fix segfault in --set-upstream option 报告人：Clemens Fruhwirth 报告人：Jan Pokorný 签字人：Ævar Arnfjörð Bjarmason

修复 24bc1a1 中添加的 --set-upstream 选项中的段错误（pull，2019-08-19，Git v2.24.0-rc0 -- 批次 #2 中列出的合并）（pull, fetch: add(man) --set -upstream 选项，2019-08-19）在 v2.24.0 中添加。自 8efb889（“分支：段错误修复和验证”，2013 年 2 月 23 日，Git v1.8.3-rc0 -- 合并列于批次 #2），这反过来又修复了我现在在“git branch --set-upstream-to”（man）中修复的相同类型的段错误，参见 6183d82（“分支：引入 --set-upstream-to” , 2012-08-20, Git v1.8.0-rc0 -- 合并在第 5 批中列出）。我在这里添加的警告消息是 8efb889 中为“git branch”添加的错误的合并，并且错误输出 install_branch_config() 本身发出，即它从名称中修剪“refs/heads/”并显示“branch X远程”，而不是“远程分支 refs/heads/X”。

新警告：

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

我认为在这里简单地 die() 会更有意义，但是在对 24bc1a1 中添加的 --set-upstream 的其他检查中，我们发出了一个 warning() 代替。为了保持一致性，让我们在这里做同样的事情。由于该补丁破坏了该线程中原始报告的线程，因此在此线程中存在较早提交的替代方法来解决此问题。在创作这个版本之前我没有注意到它。我认为这里的警告信息越详细越好，我们也应该对此行为进行测试。从最近合并的 7d0daf3 开始，需要“git pull”(man) 的 --no-rebase 选项（“Merge branch 'en/pull-conflicting-options'”，2021-08-30，Git v2.34.0-rc0 -- 合并在第 #2 批中列出）。

---