git push 错误：src refspec main 与 linux 上的任何内容都不匹配

Posted 2023-02-19

【中文标题】git push 错误：src refspec main 与 linux 上的任何内容都不匹配

【英文标题】：git push error: src refspec main does not match any on linux

【发布时间】：2021-03-18 06:16:32

【问题描述】：

每当我尝试使用 git push -u origin main 上传文件时 我收到如下错误

error: src refspec main does not match any
error: failed to push some refs to 'github.com:xxxxxx/xxx-project.git'

但如果我这样做git push -u origin master，它会完美运行并将我的文件上传到名为master 的单独分支。在我的项目中检查.git/refs/heads 后，我看到只有一个名为master 的文件，所以我执行了git remote update，其中添加了.git/refs/remotes/origin/main，但git push -u origin main 仍然无效。

我尝试了git push origin HEAD:main，但产生了错误：

! [rejected] HEAD -> main (non-fast-forward) error: failed to push some refs to 'github.com:xxxxxxx/xxx-project.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (e.g. 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

我想使用git push -u origin main 将我的代码推送到主分支。我该怎么做？

P.S - git 版本 2.29.2，pop_os 20.10.1

Edit1 - git push -f origin HEAD:main 将我的代码推送到 main 分支，但是我如何将 master 文件替换为 refs/heads 中的 main 文件，这样我就不必提及头部并强制我的推送？

【参考方案1】：

您也可能会从主分支克隆您的存储库，而现在您正尝试将其提交到主分支。如果您的本地 repo 位于 master 分支中，并且您尝试将其提交到远程 repo 上的主分支，请尝试使用以下命令。

git push -f origin master:main

【参考方案2】：

你可以使用：

git add . 

如果已经完成，请尝试提交：

git commit -m "First commit for example..."
git branch -M main   

最后：

git push origin main

【讨论】：

这个答案应该更进一步，因为忘记提交也会导致问题。

【参考方案3】：

几个小时前我遇到了类似的问题，但最终弄清楚了错误不断出现的原因以及解决方法。

我做了什么：

我在 GitHub 上创建了一个 git 存储库

在我的代码编辑器（与代码）中将我的项目初​​始化为 git 存储库

我将 URL 添加到我的 repo 中使用

git remote add origin https://github.com/xxxxxx/xxxxx.git

到时候

git remote -v 

可能按预期给出

origin  https://github.com/xxxx/xxxx.git (fetch)
origin  https://github.com/xxxx/xxxx.git (push)

注意

git branch 

此时将向您显示什么都没有，因为您还没有创建任何分支，也无法创建任何分支。

问题：

当我尝试时

git push -u origin main

我明白了

error: src refspec main does not match any
error: failed to push some refs to 'github.com:xxxx/xxxx.git'

即使使用 git 推荐的命令

git push --set-upstream origin master (or main preferably) 

我遇到了同样的错误。

现在的解决方案：

在您的项目中添加一个文件，例如 README.md

git add .
git commit -m "added README.md"
git branch -M main   

-M 是重命名你的分支，如果你不希望它被称为 master

最后，

git push origin main

【参考方案4】：

如果这是您第一次推送到主分支，请在提交更改后按照以下步骤操作。 我遇到了这个错误错误：

src refspec main does not match any
error: failed to push some refs to 'https://github.com/<my_project_name>.git

我在提交后使用这些步骤进行了修复。在以下代码中更改您的 github 的 URL：

git branch -M main
git remote add origin https://github.com/Sidrah-Madiha/<my_project_url>.git
git push -u origin main

【讨论】：

我得到一个错误：！ [rejected] main -> refs/heads/main（已经存在）

请看这个***.com/questions/22630404/…，好像你用的是git branch main而不是git branch -M main

但是现在我得到一个错误：fatal: remote origin already exists.

我能够重现您的问题，请确保您使用了 git add . 或代替 .在命令中添加您要提交的文件，然后使用git commit -m "your message for commit" 然后使用git branch -M main 中的所有命令，如果这能解决您的问题，请告诉我

