git --set-upstream是什么？我试图通过阅读git manual来理解它，但我没有完全理解。
--set-upstream
htzpubme1#
为了避免混淆最近的git版本不推荐使用这个有点模糊的--set-upstream选项支持更详细--set-upstream-to选项具有相同的语法和行为。[参考文献]
git
--set-upstream-to
git branch --set-upstream-to <remote-branch>
设置当前本地分支的默认远程分支。任何将来的git pull命令（当前本地分支已检出），将尝试将提交从<remote-branch>带入当前本地分支。避免显式输入--set-upstream/--set-upstream-to的一种方法是使用其简写标志-u，如下所示：
git pull
<remote-branch>
-u
git push -u origin local-branch
这将自动为将来的任何推/拉尝试设置上游关联。有关更多详细信息，请查看此detailed explanation about upstream branches and tracking。
ifmq2ha22#
当你使用--set-upstream标记推送到一个远程分支时，git会将你推送到的分支设置为你推送的分支的远程跟踪分支。添加一个远程跟踪分支意味着git知道你将来在执行git fetch，git pull或git push时要做什么。它假定您希望保持本地分支和它跟踪的远程分支同步，并执行适当的操作来实现这一点。您可以使用git branch --set-upstream-to或git checkout --track实现相同的功能。有关更多信息，请参阅有关跟踪分支的git帮助页面。
git fetch
git push
git branch --set-upstream-to
git checkout --track
im9ewurl3#
git branch --set-upstream <<origin/branch>>不再受官方支持，由git branch --set-upstream-to <<origin/branch>>取代
git branch --set-upstream <<origin/branch>>
git branch --set-upstream-to <<origin/branch>>
z8dt9xmd4#
--set-upstream用于将本地的分支Map到远程的分支，这样你就可以直接执行git push或git pull，它就会知道从哪个分支推送/拉取
为了添加远程存储库，我使用这些命令
git remote -v
git remote add upstream <URL>
通过使用上述相同的命令，可以对本地存储库进行多个远程访问。只需更改上游名称git remote add NAME <URL>
git remote add NAME <URL>
41zrol4v5#
我假设你的问题是：git push --set-upstream <repository> <branchname>是什么？如您所见，我假设所讨论的git命令是git push。希望你是这个意思。为了简化答案，我进一步指定您所在的本地分支与您要推送到的上游存储库上的远程分支具有相同的名称。最后，我假设一个通用的git配置。以下是我的答案：除了不带选项--set-upstream的git push所做的操作外，该选项还使git push至少设置两个配置变量：
git push --set-upstream <repository> <branchname>
这就是这个命令所做的一切。它在配置变量中存储本地分支的上游信息（即远程存储库和分支）。上游信息存储在本地分支名称下。如果本地分支名为main，则相应的配置变量为branch.main.remote和branch.main.merge。根据上游信息的存储方式，本地分支只能有一组上游信息。您可以查询是否使用git config --get-regexp ^branch\.设置了这些配置变量。这将输出任何以“分支”开头的变量。如果您没有在命令行中显式地指定这些配置变量，那么当这些配置变量（例如git fetch、git pull或git push）用于计算本地分支的上游存储库和远程分支时，就会发生神奇的事情。也就是说，当这些配置变量被设置好后，你只需发出git push，git就会知道（使用这些变量）要使用的远程仓库和上游分支。建议进一步阅读：
main
branch.main.remote
branch.main.merge
git config --get-regexp ^branch\.
如果以URL或文件路径的形式给出，请参见以下示例：
git push --set-upstream git@gitlab.example.com:namespace/myproject.git master
git push不创建对.git/refs/remotes/<repository>中的远程分支头的引用仅当上游存储库已使用
.git/refs/remotes/<repository>
git remote add <repository> <URL>
并且git push --set-upstream已经与这个名字一起使用，远程跟踪分支的全部功能在所有git命令中都可用。建议进一步阅读：
git push --set-upstream
zsbz8rwp6#
--set-upstream不仅仅是git branch -u或git push -u。还有git fetch --set-upstream和git pull --set-upstream。如果成功获取远程，则添加上游（跟踪）引用，由无参数的git pull和其他命令使用它将设置：
git branch -u
git push -u
git fetch --set-upstream
git pull --set-upstream
branch.<name>.remote
branch.<name>.merge
这将允许git push知道 * 在哪里 * 推送，以及 * 到 * 哪个远程分支推送。但是：“git fetch --set-upstream”（man）没有检查是否有当前分支，导致在**detached HEAD上运行时出现segfault**，Git 2.35（Q1 2022）已纠正。参见commit 17baeaf（2021年12月7日），作者Ævar Arnfjörð Bjarmason ( avar )。（由Junio C Hamano -- gitster --合并于commit dcaf17c，2021年12月22日）
avar
gitster
pull, fetch
报告人：克莱门斯·弗鲁沃思报告人：扬·波科尔尼签字人：埃瓦尔·阿恩菲约德·比亚马逊修复24bc1a1中添加的--set-upstream选项中的segfault（pull，2019-08-19，Git v2.24.0-rc 0--merge listed in batch #2）（pull，fetch：add（man）--set-upstream选项，2019-08-19）在v2.24.0中添加。这里添加的代码没有执行我们对“git branch“（man）本身所做的相同检查，因为8efb889（“branch：segfault fixes and validation”，2013-02-23，Git v1.8.3-rc 0--merge listed in batch #2），这又修复了我现在在“git branch --set-upstream-to”（man）中修复的相同类型的segfault，参见6183d82（“branch：introduce --set-upstream-to“，2012-08-20，Git v1.8.0-rc0 -- merge listed in batch #5）。我在这里添加的警告消息是为8efb889中的“git branch“添加的错误的合并，以及install_branch_config()本身发出的错误输出，即：它从名称中删除“refs/heads/”，并显示“branch X on remote”，而不是“branch refs/heads/X on remote”。新警告：
add
git branch
branch
install_branch_config()
refs/heads/
branch X on remote
branch refs/heads/X on remote
could not set upstream of HEAD to 'X' from 'X' when it does not point to any branch
我认为在这里简单地使用die()更有意义，但是在24bc1a1中添加的其他--set-upstream检查中，我们发出警告（）。现在让我们在这里做同样的一致性。有一个较早提交的修复此in this thread的替代方法，因为该修补程序破坏了this thread处原始报告的线程。在创作这个版本之前我没有注意到它。我认为这里更详细的警告信息更好，我们也应该对这种行为进行测试。从最近合并的7d0daf3（“Merge分支'en/pull-conflicting-options'”，2021-08-30，Git v2.34.0-rc 0--merge listed in batch #2）开始，需要“git pull“（man）的--no-rebase选项。
die()
--no-rebase
6条答案
按热度按时间htzpubme1#
为了避免混淆
最近的
git版本不推荐使用这个有点模糊的--set-upstream选项支持更详细
--set-upstream-to选项具有相同的语法和行为。
[参考文献]
设置当前本地分支的默认远程分支。
任何将来的
git pull命令（当前本地分支已检出），将尝试将提交从
<remote-branch>带入当前本地分支。避免显式输入
--set-upstream/--set-upstream-to的一种方法是使用其简写标志-u，如下所示：这将自动为将来的任何推/拉尝试设置上游关联。
有关更多详细信息，请查看此detailed explanation about upstream branches and tracking。
ifmq2ha22#
当你使用
--set-upstream标记推送到一个远程分支时，git会将你推送到的分支设置为你推送的分支的远程跟踪分支。添加一个远程跟踪分支意味着git知道你将来在执行
git fetch，git pull或git push时要做什么。它假定您希望保持本地分支和它跟踪的远程分支同步，并执行适当的操作来实现这一点。您可以使用
git branch --set-upstream-to或git checkout --track实现相同的功能。有关更多信息，请参阅有关跟踪分支的git帮助页面。im9ewurl3#
git branch --set-upstream <<origin/branch>>不再受官方支持，由git branch --set-upstream-to <<origin/branch>>取代z8dt9xmd4#
--set-upstream用于将本地的分支Map到远程的分支，这样你就可以直接执行git push或git pull，它就会知道从哪个分支推送/拉取为了添加远程存储库，我使用这些命令
git remote -v检查远程存储库git remote add upstream <URL>git remote -v再次检查远程存储库通过使用上述相同的命令，可以对本地存储库进行多个远程访问。
只需更改上游名称
git remote add NAME <URL>41zrol4v5#
我假设你的问题是：
git push --set-upstream <repository> <branchname>是什么？如您所见，我假设所讨论的git命令是
git push。希望你是这个意思。为了简化答案，我进一步指定您所在的本地分支与您要推送到的上游存储库上的远程分支具有相同的名称。最后，我假设一个通用的git配置。以下是我的答案：
除了不带选项
--set-upstream的git push所做的操作外，该选项还使git push至少设置两个配置变量：这就是这个命令所做的一切。它在配置变量中存储本地分支的上游信息（即远程存储库和分支）。
上游信息存储在本地分支名称下。如果本地分支名为
main，则相应的配置变量为branch.main.remote和branch.main.merge。根据上游信息的存储方式，本地分支只能有一组上游信息。您可以查询是否使用
git config --get-regexp ^branch\.设置了这些配置变量。这将输出任何以“分支”开头的变量。如果您没有在命令行中显式地指定这些配置变量，那么当这些配置变量（例如
git fetch、git pull或git push）用于计算本地分支的上游存储库和远程分支时，就会发生神奇的事情。也就是说，当这些配置变量被设置好后，你只需发出git push，git就会知道（使用这些变量）要使用的远程仓库和上游分支。建议进一步阅读：
但是要注意git的一些怪癖：
如果以URL或文件路径的形式给出，请参见以下示例：
git push不创建对.git/refs/remotes/<repository>中的远程分支头的引用仅当上游存储库已使用
并且
git push --set-upstream已经与这个名字一起使用，远程跟踪分支的全部功能在所有git命令中都可用。建议进一步阅读：
zsbz8rwp6#
--set-upstream不仅仅是git branch -u或git push -u。还有
git fetch --set-upstream和git pull --set-upstream。如果成功获取远程，则添加上游（跟踪）引用，由无参数的
git pull和其他命令使用它将设置：
branch.<name>.remotebranch.<name>.merge这将允许
git push知道 * 在哪里 * 推送，以及 * 到 * 哪个远程分支推送。但是：“
git fetch --set-upstream”（man）没有检查是否有当前分支，导致在**detached HEAD上运行时出现segfault**，Git 2.35（Q1 2022）已纠正。参见commit 17baeaf（2021年12月7日），作者Ævar Arnfjörð Bjarmason (
avar)。（由Junio C Hamano --
gitster--合并于commit dcaf17c，2021年12月22日）pull, fetch：在--set-upstream选项中修复segfault报告人：克莱门斯·弗鲁沃思
报告人：扬·波科尔尼
签字人：埃瓦尔·阿恩菲约德·比亚马逊
修复24bc1a1中添加的
--set-upstream选项中的segfault（pull，2019-08-19，Git v2.24.0-rc 0--merge listed in batch #2）（pull，fetch：add（man）--set-upstream选项，2019-08-19）在v2.24.0中添加。这里添加的代码没有执行我们对“
git branch“（man）本身所做的相同检查，因为8efb889（“branch：segfault fixes and validation”，2013-02-23，Git v1.8.3-rc 0--merge listed in batch #2），这又修复了我现在在“git branch --set-upstream-to”（man）中修复的相同类型的segfault，参见6183d82（“branch：introduce--set-upstream-to“，2012-08-20，Git v1.8.0-rc0 -- merge listed in batch #5）。我在这里添加的警告消息是为8efb889中的“
git branch“添加的错误的合并，以及install_branch_config()本身发出的错误输出，即：它从名称中删除“
refs/heads/”，并显示“branch X on remote”，而不是“branch refs/heads/X on remote”。新警告：
我认为在这里简单地使用
die()更有意义，但是在24bc1a1中添加的其他--set-upstream检查中，我们发出警告（）。现在让我们在这里做同样的一致性。
有一个较早提交的修复此in this thread的替代方法，因为该修补程序破坏了this thread处原始报告的线程。
在创作这个版本之前我没有注意到它。
我认为这里更详细的警告信息更好，我们也应该对这种行为进行测试。
从最近合并的7d0daf3（“Merge分支'en/pull-conflicting-options'”，2021-08-30，Git v2.34.0-rc 0--merge listed in batch #2）开始，需要“
git pull“（man）的--no-rebase选项。