document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-28 23:20:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #20329 from geekpi/translating

Browse Source 
translated
This commit is contained in:
geekpi 2020-12-03 08:39:08 +08:00 committed by GitHub
commit 5500b912f5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 102 additions and 102 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
sources/tech/20201125 Keep track of multiple Git remote repositories.md
View File

@ -1,102 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: 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)
Keep track of multiple Git remote repositories
======
Having consistent naming standards is key to keeping local and upstream
Git repos straight.
![Digital hand surrounding by objects, bike, light bulb, graphs][1]
Working with remote repositories gets confusing when the names of the remote repositories in your local Git repo are inconsistent.
One approach to solving this issue is to standardize the use and meaning of two words: `origin`, referring to your personal `example.com/<USER>/*` repos, and `upstream`, referring to the `example.com` repo from which you forked the `origin` repo. In other words, `upstream` refers to the upstream repo where work is publicly submitted, while `origin` refers to your local fork of the upstream repo from which you generate pull requests (PRs), for example.
Using the [pbench][2] repo as an example, here is a step-by-step approach to set up a new local clone with `origin` and `upstream` defined consistently.
1. On most Git hosting services, you must fork a project when you want to work on it. When you run your own Git server, that's not necessary, but for a codebase that's open to the public, it's an easy way to transfer diffs among contributors.
Create a fork of a Git repository. For this example, assume your fork is located at `example.com/<USER>/pbench`.
2. Next, you must obtain a Uniform Resource Identifier ([URI][3]) for cloning over SSH. On most Git hosting services, such as GitLab or GitHub, it's in a button or panel labeled **Clone** or **Clone over SSH**. Copy the clone URI to your clipboard.
3. On your development system, clone the repo using the text you copied:
```
`$ git clone git@example.com:<USER>/pbench.git`
```
This clones the Git repository with the default name `origin` for your forked copy of the pbench repo.
4. Change directory to the repo you just cloned:
```
`$ cd ~/pbench`
```
5. Next, obtain the SSH URI of the source repo (the one you originally forked). This is probably done the same way as above: Find the **Clone** button or panel and copy the clone address. In software development, this is typically referred to as "upstream" because (in theory) this is where most commits happen, and you intend to let those commits flow downstream into your copy of the repository.
6. Add the URI to your local copy of the repository. Yes, there will be _two different_ remotes assigned to your local copy of the repository:
```
`$ git remote add upstream \ git@example.com:bigproject/pbench.git`
```
7. You now have two named remote repos: `origin` and `upstream`. You can see your remote repos with the remote subcommand:
```
`$ git remote -v`
```
Right now, your local `master` branch is tracking the `origin` master, which is not necessarily what you want. You probably want to track the `upstream` version of this branch because upstream is where most development takes place. The idea is that you are adding your changes on top of whatever you get from upstream.
8. Change your local master branch to track `upstream/master`:
```
$ git fetch upstream
$ git branch --set-upstream-to=upstream/master master
```
You can do this for any branch you want, not just `master`. For instance, some projects use a `dev` branch for all unstable changes, reserving `master` for code approved for release.
9. Once you've set your tracking branches, be sure to `rebase` your master to bring it up to date to any new changes made to the upstream repo:
```
$ git remote update
$ git checkout master
$ git rebase
```
This is a great way to keep your Git repositories synchronized between forks. If you want to automate this, read Seth Kenlon's article on [cohosting Git repositories with Ansible][4] to learn how.
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/11/multiple-git-repositories
作者：[Peter Portante][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/portante
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003588_01_rd3os.combacktoschoolseriesk12_rh_021x_0.png?itok=fvorN0e- (Digital hand surrounding by objects, bike, light bulb, graphs)
[2]: https://github.com/distributed-system-analysis/pbench
[3]: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
[4]: https://opensource.com/article/19/11/how-host-github-gitlab-ansible

102
translated/tech/20201125 Keep track of multiple Git remote repositories.md Normal file
View File

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