我不清楚您最初是如何创建本地存储库的，但是我怀疑您是这样做的：

mkdir new-repo
cd new-repo
git init

，然后创建一些文件并git add对其进行编辑并提交结果。这样，您将得到一个只有一个提交且没有origin远程的新存储库，因此您将不得不运行：

git remote add origin ssh://git@github.com/your/repo.git

或类似的

我不清楚您是如何在GitHub上创建your/repo.git（或其路径可能是什么）的，但是我怀疑您使用了“使用README文件创建新存储库”按钮。

如果所有这些“怀疑”都是正确的，则说明一切。您的最初错误：

fatal: 'origin/master' is not a commit and ...

发生这种情况是因为您尚未将Git连接到保存您在GitHub创建的存储库的GitHub Git。

然后，您运行git fetch origin，它将您的Git连接到他们的Git，并获得其（单个）包含README文件的提交。您的Git将他们的提交复制到您的存储库中。然后，您的Git创建了自己的origin/master远程跟踪名称，以记住其（单个）提交的哈希ID。

您现在有两个初始（从零创建）提交，Git称为 root 提交。如果我们绘制您的存储库图，它可能看起来像这样：

A   <-- master

B   <-- origin/master

您的第一次提交（在此表示为A（无论其实际的哈希ID可能是什么）都保存您提交的文件。您的分支机构名称master标识了这一提交。

他们的首次提交（在此表示为B）保存了他们提交的文件。您的远程跟踪名称origin/master标识此一次提交。

您现在要求Git使用master通过失败的命令创建一个新的分支名称B，指向提交origin/master：

git checkout --track origin/master
fatal: A branch named 'master' already exists.

错误消息的原因很明显：您已经有一个分支名称master，指向现有的提交A；无法创建指向现有提交master的新的但相同的分支名称B。

该怎么办

您可以从此处进行多种选择。它们主要涉及创建新的提交C。

您可以使用git merge将历史记录（您的一个单独提交）加入他们的历史记录（他们的一个单独提交）。为此，您将需要--allow-unrelated-histories选项，除非您的Git版本足够旧而不能拥有该选项。古老的Git假定应该始终暗示--allow-unrelated-histories。

如果自动生成了单独的提交B，则将这样的历史合并会有点愚蠢。只完全放弃他们的承诺会更有意义。从他们的提交B中获取您认为有用的所有内容，并进行自己的新常规提交C：

A <-C   <-- master

B   <-- origin/master

您的新提交C仅指向您现有的A。您现在可以强迫他们放弃提交B，向他们发送新的C。

或者，您可以继续合并两个提交：

A
 \
  C   <-- master
 /
B   <-- origin/master

您现在可以向他们发送提交C，并要求他们记住自己的master C，后者同时记住A和B。

向他们发送新的提交C（它将带来A，并指向A，并可能还会指向B，具体取决于您的制作方式{ {1}}），使用C。这会发送git push origin master（和C），并以礼貌的请求结束，请他们（如果愿意）将其名字A指向master。如果您故意抛出 C，而没有进行合并，则需要将礼让请求升级为B命令。

完成所有操作后，其 git push --force origin master也将指向（它们现在共享的副本）提交master。您的Git会更新您自己的C来记住他们的origin/master记得master，并且您都同意C是您及其分支机构的最后一次提交，两者其中名为C。

同时，您自己的master不会将master设置为其上游。 没有是没有道理的，但是如果您愿意成为它（请参阅Why do I need to do `--set-upstream` all the time?，则可以使用origin/master，也可以结合使用git branch --set-upstream-to使用git push选项：

-u

或：

git push -u origin master

（只有在您告诉他们时才需要使用git push --force -u origin master 选项：*忘记您的提交--force，这没用，请改用我的B-如果您的{ C指向C）。

您还有更多选择，而不是合并或，它们还会创建一个新的提交B。您可以：

• 使用C将A设为B的基础，或者
• 将您的git rebase -i --root复制到位于其A上方的新提交C上，名为B的新分支上。 li>

通过执行复制工作，然后放弃原来的master来支持这个新的A，从而实现了重新配置：

C

或者：

A   [abandoned / lost - will eventually be garbage collected]

B   <-- origin/master
 \
  C   <-- master

然后，您可以将A <-- master B <-- origin/master \ C <-- newbranch 重命名为master，然后将old-master重命名为newbranch：

master

最后，您现在可以A <-- old-master B <-- origin/master \ C <-- master 向他们发送提交git push -u origin master（这次完全不发送C），并要求他们将A设置为指向到新的提交master。

如何理解所有这些

返回并重新检查所有先前的图，并考虑如下问题：

• 对Git来说重要的是 commits ，它们永远不会改变（但可以被丢弃，最终被完全抛弃）。
像C和master这样的
• 名称只是用来按某些提交顺序查找 last 提交。
• 任何提交的哈希ID（您将在origin/master输出中看到这些大的丑陋哈希ID）是Git查找提交的方式。通过在每个名称中存储 last 哈希ID，Git可以找到所有最后一个。每个提交本身都会存储其前身的丑陋哈希ID：提交git log指向提交C或提交A或两者，这取决于我们的制作方式。

真正重要的是 commits 。 Git为您提供了名称，因为名称对人类（他们不记得那些丑陋的哈希ID）有一定的意义，然后使用名称来查找。 Git可以按名称查找的那些提交，将存储先前提交的哈希ID。那些较早的提交存储了什至较早的提交的哈希ID，依此类推。 B命令仅从当前 end 开始，并向后工作，向您显示行进中的提交。

• 获取最新版本
  git fetch -apt
• 使用
  检查遥控器是否正确 git remote -v
  如果遥控器不正确，请执行git remote add origin <your repo>
• 使用标签保存当前的master分支：
  git tag -l old-master
• 删除本地母版（您已经使用标记将其保存了）
  git branch -D master
• 获取最新的远程主服务器
  git switch -c <branch> --track <remote>/<branch>