我在推送时使用强制-f 标志修复了我的问题。这是唯一有效的方法。

【参考方案5】：

对我来说，将其添加到 ~/.ssh/config

Host github.com
  Hostname github.com
  User <your username>
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

注意：id_ed25519.pub 已添加到我的 github 授权 SSH 密钥中

【参考方案6】：

这是一个多部分的答案，因为这里有两个单独的问题现在纠缠在一起。以下是我们将要介绍的内容的摘要：

main 与 master error: src refspec main does not match any 协调单独的 main 和 master 分支

每一个都在自己的部分中。

main 与 master

Git 本身没有特殊的分支名称。¹ 您可以使用main、master、trunk 或任何其他名称作为您的第一个分支的名称。 Git 传统上在这里使用名称 master，但有一个项目可以使此名称可配置，因此如果您是法语或西班牙语，则可以使用名称 principal 或 première 或 primero，或者如果您愿意毛利人，你可以使用matua 或tuatahi。目前，您可以在 git init,² 期间或之后手动执行此操作，但该项目使 Git 自动执行此操作，无需第二步：如果出于 任何 原因你想要任何默认的名字，你可以配置它。

与此同时，GitHub 已经选择了跨越式发展，将其默认的初始分支名称设为 main 而不是 master。但这会使 你的 Git 和 GitHub 的 Git 不同步，就像原来一样。有关 GitHub 转换的更多信息，请参阅 Difference Between Main Branch and Master Branch in Github?

---

¹这种说法存在一些技术缺陷。众所周知，technically correct is the best kind of correct，所以让我在这个脚注中添加一些注意事项：

当您在分支 Y 上并运行 git merge <em>X</em> 时，合并会自动生成格式为 merge branch X into Y 的消息。但是，当您使用 master 时，Git 传统上只会生成 merge branch X 形式的消息。

git init 创建的新的空存储库没有提交，因此也没有分支（因为分支只有通过提交才能存在）。但是，您必须在这个新的空存储库中的某个分支上。因此 Git 将一些名称存储在名为 HEAD 的符号引用中。这是您所在的分支名称，即使该分支名称不存在（尚不存在）。很长一段时间以来，Git 已经硬编码了一些代码来将分支名称 master 粘贴在其中。 （实际上，这就是 GitHub 改变的地方。）

在源代码和文档中还有很多其他的字符串字面量为master；它们正在转换为使用配置设置，但这都需要时间。

²如果您有 Git 2.28 或更高版本，请运行 git init --initial-branch=<em>name</em>，和/或在您的系统或全局配置中使用 git config 设置 init.defaultBranch。如果您安装了早期版本的 Git，或者已经运行 git init，只需使用 git branch -m 将 master 重命名为您喜欢的任何名称。

---

error: src refspec main does not match any

这个来自 Git 的错误消息对于新手来说非常神秘，但实际上非常简单。问题在于它使用了行话（webster;wikipedia），并将“source”缩写为“src”。

Git 是关于提交的。当我们克隆一个存储库时，我们的 Git 可以访问其他 Git。另一个 Git 查找一个存储库，而另一个存储库充满了提交。然后我们让我们的 Git 在本地创建一个新的存储库，将他们所有的提交转移到其中所有，并将他们所有的分支名称变成远程跟踪名称时间>。然后，我们的 Git 在这个新的存储库中创建 一个 分支名称，基于它们的一个分支名称。至少，这是正常的过程。 （而且，如果您知道所有这些术语的含义，那就太好了！如果不知道，现在不要太担心它们。这里要记住的一点是，我们得到了 他们所有的提交 和 没有他们的分支，然后我们通常让我们的 Git 创建一个分支来匹配他们的一个。）

