git push 错误:src refspec main 在 linux 上不匹配 [英] git push error: src refspec main does not match any on linux

问题描述

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

whenever I'm trying to upload my files using git push -u origin main I'm getting error which is as follows

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 没有工作.

but if I do git push -u origin master it is working perfectly and uploading my files to a separate branch named master. upon checking .git/refs/heads in my project i saw that there is only one file named master so i performed git remote update which added .git/refs/remotes/origin/main but still git push -u origin main didn't work.

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

I tried git push origin HEAD:main but produced error:

<代码>！[拒绝] HEAD ->主要(非快进)错误:未能将一些引用推送到github.com:xxxxxxx/xxx-project.git"提示:更新被拒绝，因为推送的分支提示在其远程提示后面:对应.检查此分支并在再次推送之前集成远程更改提示:(例如'git pull ...').提示:有关详细信息，请参阅git push --help"中的关于快进的注意事项".

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

I want to push my code to main branch using git push -u origin main. how do I do that ?

P.S - git 版本 2.29.2，pop_os 20.10.1

P.S - git version 2.29.2, pop_os 20.10.1

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

Edit1 - git push -f origin HEAD:main pushes my code to main branch but how can i replace master file with main file in refs/heads so that i don't have to mention head and force my push ?

推荐答案

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

This is a multi-part answer because there are two separate issues here that are tangling together now. Here's a summary of what we'll cover:

• main vs master
• 错误:src refspec main 不匹配任何
• 协调单独的 main 和 master 分支

• main vs master
• error: src refspec main does not match any
• reconciling separate main and master branches

每一个都在自己的部分.

Each of these is in its own section.

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

Git itself has no special branch names.¹ You could use main, master, trunk, or any other name as the name of your first branch. Git has traditionally used the name master here, but there is a project to make this configurable, so that if you are French or Spanish you can use the name principal or première or primero, or if you prefer Maori, you can use matua or tuatahi. Currently, you can do this manually during or after a git init,² but the project makes Git just do it automatically, without requiring a second step: If for any reason you want any other name by default, you can configure that.

与此同时，GitHub 已经选择领先一步，将其默认初始分支名称设为 main 而不是 master.但这会使您的 Git 和 GitHub 的 Git 不同步，就像以前一样.有关 GitHub 转换的更多信息，请参阅Github 主分支和主分支的区别?

Meanwhile, GitHub have already chosen to leap ahead and make their default initial branch name main instead of master. But this leaves your Git and GitHub's Git out of sync, as it were. For more about GitHub's changeover, see Difference Between Main Branch and Master Branch in Github?

¹这种说法存在一些技术缺陷.众所周知，技术上正确就是最好的正确方式，所以让我在此脚注中添加一些注意事项:

¹There are some technical flaws in this kind of claim. As we know, technically correct is the best kind of correct, so let me add a few caveats in this footnote:

• 当您位于分支 Y 并运行 merge branch X into Y 时，合并会自动生成形式为 merge branch X into Y 的消息code>git merge X.但是，当您使用 master 时，Git 传统上仅生成 merge branch X 形式的消息.

• Merging auto-generates a message of the form merge branch X into Y when you are on branch Y and run git merge X. However, when you're on master, Git traditionally generates only a message of the form merge branch X.

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

A new, empty repository created by git init has no commits and therefore has no branches (because a branch can only exist by having commits on it). However, you must be on some branch in this new empty repository. So Git stores some name in the symbolic ref named HEAD. This is the branch name that you're on, even if that branch name does not exist (yet). For a long time, Git has had, hard-coded into it, some code to stick the branch name master in there. (This is, in effect, what GitHub changed.)

在源代码和文档中还有一堆其他的字符串文字读取 master ；它们正在转换为使用配置设置，但这都需要时间.

There are a bunch of other string literals reading master in the source and documentation as well; they're being converted to use the configuration settings but this will all take time.

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

²If you have Git 2.28 or later, run git init --initial-branch=name, and/or set init.defaultBranch with git config in your system or global configuration. If you have an earlier version of Git installed, or have already run git init, simply use git branch -m to rename master to whatever name you like.

