Skip to content

Commit

Permalink
Re-read and edit text
Browse files Browse the repository at this point in the history
  • Loading branch information
jennybc committed Jun 16, 2020
1 parent 7aed2c6 commit 374cff0
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions remote-scenarios-supported.Rmd
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ A common next step is to associate a local repo with a copy on GitHub, owned by
knitr::include_graphics("img/ours-you.png")
```

A remote named `origin` is configured and you have permission to push to (and pull from) `origin`. The `origin` remote on GitHub is what we'll call a **primary** repo, meaning it is not a fork (or copy) of anything else on GitHub.
A remote named `origin` is configured and you have permission to push to (and pull from) `origin`. (That's why `origin` is colored blue and there are solid arrows going both directions.) The `origin` remote on GitHub is what we'll call a **primary** repo, meaning it is not a fork (or copy) of anything else on GitHub.

`usethis::use_github()` can create this setup from a local repository, as long as you have configured a `GITHUB_PAT`. usethis describes this setup as "ours".

Expand All @@ -41,11 +41,11 @@ Here is a variation on "ours" that is equivalent in practice.
knitr::include_graphics("img/ours-them.png")
```

A remote named `origin` is configured and you can push to (and pull from) `origin`. As abvoe, `origin` is a **primary** repo, meaning it is not a fork (or copy) of anything else on GitHub. The `origin` remote is, however, not owned by you. Instead it's owned by another GitHub user or organisation.
A remote named `origin` is configured and you can push to (and pull from) `origin`. As above, `origin` is a **primary** repo, meaning it is not a fork (or copy) of anything else on GitHub. The `origin` remote is, however, not owned by you. Instead it's owned by another GitHub user or organisation.

How does this happen?

1. The primary repo is owned by an organisation and your role in this organisation confers enough power to create or push to a repo.
1. The primary repo is owned by an organisation and your role in this organisation confers enough power to create repos or to push to this repo.
2. The owner of the primary repo has added you, specifically, as a collaborator to this specific repo.

Way to get here with usethis:
Expand Down Expand Up @@ -74,17 +74,17 @@ How does this happen?

usethis describes this setup as "theirs".

What if you do want to make a pull request? In hindsight, you should have done *fork-and-clone* instead of *clone*. If you've made no changes or they're easy to save somewhere temporarily, just start over with a fork-and-clone workflow (see below) and re-introduce your changes. It is also possible to preserve your work in a branch, fork the primary repo, re-configure your remotes, and get back on track. But this is much easier to goof up.
What if you do want to make a pull request? This means you should have done *fork-and-clone* instead of *clone*. If you've made no changes or they're easy to save somewhere temporarily, just start over with a fork-and-clone workflow (see below) and re-introduce your changes. It is also possible to preserve your work in a local branch, fork the primary repo, re-configure your remotes, re-sync up with the primary repo, and get back on track. But this is much easier to goof up.

## Fork (of theirs)

This is an ideal setup for making a pull request and generally following the development of a primary repo owned by someone else.
This is an ideal setup if you want to make a pull request and generally follow the development of a primary repo owned by someone else.

```{r fork-them, echo = FALSE, out.width = "60%"}
knitr::include_graphics("img/fork-them.png")
```

This shows a successful "fork-and-clone". Your local repo can pull changes from the primary repo, which is configured as `upstream`, which you cannot push to. You can push to your fork, which is configured as `origin`, and from there you can make a pull request back to the primary repo.
This shows a successful "fork-and-clone". Your local repo can pull changes from the primary repo, which is configured as `upstream`, which you cannot push to (but you can pull from). You have a fork of the primary repo (a very special copy, on GitHub) and it is configured as `origin`. You can push to and pull from your fork. You can make a pull request back to the primary repo via your fork.

How do we get here?

Expand Down Expand Up @@ -120,4 +120,4 @@ If you only plan to make one pull request, this setup is fine. When the exchange

You can add the primary repo as `upstream` in the shell or with `usethis::use_git_remote()`. Next time you do fork-and-clone, consider using `usethis::create_from_github(fork = TRUE)` instead. In addition to configuring the necessary remotes, `create_from_github()` implements other config that is favorable for making pull requests.

Even if `upstream` is not (yet) configured, usethis still describes this setup as "fork".
Even though `upstream` is not (yet) configured, usethis still describes this setup as "fork".

0 comments on commit 374cff0

Please sign in to comment.