由于 Git 是关于提交的，因此我们只需要这个过程——复制所有提交，但只将其中一个分支名称复制到我们自己的存储库中拼写相同的名称中。我们的 Git 重命名它们所有的分支名称这一事实——所以除了一个例外，我们根本没有任何分支——通常并不是很重要。我们自己的 Git 会在必要时自动处理这个问题。

当我们使用git push 时，我们要求正在读取我们自己的 Git 存储库的 Git 程序连接到其他 Git 程序（通常在服务器机器上运行），然后该程序可以写入其他 Git 存储库。我们希望我们的 Git 向他们的 Git 发送我们的一些提交。特别是，我们希望向他们发送我们的新 提交： 我们刚刚提交的那些。毕竟，这些是我们放置所有好新东西的地方。 （Git 是关于提交的，所以这是我们唯一可以放任何东西的地方。）

不过，一旦我们发送了这些提交，我们需要在他们的 Git 中设置一个他们的分支名称以记住我们的新提交。那是因为 Git finds 提交的方式是使用分支名称。³ 每个提交的真实名称都是大而难看的哈希 ID 号，没有人想记住或查看；所以我们让 Git 使用分支名称记住这些数字。这样，我们只需要查看分支名称，这些名称对我们来说可能是有意义的：trunk，或feature/tall，或tuatahi，等等。

默认情况下，我们使用git push 执行此操作的方式非常简单：

git push origin main

例如。 git push 部分是表示发送提交并要求他们设置名称的命令。 origin 部分是 Git 所说的 remote: 一个短名称，主要包含一个 URL。末尾的main 部分在这里是我们的 分支名称。这就是 我们的Git 用来查找我们的提交的那个。我们会让我们的 Git 发送我们的提交，然后让他们的 Git 也设置 他们的 main。

最后一部分——我们在这里输入main——就是Git 所说的refspec。 Refspecs 实际上让我们输入 两个 名称，用冒号分隔，或其他几种形式。例如，我们可以像在Arka's answer 中一样使用HEAD:main（尽管出于技术原因，我们可能希望在许多情况下使用HEAD:refs/heads/main）。但在简单的情况下，我们可以只使用一个分支名称：git push origin main。简单分支名称是 refspec 的一种简单形式。

为此，源名称必须是我们自己的 Git 存储库中现有分支的名称。这就是问题所在。

（另见Message 'src refspec master does not match any' when pushing commits in Git）

---

³Git 可以使用任何名称，而不仅仅是分支名称。例如，标签名称可以正常工作。但是这个答案是关于分支名称的，因为问题是关于分支名称的，而分支名称是这里最常用的。

---

如果 我们的 Git 只创建了 master 怎么办？

假设我们正在使用 GitHub，并且我们已经要求 GitHub 为我们创建一个新的存储库。他们运行git init 的形式，提供名称main 作为新存储库的初始分支名称。他们也可能会也可能不会创建一个提交。假设我们确实让他们创建了这个提交。根据我们使用 Web 界面选择的内容，该一次提交将保存 README 和/或 LICENSE 文件。创建初始提交实际上会创建分支名称main。

如果我们现在克隆他们的存储库，我们将获得他们的一个提交，它将在他们的分支名称main 下。我们的 Git 会将他们的 main 重命名为 origin/main，然后创建一个新的分支名称 main 以匹配他们的名称。所以一切都会好起来的。

但是，如果我们创建自己的 empty Git 存储库，使用 git init 我们自己，我们的 Git 可能会设置我们，以便我们的第一次提交将创建名称 master。我们不会有main 分支：我们将有一个master 分支。

或者，如果我们没有让 GitHub 创建初始 commit，那么 GitHub 存储库将完全是空的。因为它没有提交，所以它没有分支：分支名称只有在指定某个提交时才允许存在。因此，如果我们克隆这个空存储库，我们也将没有分支，并且我们的 Git 不会知道使用 main：我们的 Git 可能会使用 master。我们又回到了同样的情况，我们的 Git 认为要创建的第一个名字应该是 master。

因此，在这些不同的情况下，我们进行了第一次提交，它们都在一个名为 master 的分支上进行。如果我们现在运行：

