滥用一些术语,每个 git repo 本身很像一个明确的私人视图:你不能直接看到其他人的。(但我稍后会提到一条捷径。)
幸运的是,你可以间接看到他,因为你们两个有第三个共享仓库。他推送到共享存储库,然后您fetch
(还没有pull
,因为这会使答案复杂化)从共享存储库中推送。现在你可以看到他做了什么,因为fetch
抓住(无论如何默认)一切。
不过,这就是 git 与 clearcase 非常不同的地方:您可以通过要求 git 将其提取到可见的地方来“看到他做了什么”。它不会“只是出现”,你必须告诉它“让我看看”。
您可以通过执行以下一项或多项操作来查看它:
- 要求 git(或 GUI)显示差异
- 要求 git 在当前工作树中检出一个不同的分支(这里有明显的冲突可能性)
- 要求 git 从特定分支中检出一个或多个特定文件的内容到当前工作树中
- 要求 git 将不同的分支签出到不同的(可能是新的)工作树中
所有这些都需要了解如何指定特定的修订(通过“分支名称”或提交 ID 或其他)。这里有两个重要的事情要记住:
- 当您克隆和获取时,git 会创建名称类似于
remotes/origin/master
和的分支remotes/origin/bug_b
。
- 当您在仓库中本地工作时,git 会创建名称如
master
和的分支bug_a
。
因此,要查看已fetch
编入的更改remotes/origin/bug_b
,请使用:
git log remotes/origin/bug_b
请注意,您不需要拥有自己的名为 的分支bug_b
,更不用说进行任何合并或拉取或其他操作。当您只想查看时,只需命名远程分支。如果您要在分支上做自己的工作,您只需要自己的分支名称bug_b
。
这里有一个更深层次的东西,你还不需要理解,但你应该不时回到它:一个分支名称remotes/origin/bug_b
真的只是一种象征性的方式来命名那些大的 git SHA1 值之一,比如ae0af6d748b98716f0f72e428728345b828c4067
. 当您fetch
获取所有新文件和树等,以及所有具有那些大毛ID的提交并将它们全部填充到您的存储库时,git会做什么;然后更新remotes/x/y
标签指向每个“远程分支”的“提示”。你的 repo 拥有每个人做过的所有事情,如果需要,就在你的指尖。(有时结果是“太多”,因此有一些方法可以限制您实际拥有的数量,但“一切”是默认设置,也是考虑它的方式。)(用清晰的术语来说,你有一个每个 VOB 的完整副本。幸运的是 git 比 clearcase 更节省空间和时间。)
当您执行 a 时,git pull
您实际上是在做两件事: a git fetch
——这就是拉动变化的原因——然后(通常) a git merge
。合并将“其他人所做的工作”与“您所做的工作”结合在一起。当您获取 Bobbug_b
在您自己的bug_a
分支上工作时所做的更改时,您不希望这样。
(可选地,你可以告诉 git 让git pull
meangit fetch
后跟git rebase
。但你也不想要那个。坚持使用git fetch
。)
现在,对于那个快捷方式:如果您git clone
是原始共享存储库,那么您必须等待 Bob 将git push
他的bug_b
更改返回到共享存储库,然后才能看到它们。但是,如果 Bob 授予您对他的私有 repo 的读取访问权限(通过 ssh 或其他方式),您可以将 Bob 的 repo 添加为备用“远程”。例如,remotes/origin/bug_b
您可以命名这个遥控器remotes/bob/
,并参考remotes/bob/bug_b
. 你可以用git remote update bob
. 不过,除非你能与 Bob 协调,否则不要为这一切烦恼。你们俩的单一共享存储库push
通常是要走的路。