-
Notifications
You must be signed in to change notification settings - Fork 18
/
presentation.qmd
188 lines (115 loc) · 4.6 KB
/
presentation.qmd
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
---
title: "UDOT GitHub Training"
author: "Greg Macfarlane"
format:
revealjs:
logo: images/byu_cce.png
self-contained: true
---
## Outcomes
1. Understand and describe the purpose of version control in transportation analysis projects.
2. Create a git repository and commit changes to text files using the command line as well as third-party graphical git clients.
3. Use GitHub to collaborate with others on a shared project.
## Setup
:::: {.columns}
::: {.column width="50%"}
### Needed
![Git](images/Git-Logo-2Color.png){height=150}
![GitHub / GitHub Desktop](images/GitHub_Logo.png){height=150}
:::
::: {.column width="50%"}
### Not needed, but I am going to use
![Visual Studio Code](images/vscode.png){height=200}
:::
::::
# Why we use Git
## Problem 1
How many of you have ended up here?
```sh
mydocument.docx
mydocument_final.docx
mydocument_final_commentsGSM.docx
mydocument_final_commentsSHA.docx
mydocument_really_final.docx
mydocument_really_final_gsmedit again.docx
```
Google docs has made this better, but still not perfect.
## Solution: Version Tracking
![](images/git-commits.png)
## Problem 2
Chris is working on new code for transit network skimming. Hayden is working on a new external zone design. Neither can wait for the other to be done, but they may need to edit similar files in the travel demand model.
1. Flip coins to see who will go first. Surely the other person can work on something else?
2. Create a check-out system that prevents two people from editing the code at the same time.
## Solution part 1: Working copies
![Image from Atlassian](images/working_copies.svg)
Multiple developers can have their own local working copies of a repository.
## Solution part 2: Branching
Different developers can work on their own branches (commit path). Then, two branches can be merged.
![Image from Atlassian](images/basic_branch.png)
## Problem 3
You have started building the next version of your travel model when you get a report of a bug that needs to be fixed immediately. You have already made lots of changes to the part of the code where the bug is.
1. Throw away the work you are doing on the next version so that you can fix the bug as soon as possible.
2. Fix the bug alongside everything else, and give your users a fix in the next version. Whenever that is.
## Solution: Branch-based workflow
Formalize how updates are made, based on branches.
!["Git Flow" development pattern. Image Atlassian](images/git-flow.svg)
## Review
1. What problem does version control solve?
1. Is there a project you have worked on that would benefit from version control?
# Tutorial Part 1: Working with Git on Your Own
<!-- The first tutorial has them create a new repository on the command line, add a README file to it, and then push to gitHub.-->
## Create a repository
Create a new folder, and then start a terminal (git-bash) from inside that folder.
```sh
# make this folder a git repository
git init
```
## Add a text file to the respository
```sh
# start a README file
touch README.md
```
Edit the file using a text editor, save it, and then check to see the changes.
```sh
# check the repository status
git status
```
## Stage and commit your changes
```sh
git add REAME.md
git commit -m "Add initial README file"
git status
```
## Review
You can now keep track of changes to a local file.
1. What is the difference between staging changes and committing changes?
2. How often should you commit changes?
# Tutorial Part 2: Working with others on GitHub
## GitHub uses "Pull Requests"
![Image from GitHub](images/branching.webp)
This helps people collaborate by formalizing discussion related to proposed changes.
## Fork this repository
Go to <https://github.com/gregmacfarlane/udot-gittraining>
Push the "fork" button at the top-right, and fork it to your own account.
![](images/fork_repo.png)
## Clone this repository
1. Open GitHub Desktop
2. Clone your fork to your local computer
## Make an edit
1. Open the file `participants.csv`.
2. Add your name to the list of participants.
3. Save, stage, commit, and push.
## Open a pull request
![](images/pull_request.png)
## Participants in this training
```{r cloud, echo = TRUE}
library(readr)
read_csv("participants.csv", col_types = "c")
```
## Review
1. What is the difference between `commit`, `push`, and `pull`?
2. Is there a project that you want to move into GitHub for collaboration?
## Tutorials for Learning More
Linkedin Learning / DataCamp
Atlassian: <https://www.atlassian.com/git/tutorials>^[Most images came from these tutorials.]
GitHub: <https://docs.github.com/en/get-started/start-your-journey/git-and-github-learning-resources>