这个来自 Git 的错误信息对新手来说很神秘，但实际上很简单.问题在于它充满了行话(webster; wikipedia)，缩写为source"到src".

This error message from Git is quite cryptic to newbies, but is actually pretty simple. The problems are that it's loaded with jargon (webster; wikipedia), and abbreviates "source" to "src".

Git 是关于提交的.当我们克隆一个存储库时，我们让我们的 Git 接触到其他一些 Git.另一个 Git 查找存储库，而另一个存储库充满了提交.然后我们让我们的 Git 在本地创建一个新的存储库，将他们的所有提交转移到其中，并将他们所有的分支名称转换为远程跟踪名称em>.然后，我们的 Git 在这个新存储库中根据分支名称之一创建一个 分支名称.至少，这是正常的过程.(而且，如果你知道所有这些术语的含义，很好！如果没有，现在不要太担心它们.这里要记住的一点是我们得到了他们所有的提交和没有他们的分支，然后我们通常让我们的 Git 创建一个分支来匹配他们的一个.)

Git is all about commits. When we clone a repository, we have our Git reach out to some other Git. That other Git looks up a repository, and that other repository is full of commits. We then have our Git create a new repository locally, transfer into it all of their commits, and turn all of their branch names into remote-tracking names. Then our Git creates, in this new repository, one branch name, based on one of their branch names. At least, that's the normal process. (And, if you know what all these terms mean, good! If not, don't worry too much about them right now. The point to remember here is that we get all their commits and none of their branches, and then we normally have our Git create one branch to match one of theirs.)

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

Since Git is all about commits, this process—of copying all their commits, but only copying one of their branch names to a name spelled the same in our own repository—is all we need. The fact that our Git renames all of their branch names—so that with the one exception, we don't have any branches at all—isn't normally very important. Our own Git deals with this later, automatically, if and when it's necessary.

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

When we use git push, we are asking our Git program, which is reading our own Git repository, to connect to some other Git program—typically running on a server machine—that can then write to some other Git repository. We'd like our Git to send their Git some of our commits. In particular, we want to send them our new commits: the ones we just made. Those are, after all, where we put all our good new stuff. (Git is all about commits, so that's the only place we can put anything.)

但是，一旦我们发送了这些提交，我们需要在他们的 Git 中设置他们 分支名称之一以记住我们的新提交.那是因为Git查找提交的方式是使用分支名称.³每个提交的真实名称都是丑陋的哈希ID号，没有人愿意记住或查看；所以我们让 Git 使用分支名称记住这些数字.这样，我们只需要看分支名称，这些名称对我们来说就有意义:trunk，或feature/tall，或tuatahi，或其他.

Once we've sent these commits, though, we need to their Git to set one of their branch names to remember our new commits. That's because the way Git finds commits is to use branch names.³ The real names of each commit are big ugly hash ID numbers, which nobody wants to remember or look at; so we have Git remember these numbers using the branch names. That way, we only have to look at the branch names, and these names can be meaningful to us: trunk, or feature/tall, or tuatahi, or whatever.

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

By default and convention, the way we do this using git push is pretty simple:

git push origin main

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

for instance. The git push part is the command that means send commits and ask them to set a name. The origin part is what Git calls a remote: a short name that, mostly, holds a URL. The main part at the end, here, is our branch name. That's the one our Git is using to find our commits. We'll have our Git send our commits, then ask their Git to set their main too.

最后一部分——我们在此处放入 main 的地方——就是 Git 所说的 refspec.Refspecs 实际上让我们输入两个名称，用冒号或其他几种形式分隔.例如，我们可以在 Arka 的答案 中使用 HEAD:main(尽管出于技术原因我们可能想在很多情况下使用 HEAD:refs/heads/main).但在简单的情况下，我们可以只使用一个分支名称:git push origin main.简单的分支名称是 refspec 的一种简单形式.

This last part—where we've put in main here—is what Git calls a refspec. Refspecs actually let us put in two names, separated by a colon, or a couple of other forms. We can, for instance, use HEAD:main as in Arka's answer (although for technical reasons we might want to use HEAD:refs/heads/main in many cases). But in simple cases, we can just use one branch name: git push origin main. The simple branch name is a simple form of refspec.

