如果我遵循正确的流程来用原始存储库更新我的fork,我在上游存在一个问题。我应该做类似
git remote add upstream 'link'
然后
git fetch upstream
更新该上游/母版
这意味着它是一个跟踪存储库。也可以将其创建为上游跟踪分支吗?然后我可以像
git checkout branchname
两种方法有什么区别?
答案 0 :(得分:4)
我认为您将远程存储库与远程跟踪分支混淆了。
给定一个存储库R
,一个远程存储库是R
的一个副本,通常通过网络与之物理分隔。
如果要跟踪远程存储库中发生的情况,请从R
添加对其的引用。此引用称为 remote ,按照惯例,通常将其命名为origin
。
来自Git词汇表:
大多数项目都至少跟踪一个上游项目。默认情况下,原点用于此目的。
就Git而言,所有存储库的创建方式都是相同的-然而,在几乎所有项目中,都有一个存储库层次结构,其中每个人都同意的存储库顶部是经典一个。
这是一个例子:
+-------+
| |
| Git | <-- upstream
| |
+---+---+
^
|
+---------+---------+
| |
| Git for Windows | <-- origin
| |
+---------+---------+
^
|
+------+------+
| |
| Your Fork |
| |
+-------------+
从Your Fork
的角度看,如果您想跟踪Git for Windows
中发生的情况,您将调用该远程存储库origin
,因为这是您克隆的存储库。
如果您还想跟踪规范Git
存储库中发生的情况,您将命名该远程引用upstream
,因为它是更进一步的存储库层次结构,其中向下更改流。
Git glossary总结了distinction between origin and upstream well:
大多数项目都至少跟踪一个上游项目。默认情况下,起源用于此目的。新的上游更新将被提取到名为origin / of-streamstream-branch的远程跟踪分支中。
这使我们想到下一个问题。
远程跟踪分支是要跟踪的远程存储库中存在的分支。
再次从Git glossary:
一个引用,用于跟踪另一个存储库中的更改。
这些分支通常被命名为:
<remote-name>/<branch-name>
允许您将它们与本地分支(即仅存在于本地存储库中的分支)区分开来。
例如:
upstream/master <-- master branch in the upstream repo
origin/master <-- master branch in the origin repo
master <-- local master branch
请记住,远程跟踪分支是只读的 —您可以通过运行git fetch
来更新远程分支中发生的任何新提交,但不能提交他们。从这种意义上讲,您可以将它们更多地视为书签。
当您从本地存储库跟踪远程存储库时,很可能您将与其他贡献者在同一分支上工作。
但是,我们知道远程跟踪分支只是书签,因此我们不能直接提交给它们。
解决方案是创建本地分支(我们可以提交)并将其关联到远程分支。这样,我们就可以使用git pull
和git push
快速地将来自远程跟踪分支的更改引入本地,反之亦然。
在这种情况下,its definition的Git词汇表更加神秘:
上游分支
合并到相关分支中的默认分支。
换句话说,上游分支是本地分支的远程配对;这种关系仅仅是作为使那些分支保持同步而不必通过名称显式引用它们的便捷方式。
答案 1 :(得分:0)
要更新fork,请使用master分支:
git remote add upstream 'link'
git checkout master
git fetch upstream
git merge upstream/master
git push origin