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 将代码推送到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 与 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只是自动执行此操作，而无需执行第二步:如果是任何原因，默认情况下您想要任何其他名称，则可以对其进行配置.

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 上并运行 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 ;

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在本地创建一个新的存储库，将其所有提交内容都转移到其中，然后将其所有的<分支机构名称> 转换为远程跟踪名称.然后，我们的Git在其新存储库中根据分支名称之一创建一个一个分支名称.至少，这是正常过程.(而且，如果您知道所有这些术语的含义，那就好！如果没有，请不要担心它们.现在要记住的一点是，我们会得到它们的所有提交和没有一个分支，然后通常我们的Git create 一个分支来匹配它们的一个.)

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 的东西.Refspec实际上允许我们输入两个冒号或其他两种形式的两个名称.例如，我们可以使用 HEAD:main ，如 Arka的答案(尽管出于技术原因)我们可能想在许多情况下使用 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可以使用 any 名称，而不仅仅是分支名称.例如，标记名称可以正常工作.但这是关于分支名称的答案，因为 question 是关于分支名称的，而分支名称是最常用的分支名称.

³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创建初始的 commit ，则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 来查找我们发送给他们的最后一个提交，则他们会丢失他们所做的初始提交，自述文件和许可文件.

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.

您在这里有很多选择:

• 您可以忽略他们所做的初始提交.毕竟，这只是样板提交.您可以告诉他们将其完全丢弃.按照许多现有StackOverflow答案中的任何一个，使用 git push --force .

您可以获取其初始提交，并在这些提交上重新设置您的提交.这可能有点棘手，因为您的第一个提交是 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-histories 选项.与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

实现变基或合并.如果尚未将分支重命名为 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屋！