这个问题很难问，因为我很困惑，真的不明白发生了什么。更重要的是，我仍然无法理解 git，我不在任何团队中工作，我只使用它来保存我在本地所做的更改，总是在一个分支上。
推送提交时，我不小心输入了"origin main"而不是"origin master"。我没有一个名为 main 的分支。
我收到一个错误：src refspec main 与任何不匹配 错误：无法将一些引用推送到"(...)"，我的工作目录已被清理。
在此之后，我对此提交进行了软重置，但工作目录仍然干净。我不知道现在该怎么办，而且 - 老实说 - 我不明白我现在在哪里。
我应该怎么做才能撤消此"拼写错误"操作并将我的更改视为未提交？
我不明白我现在在哪里
因为您执行了git push origin/main，所以您的更改现在位于服务器(origin)的main分支上。origin上还有一个master分支;它就在main后面.
我应该怎么做才能撤消此"拼写错误"操作并将我的更改视为未提交？
假设您所做的只是git push，您的更改也仍存储为本地副本。因为你没有使用拉取请求，我敢打赌你是唯一在这个仓库上工作的开发人员，而且你不需要从源运行拉取。因此，本地分支和origin/master之间的差异应与您刚刚推送到错误分支的差异完全相同。
我对此提交进行了软重置，但工作目录仍然干净
这是因为您的工作目录是最新的origin/main.
为了确保origin/master使用最新的更改进行更新，您只需执行git push origin/master即可。在此之后，您可以安全地删除源上的main分支。
推送提交时，我不小心输入了"origin main"而不是"origin master"。我没有一个名为 main 的分支。
没关系：
我得到了一个
error: src refspec main does not match any error: failed to push some refs to '(...)'
这是完全正常的。此时什么也没发生。
我的工作目录被清理干净了。
这是不正常的(好吧，这取决于你所说的"清理"是什么意思)，你一定做了别的事情。 正如你所说，虽然你不太确定你做了什么。
在此之后，我对此提交进行了软重置，但工作目录仍然干净。我不知道现在该怎么办，而且 - 老实说 - 我不明白我现在在哪里。
如果你的意思是你跑了：
git reset --soft
这可能什么也没做。 它究竟做了什么将取决于你在那之前处于什么状态，我们当然看不到。git push origin main什么也没做，并没有影响那个状态。
如果您提交了所有文件，那么它们当前在 Git中，无论您执行其他操作，只要您保留存储库本身，您就可以将它们取回。
当你说你的工作目录被"清理"时，如果你的意思是git status说nothing to commit, working directory clean，那也是完全正常的。
您的工作目录包含文件(以及您的操作系统坚持创建以保存这些文件的文件夹/目录)，您可以在其中查看和处理文件。 这些文件在任何有用的意义上都不在 Git 中。 它们就在你的工作树中。
Git 中的内容是一个包含提交的大型数据库，以及其他支持对象。 每个提交都有一个数字 - 一个丑陋的随机事物，以十六进制表示 - 对于一个特定的提交是唯一的。 这个数字是 Git 最终找到提交的方式。
运行git log将显示提交，从当前提交开始。 仓库中的一个提交始终是当前提交的1：这是您已签出的提交。 当您签出一些提交时，Git 会提取这些文件的已提交版本，并将副本粘贴到您的工作树中，以便您可以查看和使用它们。
使用git checkout和唯一的提交编号，您可以选择要提取的任何提交。 Git 将从你的工作树中删除它之前提取的副本，从当前的任何提交中删除，并切换到从你选择的提交中提取的副本。 该提交将成为当前提交。 因此，每次提交都会将所有文件(截至提交时的状态)永久保存，以便您可以取回旧版本，然后切换回较新版本。
但是那些丑陋的大数字，deadbeef的，badc0ffee的，dadcafe的，f031905de2的，或者其他什么，它们中的大多数都是无法发音的——不像我在这里像cabbabe一样聪明的数字——人类不可能与之合作。 所以我们使用分支名称和其他名称。 Git 安排这些名称来挑选一个特定的提交。 这就是像master或main这样的名字进来的地方。
当您创建新的 Git 存储库时，GitHub 托管站点通常会在其中保留一个初始提交。 下面的脚注 1 解释了一次初始提交的完整原因，但它允许分支名称存在。他们现在用名字称呼这个初始分支main.
当您创建新的 Git 存储库时，您正在使用的 Git 软件会使其完全为空。 它说你在一个"未出生的分支"上，或者no commits yet，或者类似的东西——确切的消息取决于你的 Git 版本(以及你使用的任何语言翻译)。 当你创建你的第一次提交时，那就是 Git 创建一个分支名称的时候，此时，当前的 Git 软件会创建一个名为master的分支，而不是一个名为main的分支。
如果您愿意，您现在可以将master重命名为main，使用：
git branch -m master main
这里的-m标志代表移动，这是一种拼写重命名的有趣方式。阿拉伯数字
将master重命名为main后，您的使用情况将与 GitHub 的使用情况匹配，您可以尝试git push origin main。 但是请注意，如果您让 GitHub 创建第一次提交，并且您进行了自己的第一次提交，那么您现在有两个不同的首次提交。 Git 不能在一个名称下有两个首次提交，所以你现在必须选择如何处理它。
如果你告诉 GitHub 在那里创建你的仓库作为一个完全空的仓库，没有提交，你在这里就可以了：git push origin main会推送你重命名为main的提交，这将在 GitHub 上创建main，一切都会好起来的。
1此规则有一个例外，Git 用几个不同的名称调用它：孤立分支或未出生分支。 在此状态下，当前没有提交。
这种状态必须能够存在，因为当你创建一个全新的、完全空的 Git 存储库时，它没有提交。 因此，没有现有的提交可以充当当前提交。 所以 Git 需要一个"当前无提交"的状态。 在遥远的过去，制作一个新的、完全空的存储库是获得它的唯一方法。 然后有人想：天哪，至少为了测试，如果没有别的，我们应该能够重新创建那个状态，他们发明了--orphan标志，并称之为孤儿分支。 但这是一个不好的名字，所以他们把它改成了未出生的分支，没有改变旗帜，现在我们有这种混乱。
在这种奇怪的状态下，在一个新的完全空的存储库中，不允许存在任何分支名称。 所以这也相当令人困惑。 当您处于此状态(此未出生或孤立分支状态)时，尚未提交，您所做的第一个提交将成为当前提交，从而创建分支。 这允许分支名称出现。 因此，Git 所做的是记录您所在的名称，而无需创建名称。 然后你进行提交，Git 创建名称，让它选择你刚刚进行的新提交，从而解决问题。
GitHub 将通过为您创建初始提交来完全回避这个问题，这也允许他们创建分支名称。 这解决了整个孤儿/未出生分支的问题。 当每个人都同意第一个分支的名称时——master——这一切都运行良好，但现在 GitHub 使用main而其他人使用master，它会产生自己的问题。
2使用move表示重命名来自Linuxmv命令，用于"移动文件"。 这个名字又来自Unix，所以这是一个历史性的事情。