forked from RVerse-Tutorials/RWorkflow-NWFSC-2021
-
Notifications
You must be signed in to change notification settings - Fork 0
/
week3.Rmd
136 lines (82 loc) · 6.76 KB
/
week3.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
---
title: "Week 3"
output:
html_document:
toc: true
toc_depth: 3
include:
after_body: footer.html
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```
## Key Git/GitHub Skills
* [The lecture notes](week3-github.html)
* [Lecture video](https://youtu.be/pdaOa4t6-Wc)
## Session questions and comments
### Migrating repos
**I would like to organize my repositories into organizations. How do I move my repos to my new organization.**
There is a migrate button. GitHub does all the work for you.
* Open the repo you want to migrate.
* Go to Settings (cog on right).
* Scroll all the way down to 'Transfer ownership'. Click on Transfer.
* Look for an email in the email address for the organization. You'll need to accept the transfer. Note, you can use the same email for all your organizations. It's really just like repo folders.
* Once the transfer is done, go into Settings for the repo and adjust the membership access as needed. You can add individuals (using their GitHub address) or add teams.
### Issues vs discussions
**What is the difference between issues and discussions**
Discussions happen within an organization and are not specific to a repository. Issues are specific to a particular repository and have features like assigning tasks to specific people and assigning labels.
### Find my issues
**My team is using issues across a variety of organizations and repositories. How do I find all the issues assigned to me.**
* Log into GitHub
* Go to https://github.com/issues/assigned and you'll see all the issues assigned to you.
### GitHub Pages
**How do you decide whether to use a GitHub Pages landing page?**
Anything that is for someone other than me has a landing page. This gives someone a readable entry to the repository with instructions for how to use the repository. I always put a link to the landing page in the repo description. Then it appears on the right side of my repo files and is easy to find.
**Examples of simple pages**
Here are some videos showing how to make a few different simple landing pages from your Readme file or from an RMarkdown file in a docs folder.
* [Super simple](https://youtu.be/HIAvNi-4TkU) - just your `Readme.md` file
* [Use a theme](https://youtu.be/gNVcAnds-Ys) - still just your `Readme.md` file but with a GitHub generated "skin". My [MARSS](https://nwfsc-timeseries.github.io/MARSS/) landing page is generated like this.
* [User an RMarkdown file](https://youtu.be/fA5BeCaX1eo) - from `index.Rmd` in a `docs` folder. This allows you to combine text and figures generated from R. Here is a real example from one of my colleagues [ASSESSOR](https://mdscheuerell.github.io/ASSESSOR/). It was generated from a single `index.Rmd` file just like in the video.
Now that you see how landing pages are often generated, if you see a landing page that you like, go to their `Readme.md` file and see how they wrote it or look for a `docs` folder and their `index.Rmd` file.
**Do you use a landing page for a personal-only repo?**
If the repo is just for myself, then I will often only have a Readme file. I write this for my 'future' self to help me quickly get back into the project at a later date. What I have here is really project dependent. Some things I usually have in the Readme for personal repos are
* If it is an R package, the code to install. I just want to copy and paste this. Saves me time later.
* Basic organization of the repo if it is anything unique or bespoke.
* Where I am at in the project and what the status was when I stopped.
### RStudio and Git
**I want to link RStudio to Git, but I am getting an error that RStudio cannot find Git**
Open RStudio. Go to Tools > Global Options... > Git/SVN . The paste in the location of the git.exe file.
On a Mac? location is `usr/bin/git`
Finding that location if you are on a PC can be onerous. First make sure you can see hidden folders. In a finder window, you click View and make sure the hidden files checkbox is checked. Then here are some ideas of where to find `git.exe`. Note you might not see `.exe` . You might only see `git`. It depends if you have `show file endings` selected in preferences.
If you only installed GitHub Desktop, look here
```
C:\Users\UserName\AppData\Local\GitHubDesktop\app-2.8.3\resources\app\git\cmd\git.exe
```
You have to change app-x.x.x to whatever version you have.
If you installed Git for Windows, look in these places.
```
C:/Program Files/Git/bin/git.exe
```
If you installed Git for Windows locally, look here
```
C:\Users\UserName\AppData\Local\Programs\Git\bin\git.exe
```
### File in use
**Can I see when someone is working on a file?**
No. You can see when they commit a change and push the file up to GitHub. Click the history link (circled in red belew) on GitHub to see what's been happening.
### Preventing conflicts
**How I prevent two people from working on a file at the same time?**
In my experience, this is actually less of a problem than you might imagine in small teams. Generally we are dividing up our tasks and work on different parts of a repository. For example, someone is working on data and another on functions to make plots with data and another on prose. Also you can work on the same file as long as you are working on different parts of the file. So if I add documentation to the top and you change code lower down, those changes are not in conflict.
Before embarking on the full-scale solution to this which is using forks (or branches) and pull-requests, I'd try just using old fashioned team communication if your team is small. So message (or email) your 1-3 collaborators when doing something that will conflict. "Hey all, I'm doing that repo reorganization that we talked about. I'll let you know when I'm done. If you can stay out of the repo until then, that'd be great."
If that doesn't work or you'd rather review changes before that are committed to the repository, then use a forking and pull-request workflow (below). I'd steer clear of branches unless you know that's what you want to do. Forks don't have the branch dangers that I've talked about in lecture.
## Forking workflow
[Video showing this workflow](https://youtu.be/q3L6Z0zvo_4)
Let's say Org A is where you have a repo that you are working on.
* Fork that to your personal GitHub account. This created a copy of the repo that is linked to the Org A repo.
* Pull the forked repo into your computer.
* Work on the fork, and when you are ready submit a Pull Request (click the button with that name). It is fairly self-explanatory once you click on Pull Request.
* Then over in the Org A repo, you'll see a Pull Request. They owner will also get an email. You can review and merge (if you want).
* Keep your fork up to date with Org A repo using the Fetch Upstream link