git push -u origin main

（有或没有-u；我不会在这里详细介绍-u）我们的Git 在我们的Git 存储库中寻找一个名为main 的分支。一个都没有！所以我们的 Git 只是给了我们：

error: src refspec main does not match any

错误信息。

要解决这个问题，我们可以git push origin master——它发送我们的提交，然后要求 GitHub 在 GitHub 存储库中创建一个新分支，该分支名称为 master——或者将我们的 master 重命名为任何名称我们想要，然后使用该名称：

git branch -m master xyzzy
git push -u origin xyzzy

将使我们都使用的（单个）分支名称为xyzzy。如果您想在此处使用main，请将您的master 重命名为main。

如果你不小心做了两个分支怎么办？

假设我们使用 GitHub 创建了一个新的存储库，其新的默认分支名称为 main，其中包括一个带有常用 README 和 LICENSE 文件的初始提交。然后，不假思索地，我们在自己的机器上使用git init 创建了我们自己的新存储库，其默认分支名称为master，并在master 上进行了一两次提交。

如果我们现在将master 重命名为main：

git branch -m master main

然后尝试推送：

git push -u origin main

我们得到一个不同的错误：

 ! [rejected]        main -> main (non-fast-forward)

原因很简单：他们有一个提交，他们使用他们的名main发现，而我们没有。如果他们更改名称main 以查找我们发送给他们的最后一次提交，他们将丢失他们所做的初始提交以及 README 和 LICENSE 文件.

这里有很多选择：

您可以忽略他们所做的初始提交。毕竟，这只是一个样板提交。你可以告诉他们把它完全扔掉。使用许多现有 *** 答案中所述的git push --force。

您可以获得他们的初始提交并rebase您在这些提交上的提交。这可能有点棘手，因为您的第一个提交是 root 提交。如果您的第一次提交包含 README 和/或 LICENSE 文件，您将在此处遇到添加/添加冲突。在这种情况下，强制推送可能更简单。

您可以获得他们的初始提交并合并您的提交。在现代 Git 中，这需要使用 --allow-unrelated-histories 选项。与 rebase 方法一样，如果您的提交包含 README 和/或 LICENSE 文件，您将遇到添加/添加冲突。生成的存储库还将有两个根提交。这些都不是严重的问题，但它们可能会有点烦人。

要获得他们的提交，只需运行git fetch origin。这将获得 GitHub 的第一次提交，并在您自己的 Git 存储库中使用名称 origin/main 来记住它。然后你可以：

git rebase origin/main

或：

git merge --allow-unrelated-histories origin/main

实现rebase或merge。您可以选择是否将您的分支重命名为main，如果您尚未这样做，则可以在执行所有这些操作之前或之后的任何时间。

【讨论】：

首先感谢您的详细解释。我没想到会有这么多信息。我还有一个要求。请指出一些我可以了解 rebase 和 root 提交的博客。

不太确定博客文章，但是在 *** 上有很多关于变基和根提交等的答案，例如，Change first commit of project with Git? 和 How to merge a commit with the next commit in git interactive rebase?。不过，这个问题和答案可能更直接相关：Insert a NON-EMPTY commit before the root commit in Git?

请注意，您可以使用搜索栏on *** 搜索 ***：将[git] 按字面意思放在方括号内，然后是各种关键字，SO 将搜索它们的对原始问题上带有git 标记的关键字拥有自己的问题和答案。

【参考方案7】：

在进行了更多研究并没有任何结果之后，我尝试了一个 hack。在这里。

在git push -f origin HEAD:main 之后，我完全删除了我的本地项目文件夹，然后从主分支克隆了我的项目。现在我可以使用git push origin main 推送我想要的任何更改。我检查了，现在我的项目的.git/refs/heads 位置有一个main 文件。

【讨论】：

这是唯一对我有用的解决方案。似乎-f 是一个神奇的覆盖标志，它迫使 git 做你想做的事情。