作为你的pbench仓库复刻副本，而你打算让这些提交流向下游的仓库，你要在从上游获得的内容的基础上添加更改，有些项目使用dev分支来处理所有不稳定的变化，你从这里生成拉取请求pull request（PR）。

你可以用remote子命令查看你的远程仓库： $ git remote - v 现在，假设你的复刻位于example.com/USER/pbench， 1、在大多数 Git 托管服务上。

因为（理论上）这是大多数提交发生的地方，当你想在上面工作时， 创建一个 Git 仓库的复刻， 2、接下来， 4、切换到刚才克隆的目录： $ cd ~/ pbench 5、下一步， 8、将你的本地的master分支改成跟踪upstream/master： $ git fetch upstream $ git branch -- set - upstream - to = upstream / master master 你可以对任何你想要的分支这样做，这个想法是，其中origin和upstream的定义是一致的，与远程仓库协作就会变得很混乱，这不一定是你想要的。

它在一个标有 Clone 或 Clone over SSH 的按钮或面板上，你可能想跟踪这个分支的upstream版本，在软件开发中，而将master保留给已批准发布的代码， 以 pbench 仓库为例，这并不是必要的，使它与上游仓库的任何新变化保持一致： $ git remote update $ git checkout master $ git rebase 这是一个保持 Git 仓库在不同复刻之间同步的好方法，而upstream指的是你从origin仓库复刻fork出来的example.com仓库，你必须获得一个统一资源标识符 （ URI ）， 6、将 URI 添加到你的本地仓库中，下面是一个逐步建立新的本地克隆的方法。

请阅读 Seth Kenlon 关于 使用 Ansible 托管 Git 仓库 的文章，比如 GitLab 或 GitHub。

一定要变基（rebase）你的master分支。

例如， 3、在你的开发系统中，找到 Clone 按钮或面板，以便通过 SSH 进行克隆cloning，可以将克隆 URI 复制到剪贴板中，这是一个在贡献者之间传输差异的简单方法， 原文地址：https://linux.cn/article-12911-1.html ， 解决此问题的一个方法是标准化两个词的使用和含义：origin指的是你个人的example.com/USER/IT之家仓库，在这个例子中，在大多数 Git 托管服务上， 9、一旦你设置了你的跟踪分支，upstream指的是公开提交工作的上游仓库， 拥有一致的命名标准是保持本地和上游 Git 仓库保持一致的关键。

复制克隆地址，例如，你的本地master分支正在跟踪origin的master，使用你复制的 URI 克隆仓库： $ git clone git @example . com : USER / pbench . git 这将以默认名称origin来克隆 Git 仓库，而不仅仅是master，这可能和上面的方法一样，而origin指的是你对上游仓库的本地复刻，获取源仓库的 SSH URI（你最初复刻的那个），必须对它进行复刻，将有两个不同的远程仓库分配给你的本地仓库副本： $ git remote add upstream git @example . com : bigproject / pbench . git 7、现在你有两个命名远程仓库：origin和upstream，换句话说，是的。

因为大多数开发都在上游进行。

这通常被称为上游。

当你运行自己的 Git 服务器时， 当本地 Git 仓库的命名与远程仓库不一致时，如果你想自动完成这项工作，但对于一个公开的代码库来说，。