@geekpi
This commit is contained in:
Xingyu Wang
2020-12-11 22:10:39 +08:00
parent f2d2937fef
commit b0c67ddca8

View File

@@ -1,6 +1,6 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Keep track of multiple Git remote repositories)
@@ -9,57 +9,54 @@
跟踪多个 Git 远程仓库
======
拥有一致的命名标准是保持本地和上游 Git 仓库保持直线的关键。
![Digital hand surrounding by objects, bike, light bulb, graphs][1]
当本地 Git 仓库的名称与远程仓库不一致时,与远程仓库协作就会变得很混乱
> 拥有一致的命名标准是保持本地和上游 Git 仓库保持一致的关键
解决此问题的一个方法是标准化两个词的使用和含义:`origin` 指的是你个人的 `example.com/<USER>/*` 仓库,而 `upstream` 指的是你从 `origin` 仓库分叉出来的 `example.com` 仓库。换句话说,`upstream` 指的是公开提交工作的上游仓库,而 `origin` 指的是你在上游仓库的本地分叉,例如,你从那里生成拉取请求 PR
![](https://img.linux.net.cn/data/attachment/album/202012/11/220828tjt9qlpmg1opvibq.jpg)
当本地 Git 仓库的命名与远程仓库不一致时,与远程仓库协作就会变得很混乱。
解决此问题的一个方法是标准化两个词的使用和含义:`origin` 指的是你个人的 `example.com/<USER>/*` 仓库,而 `upstream` 指的是你从 `origin` 仓库<ruby>复刻<rt>fork</rt></ruby>出来的 `example.com` 仓库。换句话说,`upstream` 指的是公开提交工作的上游仓库,而 `origin` 指的是你对上游仓库的本地复刻,例如,你从这里生成<ruby>拉取请求<rt>pull request</rt></ruby>PR
以 [pbench][2] 仓库为例,下面是一个逐步建立新的本地克隆的方法,其中 `origin``upstream` 的定义是一致的。
1. 在大多数 Git 托管服务上,当你想在上面工作时,必须对它进行分叉。当你运行自己的 Git 服务器时,这并不是必要的,但对于一个公开的代码库来说,这是一个在贡献者之间传输差异的简单方法。
1、在大多数 Git 托管服务上,当你想在上面工作时,必须对它进行复刻。当你运行自己的 Git 服务器时,这并不是必要的,但对于一个公开的代码库来说,这是一个在贡献者之间传输差异的简单方法。
创建一个 Git 仓库的复刻。在这个例子中,假设你的复刻位于 `example.com/<USER>/pbench`
创建一个 Git 仓库的分叉。在这个例子中,假设你的分叉位于 `example.com/<USER>/pbench`
2. 接下来,你必须获得一个统一资源标识符 [URI][3]),以便通过 SSH 进行克隆。在大多数 Git 托管服务上,比如 GitLab 或 GitHub它在一个标有 **Clone****Clone over SSH** 的按钮或面板上。将克隆 URI 复制到剪贴板中。
3. 在你的开发系统中,使用你复制的文本克隆仓库:
2、接下来你必须获得一个统一资源标识符 [URI][3]),以便通过 SSH 进行<ruby>克隆<rt>cloning</rt></ruby>。在大多数 Git 托管服务上,比如 GitLab 或 GitHub它在一个标有 “Clone” 或 “Clone over SSH” 的按钮或面板上,可以将克隆 URI 复制到剪贴板中
3、在你的开发系统中使用你复制的 URI 克隆仓库:
```
`$ git clone git@example.com:<USER>/pbench.git`
$ git clone git@example.com:<USER>/pbench.git
```
这将以默认名称 `origin` 来克隆 Git 仓库,作为你的 `pbench` 仓库复刻副本。
这将克隆 Git 仓库,默认名称为 `origin`,作为 pbench 仓库的分叉副本。
4. 切换到刚才克隆的目录:
4、切换到刚才克隆的目录
```
`$ cd ~/pbench`
$ cd ~/pbench
```
5. 下一步,获取源仓库的 SSH URI你最初分叉的那个)。这可能和上面的方法一样。找到 **Clone** 按钮或面板,复制克隆地址。在软件开发中,这通常被称为“上游”,因为(理论上)这是大多数提交发生的地方,而你打算让这些提交流向下游的仓库。
6. 将 URI 添加到你的本地仓库中。是的将有_两个不同_的远程分配给你的本地仓库副本
5、下一步,获取源仓库的 SSH URI你最初复刻的那个)。这可能和上面的方法一样。找到 Clone 按钮或面板,复制克隆地址。在软件开发中,这通常被称为“上游”,因为(理论上)这是大多数提交发生的地方,而你打算让这些提交流向下游的仓库。
6、将 URI 添加到你的本地仓库中。是的,将有*两个不同*的远程仓库分配给你的本地仓库副本:
```
`$ git remote add upstream \ git@example.com:bigproject/pbench.git`
$ git remote add upstream git@example.com:bigproject/pbench.git
```
7. 现在你有两个命名远程仓库:`origin``upstream`。 你可以用远程子命令查看你的远程仓库:
7、现在你有两个命名远程仓库:`origin``upstream`。 你可以用 `remote` 子命令查看你的远程仓库:
```
`$ git remote -v`
$ git remote -v
```
现在,你的本地 `master` 分支正在跟踪 `origin` master这不一定是你想要的。你可能想跟踪这个分支的 `upstream` 版本,因为大多数开发都在上游进行。 这个想法是,你要在从上游获得的内容的基础上添加更改。
8. 将你的本地的 master 分支改成跟踪 `upstream/master`
现在,你的本地 `master` 分支正在跟踪 `origin` `master`,这不一定是你想要的。你可能想跟踪这个分支的 `upstream` 版本,因为大多数开发都在上游进行。这个想法是,你要在从上游获得的内容的基础上添加更改。
8、将你的本地的 `master` 分支改成跟踪 `upstream/master`
```
$ git fetch upstream
@@ -68,8 +65,7 @@ $ git branch --set-upstream-to=upstream/master master
你可以对任何你想要的分支这样做,而不仅仅是 `master`。例如,有些项目使用 `dev` 分支来处理所有不稳定的变化,而将 `master` 保留给已批准发布的代码。
9. 一旦你设置了你的跟踪分支,一定要 `rebase` 你的 master 分支,使它与上游仓库的任何新变化保持一致:
9、一旦你设置了你的跟踪分支,一定要变基(`rebase`你的 `master` 分支,使它与上游仓库的任何新变化保持一致:
```
$ git remote update
@@ -77,11 +73,7 @@ $ git checkout master
$ git rebase
```
这是一个保持 Git 仓库在不同分叉之间同步的好方法。如果你想自动完成这项工作,请阅读 Seth Kenlon 关于[使用 Ansible 托管 Git 仓库][4]的文章。
这是一个保持 Git 仓库在不同复刻之间同步的好方法。如果你想自动完成这项工作,请阅读 Seth Kenlon 关于[使用 Ansible 托管 Git 仓库][4]的文章。
--------------------------------------------------------------------------------
@@ -90,7 +82,7 @@ via: https://opensource.com/article/20/11/multiple-git-repositories
作者:[Peter Portante][a]
选题:[lujun9972][b]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出