forked from QuinnAsena/GitHub_basics
-
Notifications
You must be signed in to change notification settings - Fork 0
/
git_slides.Rmd
294 lines (145 loc) · 6.42 KB
/
git_slides.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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
---
title: "Git good"
subtitle: "༼ʘ̚ل͜ʘ̚༽"
author: ""
institute: ""
date: ""
output:
xaringan::moon_reader:
lib_dir: libs
nature:
highlightStyle: github
highlightLines: true
countIncrementalSlides: false
---
```{r xaringanExtra, include = FALSE}
xaringanExtra::use_xaringan_extra(c("broadcast", "webcam"))
```
# Links - \ (•◡•) /
- [Cheatsheet and commandline info](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
- [Happy git with R](https://happygitwithr.com/big-picture.html#why-git)
- [Excuse me, do you have a moment to talk about version control?](https://peerj.com/preprints/3159v2/)
- [Software carpentry (commandline Git)](https://swcarpentry.github.io/git-novice/)
- [link to slides](https://quinnasena.github.io/GitHub_basics/git_slides.html#1)
Today's objective is to cover the minimum requirements to use Git for code reviews.
---
# Overview - (◕‿◕✿)
.pull-left[
- Git is a version control system for items like source code.
- Git is not for data storage although GitHub does have an option for large file storage (Git LFS).
- **Git** and **GitHub** are different things. Git is the version control system, GitHub is a cloud storage.
- There are alternatives to Git and GitHub. Git is commonly used.
- If all you want is a personal back-up system Git is not essential
]
.pull-right[
```{r, echo=FALSE, fig.align='center'}
knitr::include_graphics("versions_cartoon.png")
```
]
---
# Git language - :o)
**Git language** [see cheatsheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet)
Git has its own 'verbs' for everything! Gets confusing so we will cover a few of the most important ones.
.pull-left[
**Git verbs for today**
- init (initialise)
- add
- commit
- push
- pull
- clone
- merge
]
.pull-right[
**Other Git things**
- Repository
- Staging area
- Local storage
- Remote host
]
???
Everything you need to do in Git has the form *verb* -> *argument*
Commandline Git is useful to know at some point but for personal use I like the GUI.
---
# Git workflow - ﴾͡๏̯͡๏﴿
- Local copy (stored on your personal machine)
- Remote copy (stored in the cloud)
- Remote copies can be private, public or shared with specific collaborators
```{r, echo=FALSE, fig.align='center', out.width="50%", out.height=="50%"}
knitr::include_graphics("local_remote.PNG")
```
???
The idea is that git version control always moves forward. Even if you revert change it still exists.
---
# Git workflow - ﴾͡๏̯͡๏﴿
- Everything in Git can be done in the commandline.
- Use whatever method is most effective for your workflow, today we will use a GUI.
- A lot of Git things can be done either from your local machine or the remote repo, even some editing.
???
Commandline may be necessary for some work like with NeSI but 'there are no merit badges for being a git nerd'... actually there are...
---
# Git workflow - ﴾͡๏̯͡๏﴿
- **initialise** a local repository ('repo'). A repo is a working directory containing the files you wish to version control (e.g., a thesis, paper or analysis code).
- **add** a snapshot of the repo to a 'staging area': Tell git which changes to the repo you want to commit.
- **commit** files from the staging area. Takes a snapshot of the tracked files and stores them as a version.
- Each commit has a unique identifier. You can revert to a previous version of your project by using the identifier.
- Each commit requires a commit message to write to your future self what you changed and why.
- **push** changes to a server such as GitHub (there are others). Upload files to a remote repo.
???
A repository is initialised once. Add, commit and push are done every time you back up your local copy to the remote server.
Git does not autobackup every x minutes. Can set up a cron job if you really want.
---
# Initialise - (ง'̀-'́)ง
1. Make a new directory somewhere on your computer.
2. Initialise a repo in that directory with a README.md and a .gitignore (in GitDesktop this steps 1 and 2 can be done at the same time).
- a .gitignore file is a text file containing a list of items you *do not* want to keep track of or store (e.g., plot images generated from the source code).
- Markdown files render in html so the README is viewed as a formatted document on a browser. I suggest using the README to outline the purpose of your code and detail problems.
3. Publish the repo to GitHub.
---
# add/commit and push - (ᵔᴥᵔ)
1. Make some changes to your README.md.
2. Add and commit the changes.
4. Push the changes to GitHub.
???
I recommend we use the README to outline the purpose of the code to review.
---
# Pull - (ง°ل͜°)ง
1. Edit your README.md on GitHub.
2. Pull changes to your local machine.
---
# Branching - ≧☉_☉≦
- So far we have been working on the master branch of your project.
- Branches allow you to make changes in parallel to your master branch without editing your primary working branch. Changes can be reviewed and merged to your master branch with a 'pull request'
---
# Branching - ಠ~ಠ
1. Create a branch in your Git GUI and navigate to that branch.
2. Edit your README.md and commit the changes to your new branch.
3. Create a 'pull request' to merge the changes with your master branch.
---
# Collaboration - ಠ╭╮ಠ
0. Pair up with someone.
1. GitHub go: settings -> manage access -> invite collaborator. Add each other as collaborators to your projects.
2. Clone their repository.
- 'Clone' makes a copy of a remote repo on your local machine.
3. Make a new branch in their repo.
4. Make changes to their README.md, commit the changes to the branch and submit a pull request for them to review.
5. Review the changes they have made on your README.md and merge them with your master branch.
---
# Collaboration - ಠ╭╮ಠ
For the code review:
.pull-left[
For the **submitter**
1. Initialise a repo.
2. Create a branch for bug fixes.
3. Once changes have submitted to the branch, review them and **merge** with your master branch.
]
.pull-right[
For the **reviewers**
1. clone the repo.
2. do your thing.
3. submit changes **to the branch**.
]
---
# ̿̿ ̿̿ ̿̿ ̿'̿'\̵͇̿̿\з= ( ▀ ͜͞ʖ▀) =ε/̵͇̿̿/’̿’̿ ̿ ̿̿ ̿̿ ̿̿
- Git can do much much more, and also gets a lot more complicated....
- Git version control can all be done on the command line which is necessary when communing with NeSI.