Problem 1

How many of you have ended up here?

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

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

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

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

Review

1. What problem does version control solve?
2. Is there a project you have worked on that would benefit from version control?

Create a repository

Create a new folder, and then start a terminal (git-bash) from inside that folder.

# make this folder a git repository
git init

Add a text file to the respository

# start a README file
touch README.md

Edit the file using a text editor, save it, and then check to see the changes.

# check the repository status
git status

Stage and commit your changes

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?

GitHub uses “Pull Requests”

Image from GitHub

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.

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

Participants in this training

library(readr)
read_csv("participants.csv", col_types = "c")

# A tibble: 16 × 1
   Name                      
   <chr>                     
 1 Khaisy Vonarath           
 2 Greg Macfarlane           
 3 BYU Transpo Intern        
 4 Fahmid Hossain (upgraded!)
 5 Natalie Knudson           
 6 Natalia Brown             
 7 Sean Berry                
 8 Ryan Nicol (updated)      
 9 Emily Jacobson            
10 Andrew Wilding            
11 Linn La                   
12 Isaac Gardner!            
13 Dr. Macfarlane (upgraded!)
14 Muna Shah (upgraded!)     
15 Ethan Turner              
16 Hayden Atchley            

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¹

GitHub: https://docs.github.com/en/get-started/start-your-journey/git-and-github-learning-resources