Organize your research and teaching material with Git

Day 2/4: Git + GitHub on RStudio; changing Git history

Waldir Leôncio Netto

Research Software Engineer
Oslo Centre for Biostatistics and Epidemiology (OCBE)

https://github.com/ocbe-uio
https://github.com/wleoncio

Course plan (subject to change)

Class rules (day 2)

Course material

Available here or through QR
Licensed under Creative Commons Attribution-ShareAlike

Workflow

Questions/comment at any time (in-person or chat)
Requirements:

1. Git
2. GitHub account with SSH keys

Day 1 recap

If you only learn one thing in this course

git add $file
git commit -m "$message"

...and seek help if you need to check/retrieve from history.

If you learned more

1. Start a Git repo: git init
2. Register history: git status, git add, git commit, git reset
3. Check/retrieve history: git diff, git log, git show
4. Create parallel worlds: git branch, git checkout, git merge
5. Sweep things under the rug: git stash, git stash pop

Before we continue

Any questions (like the one on Slido I missed)?

I see different versions, Bash, CMD, GUI, what are the different uses?

(Quick Windows Git demo)

Make sure you have SSH keys registered on GitHub

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection

Git and RStudio

1. Create project
2. Configure Git for project (add local repo)
3. Do that thing you do

GitHub and RStudio

1. Create project
2. Configure Git on project (add local and remote repo)
3. Fetch and pull
4. Do that thing you do
5. Push

Your local project on RStudio

1. Start a Git repo: git init
2. Register history: git status, git add, git commit, git reset
3. Check/retrieve history: git diff, git log, git show
4. Create parallel worlds: git branch, git checkout, git merge
5. Sweep things under the rug: git stash, git stash pop

Our online project

Task 1: no conflicts (group exercise)

1. Clone project: git clone or GUI
   • https://github.com/ocbe-uio/git-course-2023
   • Notice the existence of two repos (as far as you can see)
     • git branch
     • git remote
2. Create new file (try to pick a unique name!); add some content
3. Commit and push

Task 2: creating a merge conflict (demo)

4. Fetch and pull from remote
5. Edit a file online
6. Edit the same lines locally
7. Commit and try to push

Real life can be even more complicated

• Push protections

• Merge vs. rebase

But there's hope

• Conflicts are rare on own projects, unusual on collaborations
• Pull Requests prevent damage
• .gitignore for files that shouldn't be pushed by anyone
• Git is pretty smart, won't overwrite things it shouldn't
• GitHub Codespaces for shared live-writing

Should you edit past commits?

Two schools of thought

1. Your Git history should not be changed. It should reflect what actually happened

• Easy to follow
• Hard to read from

2. Your Git should be a curated version of what actually happened

• Not for Git beginners
• Easy to read from

3. You should do both. Don't edit when you're a beginner. Edit when you feel ready.

Rewriting Git history

Amending commits (safe and encouraged)

git commit --amend # change files or just the commit message

Bonus: patch-add commits when things should be split

git add --patch
git commit

Bonus bonus: revert commits easily if you're organized

git revert $bad_idea_hash

Squashes and fix-ups (risky)

Step 0: backup your repository!

git commit --squash $same_idea_hash
git commit --fixup $oopsie_hash
git rebase --interactive $destination # make sure there were no pushes since