我无法将原点/母版作为跟踪分支添加到本地母版分支
git checkout --track origin/master
fatal: 'origin/master' is not a commit and a branch 'master' cannot be created from it
我的fork中已经包含一些提交。 Remote(fork)也有1个带有README的提交。可能是什么问题?
编辑:运行git fetch origin
后,错误消息将更改:
git checkout --track origin/master
fatal: A branch named 'master' already exists.
答案 0 :(得分:1)
我不清楚您最初是如何创建本地存储库的,但是我怀疑您是这样做的:
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
。
返回并重新检查所有先前的图,并考虑如下问题:
C
和master
这样的origin/master
输出中看到这些大的丑陋哈希ID)是Git查找提交的方式。通过在每个名称中存储 last 哈希ID,Git可以找到所有最后一个。每个提交本身都会存储其前身的丑陋哈希ID:提交git log
指向提交C
或提交A
或两者,这取决于我们的制作方式。真正重要的是 commits 。 Git为您提供了名称,因为名称对人类(他们不记得那些丑陋的哈希ID)有一定的意义,然后使用名称来查找。 Git可以按名称查找的那些提交,将存储先前提交的哈希ID。那些较早的提交存储了什至较早的提交的哈希ID,依此类推。 B
命令仅从当前 end 开始,并向后工作,向您显示行进中的提交。
答案 1 :(得分:0)
git fetch -apt
git remote -v
git remote add origin <your repo>
git tag -l old-master
git branch -D master
git switch -c <branch> --track <remote>/<branch>