Ark*_*rka 19 git branch github git-refspec
每当我尝试使用上传我的文件时,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'
Run Code Online (Sandbox Code Playgroud)
但如果我这样做,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.
我想使用 .js 将我的代码推送到主分支git push -u origin main。我怎么做 ?
PS - git 版本 2.29.2,pop_os 20.10.1
Edit1 -git push -f origin HEAD:main将我的代码推送到main分支,但是我如何master用mainfile in替换文件,refs/heads以便我不必提及 head 并强制推送?
tor*_*rek 29
这是一个多部分的答案,因为这里有两个单独的问题现在纠缠在一起。以下是我们将涵盖的内容的摘要:
main 对比 mastererror: src refspec main does not match anymain和master分支这些中的每一个都在其自己的部分中。
main 对比 masterGit 本身没有特殊的分支名称。1 您可以使用main、master、trunk或任何其他名称作为第一个分支的名称。Git的传统使用的名字master在这里,但有一个项目,使这个配置的,所以,如果你是法语或西班牙语,你可以使用的名称principal或première或者primero,或者如果你喜欢毛利,你可以使用matua或tuatahi。目前,您可以在 a git init, 2期间或之后手动执行此操作,但该项目使 Git 自动执行此操作,无需第二步:如果出于任何原因您需要默认任何其他名称,则可以对其进行配置。
同时,GitHub 已经选择跃进并使用默认的初始分支名称main而不是master. 但这会使您的Git 和GitHub 的Git 不同步,就像以前一样。更多关于 GitHub 的转换,请参见
Github 中 Main Branch 和 Master Branch 的区别?
1这种索赔存在一些技术缺陷。正如我们所知,技术上正确是最好的正确,所以让我在这个脚注中添加一些警告:
merge branch X into Y当您在 branchY和 run上时,合并会自动生成表单的消息。但是,当您打开 时,Git 传统上仅生成形式为 的消息。git merge Xmastermerge branch X
创建的新的空存储库git init没有提交,因此没有分支(因为分支只能通过提交才能存在)。但是,你必须在这个新的空库的一些分支。因此,Git 在名为 的符号引用中存储了一些名称HEAD。这是您所在的分支名称,即使该分支名称不存在(尚不存在)。很长一段时间以来,Git 已经硬编码了一些代码来将分支名称粘贴master在其中。(实际上,这就是 GitHub 改变的地方。)
master源代码和文档中还有一堆其他字符串文字;它们正在转换为使用配置设置,但这都需要时间。
2如果你的Git 2.28或更高版本,运行,和/或设置与您的系统或全局配置。如果您安装了早期版本的 Git,或者已经运行了,只需使用重命名为您喜欢的任何名称。git init --initial-branch=nameinit.defaultBranchgit configgit initgit branch -mmaster
error: src refspec main does not match any这个来自 Git 的错误信息对新手来说很神秘,但实际上很简单。问题在于它充满了行话(webster;wikipedia),并将“源”缩写为“src”。
Git 是关于提交的。当我们克隆一个存储库时,我们让我们的 Git 接触到其他一些 Git。另一个 Git 查找存储库,而另一个存储库充满了提交。然后我们让我们的 Git 在本地创建一个新的存储库,将他们的所有提交转移到其中,并将他们的所有分支名称转换为远程跟踪名称。然后,我们的 Git 在这个新存储库中根据分支名称之一创建一个分支名称。至少,这是正常的过程。(而且,如果你知道所有这些术语的含义,很好!如果没有,现在不要太担心它们。这里要记住的一点是我们得到了他们的所有提交,而不是他们的分支,然后我们通常让我们的 Git创建一个分支来匹配他们的一个。)
因为 Git 是关于提交的,所以这个过程——复制他们所有的提交,但只将他们的一个分支名称复制到我们自己的存储库中拼写相同的名称——就是我们所需要的。我们的 Git重命名了所有分支名称这一事实——因此除了一个例外,我们根本没有任何分支——通常不是很重要。我们自己的 Git 稍后会在必要时自动处理这个问题。
当我们使用 时git push,我们要求正在读取我们自己的 Git 存储库的 Git 程序连接到某个其他 Git 程序(通常在服务器机器上运行),然后该程序可以写入其他某个 Git 存储库。我们希望我们的 Git 将我们的一些提交发送给他们的 Git。特别是,我们想向他们发送我们的新提交:我们刚刚提交的那些。毕竟,这些是我们放置所有好的新东西的地方。(Git 是关于提交的,所以这是我们唯一可以放置任何东西的地方。)
但是,一旦我们发送了这些提交,我们就需要让他们的 Git 设置他们的分支名称之一来记住我们的新提交。那是因为 Git查找提交的方式是使用分支名称。3 每次提交的真实姓名都是丑陋的大哈希ID号,没人想记住或看;所以我们让 Git 使用分支名称记住这些数字。这样,我们只需要查看分支名称,这些名称对我们来说就很有意义:trunk、 或feature/tall、 或tuatahi、 或其他什么。
默认情况下,我们使用的git push方式非常简单:
git push origin main
Run Code Online (Sandbox Code Playgroud)
例如。该git push部分是表示发送提交并要求他们设置名称的命令。这origin部分是 Git 所说的远程:一个短名称,主要是包含一个 URL。最后的main部分,这里,是我们的分支名称。这是我们的Git 用来查找我们的提交的那个。我们将让我们的 Git 发送我们的提交,然后让他们的 Git 也设置他们的 提交main。
最后一部分——我们放在main这里的地方——是 Git 所说的refspec。Refspecs 实际上让我们输入两个名称,用冒号或其他几种形式分隔。例如,我们可以HEAD:main在Arka 的回答中使用as (尽管出于技术原因,我们可能希望HEAD:refs/heads/main在许多情况下使用)。但在简单的情况下,我们可以只使用一个分支名称:git push origin main. 简单的分支名称是 refspec 的一种简单形式。
为此,源名称必须是我们自己的 Git 存储库中现有分支的名称。 这就是事情出错的地方。
(另请参阅在 Git 中推送提交时消息“src refspec master does not match any”)
3 Git 可以使用任何名称,而不仅仅是分支名称。例如,标签名称工作正常。但是这个答案是关于分支名称的,因为问题是关于分支名称的,而分支名称是这里最常用的名称。
master怎么办?假设我们正在使用 GitHub,并且我们已经要求 GitHub为我们创建一个新的存储库。他们运行一种形式的git init供应,作为新存储库的初始分支名称, name main。他们也可能会也可能不会创建一个提交。假设我们确实让他们创建了这个提交。根据我们使用 Web 界面选择的内容,该提交将保留README和/或LICENSE文件。创建初始提交实际上会创建分支名称main。
如果我们现在克隆他们的存储库,我们将获得他们的一次提交,这将在他们的分支名称下main。我们的 Git 将它们重命名main为origin/main,然后创建一个新的分支名称main,以匹配它们的名称。所以一切都会好起来的。
但是,如果我们使用自己创建自己的空Git 存储库,git init我们的 Git 可能会设置我们,以便我们的第一次提交将创建 name master。我们不会有一个main分支:我们会有一个master分支。
或者,如果我们没有 GitHub 创建初始提交,则 GitHub 存储库将完全为空。因为它没有提交,所以它没有分支:分支名称只有在指定了某个提交时才允许存在。因此,如果我们克隆这个空存储库,我们也将没有分支,并且我们的 Git 将不知道使用main:我们的 Git 可能会使用master. 我们又回到了同样的情况,我们的 Git 认为要创建的第一个名称应该是master.
因此,在这些不同的情况下,我们进行第一次提交,并且它们都在名为master. 如果我们现在运行:
git push -u origin main
Run Code Online (Sandbox Code Playgroud)
(有或没有-u;我不会在-u这里详细介绍)我们的 Git 在我们的 Git 存储库中四处寻找名为main. 一个都没有!所以我们的 Git 只是给了我们:
error: src refspec main does not match any
Run Code Online (Sandbox Code Playgroud)
错误信息。
为了解决这个问题,我们可以git push origin master- 它发送我们的提交,然后要求 GitHub 在 GitHub 存储库中创建一个新分支,该分支名称为master- 或者将我们的重命名为我们master想要的任何名称,然后使用该名称:
git branch -m master xyzzy
git push -u origin xyzzy
Run Code Online (Sandbox Code Playgroud)
将使我们都使用的(单个)分支名称成为xyzzy. 如果你想main在这里,将你的重命名master为main.
假设我们使用 GitHub 创建了一个新的存储库,其新的默认分支名称为main,其中包括一个带有常用 README 和 LICENSE 文件的初始提交。然后,没有考虑它,我们git init在自己的机器上使用它的默认分支名称创建了我们自己的新存储库,并master在我们的master.
如果我们现在将我们的重命名master为main:
git branch -m master main
Run Code Online (Sandbox Code Playgroud)
然后尝试推送:
git push -u origin main
Run Code Online (Sandbox Code Playgroud)
我们得到一个不同的错误:
! [rejected] main -> main (non-fast-forward)
Run Code Online (Sandbox Code Playgroud)
原因很简单:他们有一个提交,他们发现使用他们的name main,而我们没有。如果他们更改名称main以查找我们发送给他们的最后一次提交,他们将丢失他们所做的初始提交,以及 README 和 LICENSE 文件。
你在这里有很多选择:
您可以忽略他们所做的初始提交。毕竟,这只是一个样板提交。你可以告诉他们把它完全扔掉。git push --force按照许多现有 StackOverflow 答案中的任何一个中的概述使用。
您可以获取他们最初的承诺和变基在这些提交你的提交。这可能有点棘手,因为您的第一次提交是根提交。如果您的第一次提交包含 README 和/或 LICENSE 文件,您将在此处遇到添加/添加冲突。在这种情况下,强制推送可能更简单。
您可以获得他们的初始提交并合并您的提交。在现代 Git 中,这需要使用该--allow-unrelated-histories选项。与 rebase 方法一样,如果您的提交包含 README 和/或 LICENSE 文件,您将遇到添加/添加冲突。生成的存储库还将有两个根提交。这些都不是严重的问题,但它们可能会有点烦人。
要获得他们的提交,只需运行git fetch origin. 这将获得 GitHub 的第一次提交,并使用origin/main您自己的 Git 存储库中的名称来记住它。然后你可以:
git rebase origin/main
Run Code Online (Sandbox Code Playgroud)
或者:
git merge --allow-unrelated-histories origin/main
Run Code Online (Sandbox Code Playgroud)
实现rebase或merge。您可以main在执行所有这些操作之前或之后的任何时间选择是否将您的分支重命名为,如果您还没有这样做的话。
小智 9
您可以使用:
git add .
Run Code Online (Sandbox Code Playgroud)
如果已经完成,请尝试提交:
git commit -m "First commit for example..."
git branch -M main
Run Code Online (Sandbox Code Playgroud)
最后:
git push origin main
Run Code Online (Sandbox Code Playgroud)
小智 6
几个小时前我遇到了类似的问题,但最终弄清楚了错误不断出现的原因以及解决方案。
我做了什么:
我在 GitHub 上创建了一个 git 仓库
在我的代码编辑器(vs 代码)中将我的项目初始化为 git 存储库
我使用
git remote add origin https://github.com/xxxxxx/xxxxx.git
Run Code Online (Sandbox Code Playgroud)
这时候
git remote -v
Run Code Online (Sandbox Code Playgroud)
可能按预期给出
origin https://github.com/xxxx/xxxx.git (fetch)
origin https://github.com/xxxx/xxxx.git (push)
Run Code Online (Sandbox Code Playgroud)
请注意
git branch
Run Code Online (Sandbox Code Playgroud)
此时不会向您显示任何内容,因为您尚未创建任何分支,也无法创建任何分支。
问题:
当我尝试
git push -u origin main
Run Code Online (Sandbox Code Playgroud)
我有
error: src refspec main does not match any
error: failed to push some refs to 'github.com:xxxx/xxxx.git'
Run Code Online (Sandbox Code Playgroud)
即使使用 git 推荐的命令
git push --set-upstream origin master (or main preferably)
Run Code Online (Sandbox Code Playgroud)
我得到了同样的错误。
现在解决方案:
在你的项目中添加一个文件,比如 README.md
git add .
git commit -m "added README.md"
git branch -M main
Run Code Online (Sandbox Code Playgroud)
如果您不希望它被称为 master,则 -M 是重命名您的分支
最后,
git push origin main
Run Code Online (Sandbox Code Playgroud)
在进行了更多研究并发现空洞之后,我尝试了一个 hack。这里是。
在git push -f origin HEAD:main我完全删除我的本地项目文件夹之后,然后从主分支克隆了我的项目。现在我可以git push origin main用来推送我想要的任何更改。我检查了一下,现在我的项目位置有一个main文件.git/refs/heads。
如果这是您第一次推送到主分支,请在提交更改后按照以下步骤操作。我遇到了这个错误:
src refspec main does not match any
error: failed to push some refs to 'https://github.com/<my_project_name>.git
Run Code Online (Sandbox Code Playgroud)
我在提交后修复了这些步骤。在以下代码中更改 github 的 URL:
git branch -M main
git remote add origin https://github.com/Sidrah-Madiha/<my_project_url>.git
git push -u origin main
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
29932 次 |
| 最近记录: |