[一些提醒，既适用于我也适用于OP：远程origin=GitLab, 远程github=GitHub。使用git remote show的主要问题在于它会做出一些假设。这些假设是关于您将来如何运行其他Git命令-git fetch和git push—以及每个Git命令涉及的第二个Git存储库将来如何布置的。正如古丹麻省理工学院名言所说：预测未来尤其是未来的事情非常困难。]
让我在此处回答上文修改过的问题：
This is the message that would give me some peace of mind:
mirror pushes to master (up to date)
How could I configure remote/github... or push.default... to get this output?
有一件值得尝试的事情：一个push.default设置，upstream，告诉Git默认情况下git push应该这样做。如果这有效并且做到了你想要的，那么你就可以了。但请注意，无论Git在这里说什么，它都是有点不真实的。
根本问题在于mirror不会推送到master。在你输入git push命令之前，它根本不会推送任何东西；一旦你输入了那个命令，你就可以使用git push命令控制它去哪里，这完全可以覆盖git remote show所做出的任何声明。
在git push时，您有以下选项：
不提供额外的参数。
在这种情况下，你的 Git 从当前的上游选择 远程。如果上游设置为 origin/...，则远程是 origin。如果上游设置为 github/...，则远程是 github。它看起来像一个简单的字符串替换（通常确实如此，尽管出于历史原因，它实际上是一个可怕的复杂字符串替换，通常变得简单：取斜杠前面的部分）。
此时，你的 Git 继续执行此处列出的第二种情况。
提供一个额外的参数。该参数指定要连接的另一个 Git 的名称。通常是一个远程（例如 origin 或 github），但此时你也可以提供一个 URL。
提供两个或更多额外的参数。其中第一个参数指定远程（或是一个 URL）。其余的是refspecs，如下所定义。
在这一点上，你的Git连接到远程并且实际上运行
git ls-remote来查看它们有哪些分支。这个列表很重要，因为它与你给出或未给出的refspecs一起使用，基于你的
push.default设置，并且事实上，当你给出一个refspec时，你可以只给出一半的refspec。
“半个refspec”情况尤其棘手。无论你做什么或设置什么，如果你实际运行
git push github mirror而你在
mirror上，你的Git将会请求远程的
github Git去设置...嗯，这取决于你是否为它设置了上游，如果没有，则是你的
push.default设置。细节在
the git push documentation中，以Git通常的难懂形式呈现。然而，默认的默认值是对于“半个refspec”，名称
mirror意味着
mirror:mirror。
如果您提供了完整的refspec，例如
git push github mirror:asdf，则refspec的后半部分确定了Git请求其Git设置的分支名称。如果您提供一半的refspec，则通常给出的一半成为两个名称。使用默认的
push.default = simple，您不能意外地将您的
mirror推送到
任何人的
master，您必须使用明确的完整refspec（然后由您确定是否正确）。
如果您
没有提供refspec，您的Git将回退到
push.default，只有五个设置可用。默认的
simple会将您的分支集与它们的分支集（来自
git ls-remote）进行比较。如果您的分支，例如
mirror，
没有相应的分支，您的Git将不会请求设置
任何分支。
假设你在分支
mirror上，将其上游设置为
github/master，并且已经配置了
push.default为
upstream（使用
git config push.default upstream）：
如果你运行git push没有参数，或者git push github没有额外的参数，那么远程将是github。
如果你不提供refspec，则应用push.default设置：Git将构造的refspec将是mirror:master。
然而，如果你提供了一半的refspec，即使我重新阅读文档多次后，也不确定Git会构造什么完整的 refspec。我认为它将是mirror:mirror，这不是你想要的。
你还可以配置一个remote.github.push变量，提供默认的refspecs。这也可能允许你获得所需内容，尽管push.default = upstream似乎更简单。
现在我们回到原始答案。:-)
那么，“本地引用配置为'git push'”为什么是“主推送到主”呢？
这意味着：
假设您当前的分支是master（即，您已经运行了git checkout master）
如果您随后运行git push github（而不是git push github more-command-words），Git - 具体来说是您自己的Git - 将尝试将您当前的master推送到https://github.com/nandoquintana/repo.git的master，具体取决于GitHub上的Git服务器如何处理礼貌请求以将其master设置为与此推送请求一起发送的哈希ID。
（如果您在master上并运行git push origin，再次没有其他参数，则相同的情况适用，只是名称origin指的是GitLab上的Git。）
另一方面，假设您当前的分支名为
mirror:
- 因此，您刚刚运行了
git checkout mirror
- 现在运行
git push github
- 基于Git当前所看到的内容，因此假设这是它再次看到的内容，您的Git将不会尝试推送任何内容。
原因很可能是您已经配置或默认配置了push.default为simple。当push.default设置为simple时，没有refspec参数的git push尝试推送当前分支，但仅当其他Git具有相同名称的分支时才这样做。因此，如果在github（即在https://github.com/...）的Git仓库中仍然没有名为mirror的分支，则您的Git将对自己说：哎呀。没有名为mirror的分支。最好不要推送任何东西。
(如果明天，GitHub 上的那个 Git 确实有一个名为 mirror 的分支，你的 Git 将对自己说：啊哈！那里就是名为 mirror 的分支！好的，我会请求那个 Git 更新它的 mirror。)
为什么不是“mirror 推送到 master”？
因为不是这样的。即使您重新配置了 push.default，也没有默认设置意味着“如果我未能给出 git push 的 refspec，则制定一个不匹配的 refspec。”
关于 refspecs 的简要说明
所有这些都基于一个概念：refspec。在 Git 中，refspec 本质上是一对引用。
一个“引用(reference)”是指“分支或标签名称”的术语（它不仅限于这两个，但这是主要的两个）。像“master”这样的分支名称是其完整拼写“refs/heads/master”的简写。这个“引用(reference)”名称“refs/heads/master”是Git表达“不仅仅是‘master’，而是‘分支(branch) master’”的方式。像“v1.2”这样的短标签名是参考名称“refs/tags/v1.2”的简写。如果你省略了“refs/heads/”或“refs/tags/”部分，Git通常通过查看你现在拥有的分支和标签来确定你的意思。
总之，“refspec”基本上只是两个这样的东西，中间有一个冒号“:”。
refs/heads/master:refs/heads/master
例如。您需要两个引用，因为您正在使用两个Git：一个在您的系统上，您要求它执行某些操作，另一个在某个远程位置，例如gitlab或github。您的Git通过互联网电话呼叫其他Git。然后，您的Git和其Git相互交谈，之后您的Git将获取或推送内容。
提取和推送步骤需要每个Git一个引用，这意味着您需要两个引用：refspec。
refspec的两个部分是源和目标。如果您运行git fetch，则源是其他Git，目标是您自己的Git。如果您运行git push，则您是源；另一个Git成为目标。但无论哪种情况，源都会向目标提供一些提交，然后源的名称（refspec的左半部分）用于更改目标的名称（refspec的右半部分）中的某些内容。
对于
git fetch，每一边都有不同的名称是完全正常的。我们从他们的
refs/heads/master中获取并写入我们自己的
refs/remotes/origin/master。我们从他们的
refs/heads/master中获取并写入我们自己的
refs/remotes/mirror/master。这样可以让我们从许多不同的地方获取，但保持它们的清晰明了。
然而，对于
git push，在每一边使用相同的名称则更加正常。我们从他们的
master中获取，进入我们的
refs/remotes/.../master。然后我们工作一段时间，并确保我们的
master中的任何内容都是一个更新，可以放在他们的
master之上，例如通过合并或变基。然后我们再次联系他们，交付我们的新提交，并要求他们将他们的
master设置为这个最新的提交，该提交建立在他们以前的提交之上，而不是他们甚至没有的
nando/master。
我们确保在获取、工作和推送的过程中，使代码建立在他们的基础之上。如果我们和Sofia“竞赛”，即我们同时获取了代码，但她工作得更快，然后在我们之前提交了代码，我们就会遇到“远程拒绝”、“不是快进”错误；我们必须重新获取代码，从GitHub或其他地方获取Sofia的工作成果，并将我们的工作建立在她的基础之上，然后再次尝试推送。
“本地过时”意味着什么？
当您的git remote show通过互联网电话调用远程仓库——具体来说是github，即https://github.com/nandoquintana/repo.git——时，那个“另一个”Git会说：
I have these references:
refs/heads/master <some big ugly hash ID>
尝试运行
git ls-remote github以查看它们拥有的内容，您将获得完整列表。
您自己的Git有一个名为
master的分支，但是您的
refs/heads/master - 您的
master分支的大而丑陋的哈希ID与您的Git不同。
由于两者不同，您的Git认为您要么“领先” - 您拥有一些他们没有的提交，要么“落后”（他们有一些您没有的提交），或者两者都有。如果您落后了，您的Git无法告诉您落后了多少，但它可以通过查看您的所有提交来确定您“领先”了多少。如果您有提交
129bca4f...，其父项为
e033fc12...，而
他们位于提交
e033fc12...，那么您仅领先一个提交。
如果你的Git在你的
master分支历史记录中找到了他们的Git的提交哈希ID，那么你就是“领先的”，你可以立即使用
git push将新提交发送给他们，要求他们将自己的
master设置为
129bca4f...，他们可能会接受这些提交并更新他们的
master。
但是，如果他们有提交
930ab988...而你根本没有这个提交，那么你的Git只知道他们有一些你没有的提交。你必须是“落后的”。你可以从他们那里使用
git fetch，获取你没有的所有提交，并使用
refs/remotes/github/master将它们记住。然后，你可以采取任何必要的措施将这些提交添加到你自己的
master中，以使你与他们处于平等状态，既不领先也不落后，并进行任何其他工作，以便你现在“领先于”他们。
由你决定这是否是个好主意，如果是的话，是否要执行。所有 git remote show 做的只是通过互联网电话使用 git ls-remote 来调用它们，并将它们的引用与您的引用进行比较，猜测基于这些结果会发生什么 git fetch 和 git push。 （如果您使用 git pull，那就意味着 运行 git fetch，然后运行 git merge。 git remote show 命令也试图猜测那会做什么。）
git branch -u github/master（首先检出镜像）。然后再次运行git remote show github命令。您确定您的推送到了正确的位置吗？ - code_fodder