要使其正常工作，源名称必须是我们自己的 Git 存储库中现有分支的名称.这就是出错的地方.

(另请参阅在 Git 中推送提交时消息src refspec master 不匹配任何")

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

³Git can use any name, not just a branch name. For instance, a tag name works fine. But this answer is about branch names because the question is about branch names, and branch names are the most common ones to use here.

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

Suppose we're using GitHub and we've asked GitHub to make a new repository for us. They run a form of git init that supplies, as the new repository's initial branch name, the name main. They may or may not create one commit, too. Let's say we do have them create this one commit. That one commit will hold README and/or LICENSE files, based on what we choose using the web interface. Creating that initial commit actually creates the branch name main.

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

If we now clone their repository, we'll get their one commit, which will be under their branch name main. Our Git will rename their main to origin/main and then create one new branch name, main, to match theirs. So all will be good.

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

But, if we create our own empty Git repository, using git init ourselves, our Git may set us up so that our first commit will create the name master. We won't have a main branch: we'll have a master branch instead.

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

Or, if we don't have GitHub create an initial commit, the GitHub repository will be totally empty. Because it has no commits, it has no branches: a branch name is only allowed to exist if it specifies some commit. So if we clone this empty repository, we'll have no branches either, and our Git won't know to use main: our Git may instead use master. We're back in that same situation, where our Git think the first name to create should be master.

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

So, in these various situations, we make our first commit(s), and they all go on a branch named master. If we now run:

git push -u origin main

(有或没有 -u；我不会在这里详细介绍 -u)我们的 Git 在我们的 Git 存储库中四处寻找一个分支名为 main.一个都没有！所以我们的 Git 给了我们:

(with or without the -u; I won't go into the details about the -u here) our Git looks around in our Git repository for a branch named main. There isn't one! So our Git just gives us that:

error: src refspec main does not match any

错误信息.

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

To fix this, we can either git push origin master—which sends our commits and then asks GitHub to create a new branch in the GitHub repository, with that branch name being master—or rename our master to whatever name we wanted, and then use that name:

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

将使我们都使用的(单个)分支名称成为 xyzzy.如果您想要 main 在这里，请将您的 master 重命名为 main.

will make the (single) branch name that we both use be xyzzy. If you want main here, rename your master to main.

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

Suppose we used GitHub to create a new repository, with their new default branch name main, that includes one initial commit with the usual README and LICENSE files. Then, without thinking about it, we used git init on our own machine to create our own new repository, with its default branch name master, and we made a commit or two on our master.

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

If we now rename our master to main:

git branch -m master main

然后尝试推送:

git push -u origin main

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

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

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

The reason for this is simple enough: They have a commit, that they find using their name main, that we do not have. If they change their name main to find the last commit that we're sending them, they'll lose the initial commit they made, with the README and LICENSE files.

这里有很多选择:

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

• You can ignore the initial commit they made. It's just a boilerplate commit, after all. You can tell them to throw it away entirely. Use git push --force as outlined in any of many existing StackOverflow answers.

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

You can obtain their initial commit and rebase your commits on those commits. This can be slightly tricky, because your first commit is a root commit. If your first commit contains README and/or LICENSE files, you'll get an add/add conflict here. In this case it's probably simpler to just force-push.

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

You can obtain their initial commit and merge your commits. In a modern Git, this requires using the --allow-unrelated-histories option. As with the rebase method, if your commits contain README and/or LICENSE files, you'll get add/add conflicts. The resulting repository will also have two root commits. None of these are serious problems, but they might prove slightly annoying.

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

To obtain their commit, simply run git fetch origin. That will get GitHub's first commit, and use the name origin/main in your own Git repository to remember it. You can then:

git rebase origin/main

或:

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

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

to achieve the rebase or merge. You can choose whether to rename your branch to main, if you have not already done so, at any time before or after doing all of this.

这篇关于git push 错误:src refspec main 在 linux 上不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！