Some feedback / suggestions for Daily Workflows part

[jtr13]

I like the direction of the Daily Workflows part, and see room for more advice on what the routines look like when you're doing things right. In that spirit, I'm going to throw out the mental models that I'm employing to make sense of things. If there are any pieces that would be useful for Happy Git, I can flesh out further. As you'll see, it's more or less an attempt to sort out dichotomies such as: my repo vs. someone else's repo, contributor vs. collaborator, branch vs. master, local vs. remote. (All are are easy to grasp in isolation but not always simultaneously). Apologies in advance for mistakes. I hope they will serve as useful information on what people aren't getting, and not cause too much cringing.

In addition, it would be great to have more info -- or a link to another resource -- that explains the importance of a having proper commit history, as that appears to be the main force in determining what's recommended and what's not.

Scenario 1: Using GitHub only

There's lots of stuff you can do, share code and other stuff, look at code and other stuff, download repositories, even make changes to other people's repositories or let them make changes to yours (https://happygitwithr.com/workflows-browsability.html#let-people-correct-you-on-the-internet).

Scenario 2: Using git for your own repo, no one else involved (no branching)

the model: origin/master (Github) <--> local/master

the set up: https://happygitwithr.com/new-github-first.html

the workflow in RStudio: 1. pull, 2. work, 3. save 4. commit, 5. push

Scenario 3: Your repo, other collaborators (= have write access to repo) and/or contributors (random people with no write access)

Collaborators need to discuss who is going to merge pull requests.

the set up: same as above

the workflow in RStudio (similar to before, but now we're going to work on a branch):

1. pull 2. branch 3. work 4. save 4. commit 5. push

next: submit a PR on GitHub, either you or another collaborator reviews and merges it

merging PRs: this is done on GitHub

the easy way: review file changes and click merge without leaving GitHub

the more complex way: review code locally before merging. Some clues here: https://happygitwithr.com/pr-extend.html but I'm lost on how to do this properly (or frankly at all)

If you were the one who submitted the pull request, be sure to delete your local branch after the merge, and pull new changes. The twist: local master is the last to be updated. The new code goes from local/newbranch --> origin/newbranch --> origin/master --> local/master

Scenario 4: Contributing to someone else's repo

Very similar to 3, but we now have to fork and clone someone else's repo to begin (https://happygitwithr.com/fork-and-clone.html)

the workflow in RStudio: same as above 1. pull 2. branch 3. work 4. save 4. commit 5. push

submitting a PR: same as above but the request is from your origin/branch to upstream/master

after the merge, delete the branch and get upstream changes (or in the other order?) (https://happygitwithr.com/upstream-changes.html)

then push them to origin/master

The twist: origin/master is the last to be updated (if at all). Now the new code flows from local/newbranch --> origin/newbranch --> upstream/master --> local/master --> origin/master

[jennybc]

Thanks! I'm not working on Happy Git actively right now, but appreciate this. Don't interpret my silence as lack of interest.