跟踪多个 Git 远程仓库

拥有一致的命名标准是保持本地和上游 Git 仓库清晰的关键。

图片来源：

Opensource.com

当本地 Git 仓库中远程仓库的名称不一致时，使用远程仓库会变得混乱。

解决此问题的一种方法是标准化两个词的使用和含义：origin，指代您的个人 example.com/<USER>/* 仓库，以及 upstream，指代您从中 fork 出 origin 仓库的 example.com 仓库。换句话说，upstream 指的是公开提交工作的上游仓库，而 origin 指的是您从其中生成拉取请求 (PR) 的上游仓库的本地 fork，例如。

以 pbench 仓库为例，以下是设置新的本地克隆并一致定义 origin 和 upstream 的分步方法。

在大多数 Git 托管服务上，当您想要处理一个项目时，必须 fork 该项目。当您运行自己的 Git 服务器时，这不是必需的，但对于对公众开放的代码库，这是一种在贡献者之间传输差异的简便方法。

创建一个 Git 仓库的 fork。对于本示例，假设您的 fork 位于 example.com/<USER>/pbench。
接下来，您必须获取用于通过 SSH 克隆的统一资源标识符 (URI)。在大多数 Git 托管服务（例如 GitLab 或 GitHub）上，它位于标记为 Clone 或 Clone over SSH 的按钮或面板中。将克隆 URI 复制到剪贴板。
在您的开发系统上，使用您复制的文本克隆仓库
```
$ git clone git@example.com:<USER>/pbench.git
```
这将克隆 Git 仓库，并将默认名称 origin 用于您的 pbench 仓库的 fork 副本。
将目录更改为您刚刚克隆的仓库
```
$ cd ~/pbench
```
接下来，获取源仓库（您最初 fork 的仓库）的 SSH URI。这可能与上述方法相同：找到 Clone 按钮或面板并复制克隆地址。在软件开发中，这通常被称为“upstream”，因为（理论上）这是大多数提交发生的地方，并且您打算让这些提交向下游流入您的仓库副本。
将 URI 添加到您的本地仓库副本。是的，将有两个不同的远程仓库分配给您的本地仓库副本
```
$ git remote add upstream git@example.com:bigproject/pbench.git
```
现在您有两个命名的远程仓库：origin 和 upstream。您可以使用 remote 子命令查看您的远程仓库
```
$ git remote -v
```
目前，您的本地 master 分支正在跟踪 origin master，但这不一定是您想要的。您可能想要跟踪此分支的 upstream 版本，因为 upstream 是大多数开发发生的地方。其理念是，您在从 upstream 获取的任何内容之上添加您的更改。
更改您的本地 master 分支以跟踪 upstream/master
```
$ git fetch upstream
$ git branch --set-upstream-to=upstream/master master
```
您可以对任何您想要的分支执行此操作，而不仅仅是 master。例如，某些项目使用 dev 分支来处理所有不稳定的更改，而将 master 保留用于批准发布的代码。
设置跟踪分支后，请务必 rebase 您的 master 以使其与对上游仓库所做的任何新更改保持同步
```
$ git remote update
$ git checkout master
$ git rebase
```