From b0c67ddca8adf7a2f5d21ffe502119358f2e27d7 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Fri, 11 Dec 2020 22:10:39 +0800 Subject: [PATCH 1/2] PRF @geekpi --- ...ack of multiple Git remote repositories.md | 62 ++++++++----------- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/translated/tech/20201125 Keep track of multiple Git remote repositories.md b/translated/tech/20201125 Keep track of multiple Git remote repositories.md index f96a4c220d..ab131b84a5 100644 --- a/translated/tech/20201125 Keep track of multiple Git remote repositories.md +++ b/translated/tech/20201125 Keep track of multiple Git remote repositories.md @@ -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//*` 仓库，而 `upstream` 指的是你从 `origin` 仓库分叉出来的 `example.com` 仓库。换句话说，`upstream` 指的是公开提交工作的上游仓库，而 `origin` 指的是你在上游仓库的本地分叉，例如，你从那里生成拉取请求 （PR）。 +![](https://img.linux.net.cn/data/attachment/album/202012/11/220828tjt9qlpmg1opvibq.jpg) + +当本地 Git 仓库的命名与远程仓库不一致时，与远程仓库协作就会变得很混乱。 + +解决此问题的一个方法是标准化两个词的使用和含义：`origin` 指的是你个人的 `example.com//*` 仓库，而 `upstream` 指的是你从 `origin` 仓库复刻fork出来的 `example.com` 仓库。换句话说，`upstream` 指的是公开提交工作的上游仓库，而 `origin` 指的是你对上游仓库的本地复刻，例如，你从这里生成拉取请求pull request（PR）。 以 [pbench][2] 仓库为例，下面是一个逐步建立新的本地克隆的方法，其中 `origin` 和 `upstream` 的定义是一致的。 - 1. 在大多数 Git 托管服务上，当你想在上面工作时，必须对它进行分叉。当你运行自己的 Git 服务器时，这并不是必要的，但对于一个公开的代码库来说，这是一个在贡献者之间传输差异的简单方法。 +1、在大多数 Git 托管服务上，当你想在上面工作时，必须对它进行复刻。当你运行自己的 Git 服务器时，这并不是必要的，但对于一个公开的代码库来说，这是一个在贡献者之间传输差异的简单方法。 + +创建一个 Git 仓库的复刻。在这个例子中，假设你的复刻位于 `example.com//pbench`。 - 创建一个 Git 仓库的分叉。在这个例子中，假设你的分叉位于 `example.com//pbench`。 - - 2. 接下来，你必须获得一个统一资源标识符 （[URI][3]），以便通过 SSH 进行克隆。在大多数 Git 托管服务上，比如 GitLab 或 GitHub，它在一个标有 **Clone** 或 **Clone over SSH** 的按钮或面板上。将克隆 URI 复制到剪贴板中。 - - 3. 在你的开发系统中，使用你复制的文本克隆仓库： +2、接下来，你必须获得一个统一资源标识符 （[URI][3]），以便通过 SSH 进行克隆cloning。在大多数 Git 托管服务上，比如 GitLab 或 GitHub，它在一个标有 “Clone” 或 “Clone over SSH” 的按钮或面板上，可以将克隆 URI 复制到剪贴板中。 +3、在你的开发系统中，使用你复制的 URI 克隆仓库： ``` -`$ git clone git@example.com:/pbench.git` +$ git clone git@example.com:/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/) 荣誉推出 From d55d3e01818e092f142c1bc48d3fe21d97f82508 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Fri, 11 Dec 2020 22:13:36 +0800 Subject: [PATCH 2/2] PUB @geekpi https://linux.cn/article-12911-1.html --- ...20201125 Keep track of multiple Git remote repositories.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename {translated/tech => published}/20201125 Keep track of multiple Git remote repositories.md (98%) diff --git a/translated/tech/20201125 Keep track of multiple Git remote repositories.md b/published/20201125 Keep track of multiple Git remote repositories.md similarity index 98% rename from translated/tech/20201125 Keep track of multiple Git remote repositories.md rename to published/20201125 Keep track of multiple Git remote repositories.md index ab131b84a5..4c1ce8711e 100644 --- a/translated/tech/20201125 Keep track of multiple Git remote repositories.md +++ b/published/20201125 Keep track of multiple Git remote repositories.md @@ -1,8 +1,8 @@ [#]: collector: (lujun9972) [#]: translator: (geekpi) [#]: reviewer: (wxy) -[#]: publisher: ( ) -[#]: url: ( ) +[#]: publisher: (wxy) +[#]: url: (https://linux.cn/article-12911-1.html) [#]: subject: (Keep track of multiple Git remote repositories) [#]: via: (https://opensource.com/article/20/11/multiple-git-repositories) [#]: author: (Peter Portante https://opensource.com/users/portante)