git push error: src refspec main does not match any on linux
git push error: src refspec main does not match any on linux
每当我尝试使用 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 分支，但是我如何用 refs/heads 中的 main 文件替换 master 文件，这样我就不会不用提头强推？
在进行了更多研究并一无所获后，我尝试了破解。在这里。
在 git push -f origin HEAD:main 之后，我完全删除了我的本地项目文件夹，然后从主分支克隆了我的项目。现在我可以使用 git push origin main 来推送我想要的任何更改。我检查了一下，现在我项目的 .git/refs/heads 位置有一个 main 文件。
这是一个由多个部分组成的答案，因为这里有两个独立的问题现在纠缠在一起。以下是我们将涵盖的内容的摘要：
main 对比 mastererror: src refspec main does not match any- 协调单独的
main 和 master 分支
每一个都在自己的部分。
main 对比 master
Git 本身没有特殊的分支名称。1 您可以使用 main、master、trunk 或任何其他名称作为您的第一个分支机构的名称。 Git 在这里传统上使用名称 master，但是有一个项目可以配置它，因此如果您是法语或西班牙语，您可以使用名称 principal 或 première 或 primero，或者如果您喜欢毛利语，可以使用 matua 或 tuatahi。目前，您可以在 git init、2 期间或之后手动执行此操作，但该项目使 Git 自动执行此操作，无需第二步：如果any reason you want any other name by default, you can configure that.
与此同时，GitHub 已经选择向前迈进，将默认的初始分支名称设为 main 而不是 master。但这会使 您的 Git 和 GitHub 的 Git 不同步，就好像是。有关 GitHub 转换的更多信息，请参阅
1这种说法存在一些技术缺陷。正如我们所知，technically correct is the best kind of correct，所以让我在此脚注中添加一些注意事项：
当您在分支 Y 和 运行 上时，合并会自动生成 merge branch X into Y 形式的消息git合并<em>X</em>。但是，当您使用 master 时，Git 通常只会生成 merge branch X.
形式的消息
由 git init 创建的一个新的空存储库没有提交，因此没有分支（因为只有提交才能存在分支）。但是，您必须 on 这个新的空存储库中的某个分支。所以 Git 在名为 HEAD 的符号引用中存储了一些名称。这是您所在的分支名称，即使该分支名称尚不存在。很长一段时间以来，Git 已经将一些代码硬编码到其中，以将分支名称 master 粘贴在那里。 （实际上，这就是 GitHub 所改变的。）
在源代码和文档中还有一堆其他字符串文字 master；它们正在转换为使用配置设置，但这都需要时间。
2如果你有 Git 2.28 或更高版本，运行 git init --initial-branch= <em>name</em>, and/or 在您的系统或全局配置中将 init.defaultBranch 设置为 git config。如果您安装了 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 在这个新的存储库中创建 one 分支名称，基于它们的分支名称之一。至少，这是正常的过程。 （而且，如果你知道所有这些术语的意思，很好！如果不知道，现在不要太担心它们。这里要记住的一点是我们得到 他们所有的提交和 none 他们的分支 ，然后我们通常有我们的 Git 创建 一个分支来匹配他们的分支之一。 )
由于 Git 都是关于提交的，所以这个过程——复制他们所有的提交，但只将其中一个分支名称复制到我们自己的存储库中拼写相同的名称——就是我们所需要的。事实上，我们的 Git 重命名了它们所有的分支名称 ——所以除了一个例外，我们根本没有任何分支——通常不是很重要。我们自己的 Git 稍后会在必要时自动处理此问题。
当我们使用 git push 时，我们要求我们的 Git 程序（正在读取我们自己的 Git 存储库）连接到其他一些 Git 程序——通常运行ning 在服务器机器上——然后可以写入其他 Git 存储库。我们希望我们的 Git 发送他们的 Git 我们的一些提交。特别是，我们想向他们发送 我们的 new 提交： 我们刚刚提交的内容。毕竟，这些是我们放置所有好新东西的地方。 （Git 是关于提交的，所以这是我们唯一可以放置任何东西的地方。）
但是，一旦我们发送了这些提交，我们需要他们的 Git 将 他们的 分支名称之一设置为 remember 我们的新提交。那是因为 Git finds 提交的方式是使用分支名称。3 每个提交的真实名称都是丑陋的大哈希 ID 号，没有人愿意记住或看；所以我们 Git 使用分支名称记住这些数字。这样，我们只需要查看分支名称，这些名称对我们来说是有意义的：trunk，或feature/tall，或tuatahi，或其他。
默认情况下，我们使用 git push 的方式非常简单：
git push origin main
例如。 git push 部分是命令，表示 发送提交并要求他们设置名称 。 origin 部分是 Git 所谓的 远程： 一个短名称，主要包含 URL。最后的 main 部分是 our 分支名称。那就是 our Git 用来查找 our commits 的那个。我们将让 Git 发送我们的提交，然后要求他们的 Git 也设置 他们的 main。
最后一部分——我们在这里放入 main 的地方——就是 Git 所谓的 refspec。 Refspecs 实际上让我们输入 两个 名称，用冒号或其他几种形式分隔。例如，我们可以像 那样使用 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）
3Git 可以使用 any 名称，而不仅仅是分支名称。例如，标签名称可以正常工作。但是这个答案是关于分支名称的，因为问题是关于分支名称的，而分支名称是这里最常用的分支名称。
如果 我们的 Git 只创建了 master 怎么办？
假设我们正在使用 GitHub 并且我们要求 GitHub 为我们创建一个新存储库。他们 运行 一种 git init 的形式，提供名称 main 作为新存储库的初始分支名称。他们也可能会或可能不会创建一次提交。假设我们确实让他们创建了这个提交。根据我们使用 Web 界面选择的内容，一次提交将保存 README and/or LICENSE 个文件。创建初始提交实际上创建了分支名称 main.
如果我们现在克隆他们的存储库，我们将获得他们的一次提交，该提交将在他们的分支名称main 下。我们的 Git 会将他们的 main 重命名为 origin/main，然后创建一个新的分支名称 main 以匹配他们的名称。所以一切都会好的。
但是，如果我们自己使用 git init 创建自己的 empty Git 存储库，我们的 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 文件制作。
这里有很多选择：
您可以忽略他们所做的初始提交。毕竟，这只是一个样板提交。你可以告诉他们把它完全扔掉。使用许多现有 Whosebug 答案中概述的 git push --force。
您可以获得他们的初始提交并rebase您对这些提交的提交。这可能有点棘手，因为您的第一次提交是 root 提交。如果您的第一次提交包含 README and/or LICENSE 文件，您将在此处遇到 add/add 冲突。在这种情况下，仅用力推动可能更简单。
您可以获得他们的初始提交并合并您的提交。在现代 Git 中，这需要使用 --allow-unrelated-histories 选项。与 rebase 方法一样，如果您的提交包含 README and/or LICENSE 文件，您将遇到 add/add 冲突。生成的存储库还将有两个根提交。 None 其中一些是严重的问题，但它们可能会有点烦人。
要获得他们的承诺，只需 运行 git fetch origin。这将获得 GitHub 的第一次提交，并在您自己的 Git 存储库中使用名称 origin/main 来记住它。然后你可以：
git rebase origin/main
或：
git merge --allow-unrelated-histories origin/main
实现变基或合并。您可以选择是否将您的分支重命名为 main，如果您还没有这样做，可以在执行所有这些操作之前或之后的任何时间选择。
对我来说，将它添加到 ~/.ssh/config
Host github.com
Hostname github.com
User <your username>
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
注意：id_ed25519.pub 已添加到我的 github 授权 SSH 密钥中
如果这是您第一次推送到主分支，请在提交更改后执行这些步骤。
我遇到了这个错误：
src refspec main does not match any
error: failed to push some refs to 'https://github.com/<my_project_name>.git
并且我在 commit.Change URL 之后为您的 github 在以下代码中使用了这些步骤：
git branch -M main
git remote add origin https://github.com/Sidrah-Madiha/<my_project_url>.git
git push -u origin main
几个小时前我遇到了类似的问题，但最终弄清楚了错误不断出现的原因以及解决方法。
我做了什么：
我在 GitHub
创建了一个 git 存储库
在我的代码编辑器（vs 代码）中将我的项目初始化为 git 存储库
我使用
将URL添加到我的回购
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
您可以使用：
git add .
如果已经完成，请尝试提交：
git commit -m "First commit for example..."
git branch -M main
最后：
git push origin main
也可能发生您从 master 分支克隆了您的 repo，现在您正试图将它提交到主分支。如果您的本地仓库在 master 分支中，并且您正尝试将其提交到远程仓库的主分支，请尝试使用以下命令。
git push -f origin master:main
就我而言，我只是想推送一个空文件夹。
添加了 test.txt 文件，一切正常！
这是我使用的：
cd existing_folder
git init --initial-branch=main
git remote add origin https://.../repo.git
git add .
git commit -m "Initial commit"
git push -u origin main
每当我尝试使用 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 分支，但是我如何用 refs/heads 中的 main 文件替换 master 文件，这样我就不会不用提头强推？
在进行了更多研究并一无所获后，我尝试了破解。在这里。
在 git push -f origin HEAD:main 之后，我完全删除了我的本地项目文件夹，然后从主分支克隆了我的项目。现在我可以使用 git push origin main 来推送我想要的任何更改。我检查了一下，现在我项目的 .git/refs/heads 位置有一个 main 文件。
这是一个由多个部分组成的答案，因为这里有两个独立的问题现在纠缠在一起。以下是我们将涵盖的内容的摘要：
main对比mastererror: src refspec main does not match any- 协调单独的
main和master分支
每一个都在自己的部分。
main 对比 master
Git 本身没有特殊的分支名称。1 您可以使用 main、master、trunk 或任何其他名称作为您的第一个分支机构的名称。 Git 在这里传统上使用名称 master，但是有一个项目可以配置它，因此如果您是法语或西班牙语，您可以使用名称 principal 或 première 或 primero，或者如果您喜欢毛利语，可以使用 matua 或 tuatahi。目前，您可以在 git init、2 期间或之后手动执行此操作，但该项目使 Git 自动执行此操作，无需第二步：如果any reason you want any other name by default, you can configure that.
与此同时，GitHub 已经选择向前迈进，将默认的初始分支名称设为 main 而不是 master。但这会使 您的 Git 和 GitHub 的 Git 不同步，就好像是。有关 GitHub 转换的更多信息，请参阅
1这种说法存在一些技术缺陷。正如我们所知，technically correct is the best kind of correct，所以让我在此脚注中添加一些注意事项：
当您在分支
形式的消息Y和 运行 上时，合并会自动生成merge branch X into Y形式的消息git合并<em>X</em>。但是，当您使用master时，Git 通常只会生成merge branch X.由
git init创建的一个新的空存储库没有提交，因此没有分支（因为只有提交才能存在分支）。但是，您必须 on 这个新的空存储库中的某个分支。所以 Git 在名为HEAD的符号引用中存储了一些名称。这是您所在的分支名称，即使该分支名称尚不存在。很长一段时间以来，Git 已经将一些代码硬编码到其中，以将分支名称master粘贴在那里。 （实际上，这就是 GitHub 所改变的。）在源代码和文档中还有一堆其他字符串文字
master；它们正在转换为使用配置设置，但这都需要时间。
2如果你有 Git 2.28 或更高版本，运行 git init --initial-branch= <em>name</em>, and/or 在您的系统或全局配置中将 init.defaultBranch 设置为 git config。如果您安装了 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 在这个新的存储库中创建 one 分支名称，基于它们的分支名称之一。至少，这是正常的过程。 （而且，如果你知道所有这些术语的意思，很好！如果不知道，现在不要太担心它们。这里要记住的一点是我们得到 他们所有的提交和 none 他们的分支 ，然后我们通常有我们的 Git 创建 一个分支来匹配他们的分支之一。 )
由于 Git 都是关于提交的，所以这个过程——复制他们所有的提交，但只将其中一个分支名称复制到我们自己的存储库中拼写相同的名称——就是我们所需要的。事实上，我们的 Git 重命名了它们所有的分支名称 ——所以除了一个例外，我们根本没有任何分支——通常不是很重要。我们自己的 Git 稍后会在必要时自动处理此问题。
当我们使用 git push 时，我们要求我们的 Git 程序（正在读取我们自己的 Git 存储库）连接到其他一些 Git 程序——通常运行ning 在服务器机器上——然后可以写入其他 Git 存储库。我们希望我们的 Git 发送他们的 Git 我们的一些提交。特别是，我们想向他们发送 我们的 new 提交： 我们刚刚提交的内容。毕竟，这些是我们放置所有好新东西的地方。 （Git 是关于提交的，所以这是我们唯一可以放置任何东西的地方。）
但是，一旦我们发送了这些提交，我们需要他们的 Git 将 他们的 分支名称之一设置为 remember 我们的新提交。那是因为 Git finds 提交的方式是使用分支名称。3 每个提交的真实名称都是丑陋的大哈希 ID 号，没有人愿意记住或看；所以我们 Git 使用分支名称记住这些数字。这样，我们只需要查看分支名称，这些名称对我们来说是有意义的：trunk，或feature/tall，或tuatahi，或其他。
默认情况下，我们使用 git push 的方式非常简单：
git push origin main
例如。 git push 部分是命令，表示 发送提交并要求他们设置名称 。 origin 部分是 Git 所谓的 远程： 一个短名称，主要包含 URL。最后的 main 部分是 our 分支名称。那就是 our Git 用来查找 our commits 的那个。我们将让 Git 发送我们的提交，然后要求他们的 Git 也设置 他们的 main。
最后一部分——我们在这里放入 main 的地方——就是 Git 所谓的 refspec。 Refspecs 实际上让我们输入 两个 名称，用冒号或其他几种形式分隔。例如，我们可以像 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）
3Git 可以使用 any 名称，而不仅仅是分支名称。例如，标签名称可以正常工作。但是这个答案是关于分支名称的，因为问题是关于分支名称的，而分支名称是这里最常用的分支名称。
如果 我们的 Git 只创建了 master 怎么办？
假设我们正在使用 GitHub 并且我们要求 GitHub 为我们创建一个新存储库。他们 运行 一种 git init 的形式，提供名称 main 作为新存储库的初始分支名称。他们也可能会或可能不会创建一次提交。假设我们确实让他们创建了这个提交。根据我们使用 Web 界面选择的内容，一次提交将保存 README and/or LICENSE 个文件。创建初始提交实际上创建了分支名称 main.
如果我们现在克隆他们的存储库，我们将获得他们的一次提交，该提交将在他们的分支名称main 下。我们的 Git 会将他们的 main 重命名为 origin/main，然后创建一个新的分支名称 main 以匹配他们的名称。所以一切都会好的。
但是，如果我们自己使用 git init 创建自己的 empty Git 存储库，我们的 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 文件制作。
这里有很多选择：
您可以忽略他们所做的初始提交。毕竟，这只是一个样板提交。你可以告诉他们把它完全扔掉。使用许多现有 Whosebug 答案中概述的
git push --force。您可以获得他们的初始提交并rebase您对这些提交的提交。这可能有点棘手，因为您的第一次提交是 root 提交。如果您的第一次提交包含 README and/or LICENSE 文件，您将在此处遇到 add/add 冲突。在这种情况下，仅用力推动可能更简单。
您可以获得他们的初始提交并合并您的提交。在现代 Git 中，这需要使用
--allow-unrelated-histories选项。与 rebase 方法一样，如果您的提交包含 README and/or LICENSE 文件，您将遇到 add/add 冲突。生成的存储库还将有两个根提交。 None 其中一些是严重的问题，但它们可能会有点烦人。
要获得他们的承诺，只需 运行 git fetch origin。这将获得 GitHub 的第一次提交，并在您自己的 Git 存储库中使用名称 origin/main 来记住它。然后你可以：
git rebase origin/main
或：
git merge --allow-unrelated-histories origin/main
实现变基或合并。您可以选择是否将您的分支重命名为 main，如果您还没有这样做，可以在执行所有这些操作之前或之后的任何时间选择。
对我来说，将它添加到 ~/.ssh/config
Host github.com
Hostname github.com
User <your username>
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
注意：id_ed25519.pub 已添加到我的 github 授权 SSH 密钥中
如果这是您第一次推送到主分支，请在提交更改后执行这些步骤。 我遇到了这个错误：
src refspec main does not match any
error: failed to push some refs to 'https://github.com/<my_project_name>.git
并且我在 commit.Change URL 之后为您的 github 在以下代码中使用了这些步骤：
git branch -M main
git remote add origin https://github.com/Sidrah-Madiha/<my_project_url>.git
git push -u origin main
几个小时前我遇到了类似的问题，但最终弄清楚了错误不断出现的原因以及解决方法。
我做了什么：
我在 GitHub
创建了一个 git 存储库在我的代码编辑器（vs 代码）中将我的项目初始化为 git 存储库
我使用
将URL添加到我的回购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
您可以使用：
git add .
如果已经完成，请尝试提交：
git commit -m "First commit for example..."
git branch -M main
最后：
git push origin main
也可能发生您从 master 分支克隆了您的 repo，现在您正试图将它提交到主分支。如果您的本地仓库在 master 分支中，并且您正尝试将其提交到远程仓库的主分支，请尝试使用以下命令。
git push -f origin master:main
就我而言，我只是想推送一个空文件夹。 添加了 test.txt 文件，一切正常！
这是我使用的：
cd existing_folder
git init --initial-branch=main
git remote add origin https://.../repo.git
git add .
git commit -m "Initial commit"
git push -u origin main