我向自己的Repo A
分叉了一个存储库,创建了一个新的分支A并做了一些工作,然后将远程存储库更改为我要为其发出拉取请求Repo B
的存储库。但是我的分支仍在跟踪对Repo A
主分支的提交。如何更改我的基础为Repo B
的主分支。我已经推送到正确的远程分支
我已经尝试过`git rebase --onto master
(commit 1) - master
\-- (commit 2) - (commit 3) - demo
\-- (commit 4) - (commit 5) - PRO
(commit 1) - master
|-- (commit 2) - (commit 3) - demo
\-- (commit 4) - (commit 5) - PRO
答案 0 :(得分:2)
Git本身没有基本分支的概念。分支(大多数情况下,人们以不同的方式使用该词;请参见What exactly do we mean by "branch"?)只是一个名称,该名称包含提交的哈希ID。名称标识的提交称为 tip commit 。该提交几乎可以肯定至少有一个 parent commit ,并且其父级也在分支中。父母犯有自己的父母。这些提交也在分支上。通过从顶端开始并向后工作,您所获得的链将枚举分支中的所有提交。
如果您移动分支标签(Git将允许您随意移动它),则更改分支上的提交,而无需更改任何提交本身。只要提交本身仍在存储库中,就可以根据需要创建任意多个分支名称。将提交视为一系列连接:
C--D--E <-- branch1
/
...--A--B
\
F--G--H <-- branch2
您可以在任何需要的地方添加和删除标签,而无需实际更改(除非现在有了提交B
的名称):
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
git rebase
的作用是复制一组提交,例如,将新副本放在该组提交中更合适的位置。例如,假设当前从branch2
仅可到达三个 提交-从右侧开始,向左移动,我们找到H
,然后是G
,然后F
-如果它们在对branch1
的 last 提交之后出现,将会得到改善。为此,您可以运行:
git checkout branch2
git rebase --onto branch1 branch3
告诉Git的:从我所在的地方branch2
查找提交,但在两个分支汇合的branch3
处停止查找。既然您已经有了正确提交的列表,则将它们逐个复制,从F
开始,然后依次进行G
和最后H
。在开始复制提交之前,请签出提交E
。
我们将F
的副本称为F'
,以表示它与F
有多么相似,即使它具有不同的哈希ID。复制完成后,图片将如下所示:
F' <-- HEAD
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
重新建立基础将继续复制G
和H
,然后作为最后一步,将名称branch2
向上拉,使其指向{{1 }}:
H
由于默认情况下 F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H [abandoned]
不会显示任何放弃的提交,因此在运行git log
时,您将看到:
git log
,它将看起来像提交已移动。他们没有:它们被更新的更明亮的提交所取代,而旧的沉闷的提交仍在存储库中。 (如果发现新的闪亮字母已损坏,则可以将名称 F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
改回原始字母,只要您在它们过期之前就将它们捕获即可。默认情况下,它们至少还可以使用30天。 )
根据this GitHub page,基本分支的 GitHub 概念是:
父存储库的默认分支。
父存储库的概念同样适用于GitHub:Git存储库没有父级。
GitHub帮助页面上继续说:
如果默认的父存储库不正确,则可以使用下拉列表更改父存储库和分支...
因此,要更改父存储库,请使用GitHub Web界面。选择正确的父存储库后,基本分支将是该存储库的默认分支。要更改GitHub托管的存储库的默认分支,请使用GitHub Web界面(如this page中所述)。
有关协作的更多GitHub信息,请从this page开始。