Session 4: Version Control with Git and GitHub
Monday, 19 October 2026, 09:00–11:15 · Room MAD 099
Two things, and neither can be done quickly in the room with thirty other people:
- Install Git and connect RStudio to your GitHub account — follow Git and GitHub with RStudio (Gräbner-Radkowitsch 2026)
- Install the
usethispackage:install.packages("usethis")
Allow half an hour. If it goes wrong, post in the Moodle forum before Monday — that is much better than arriving stuck.
What this session is about
You have written a report that rebuilds itself from its source. You zipped it and sent it to me, and that worked — once, from one machine, in one version.
Now consider the evening it goes wrong. Your document rendered on Thursday. On Sunday you tidied a chunk, and at 23:10 it errors. Without a record of what you changed, you reread everything. With one, you read four changed lines and find the bug in six seconds.
That record is what today is about. It is also how you hand in from now on: Report 2 is not a file, it is a repository.
One new one:
install.packages("usethis")gitcreds, which you also use, arrives with it automatically. Plus tidyverse, flextable and here from the earlier sessions.
Git is usually taught by typing commands into a terminal. We do not do that. A few lines in the R console set your machine up once; after that everything is buttons in RStudio’s Git tab.
Learning goals
- Say what a commit, a repository and a remote are, in your own words
- Name the four places your work can be — working files, the staging area, your history and the remote — and what HEAD and
originrefer to - Turn an existing RStudio project into a GitHub repository in your own account — once, in three lines
- Do the everyday loop by clicking: Pull → Stage → Commit → Push
- Read a diff, and explain why that is the single most useful window in RStudio
- Write a commit message somebody can use in six weeks — including you
- Decide what belongs in a repository and what does not, and write a
.gitignorebefore the first commit - Get an earlier version of a file back, and know which of the two ways applies
- Say why you pull before you push, even working alone
- Write a
README.mdthat lets a stranger reproduce your work
Slides
Open the slides in a separate tab
Open the slides in a separate tab in Chrome, add ?print-pdf to the end of the address, then print to PDF.
Materials
| File | Description |
|---|---|
| Exercise sheet | The in-session exercise |
| Classroom 50 exercise | The practice assignment — if you finish early, otherwise take-home |
| Classroom 50 manual | How you hand in Reports 2 and 3 — keep it |
| Setup tutorial | Installing Git and connecting RStudio — before the session |
| Slides | The deck from the session |
| Live coding document | The narrated code we wrote together |
| Exemplary solution | Worked answers to the exercise |
Data
None, and deliberately so. Today you work on your own Report 1 project — the one you submitted last week, with the data already in it.
That is the point of the session rather than a shortcut: the thing you put on GitHub today is a real piece of your own work, and the workflow you practise is exactly the one Report 2 is submitted through.
Use your session 3 exercise project instead. Everything in the exercise works identically, and nothing about today depends on which dataset is in the folder.
New this session: a few usethis lines
Everything today is clicking, apart from a short one-off setup. These are the only Git commands you type in this course:
# once per laptop — who you are, and proof that you are you
usethis::use_git_config(user.name = "...", user.email = "...")
usethis::create_github_token()
gitcreds::gitcreds_set()
# once per project — in this order
usethis::use_git_ignore(c("*.html", "*_files/"))
usethis::use_git()
usethis::use_github(private = TRUE)The first three belong in the setup tutorial and should already be done. The last three are the session. private = TRUE keeps your Report 1 repository visible to you alone: other students may still be revising theirs.
use_git() makes your first commit, and your Report 1 folder already contains a rendered .html. Ignoring a file does not remove it from a history it is already in — so the ignore rules have to be written before the history exists.
This is the one thing in the session that is genuinely hard to undo afterwards.
create_github_token() shows it once and never again. Never put it in a .qmd, never commit it, and if it ever reaches GitHub, treat it as compromised and make a new one. gitcreds_set() exists so it lives in your keychain instead of in a file.
The question we answer
Not about hotels this week:
How do you keep work so that you can see what you changed, get an earlier version back, and hand the whole thing to somebody else as a link?
Two things, and the second is the one that sticks.
The first is that Git is much less about disaster recovery than the name “version control” suggests. You will use the Diff window ten times for every one time you restore something.
The second is that a repository is a stricter test of your session 3 work than a zip file ever was. A zip carries whatever happened to be in the folder. A repository carries what you decided to put in it — and if you decided wrong, it will not render on anybody else’s machine. Optional task (c) makes you find out which you did, in two minutes, by cloning your own work and rendering it as a stranger would.
What we are not doing
Branches · pull requests · merge conflicts as a practice · the command line.
All four are real, and they are how professional teams work. None of the three reports in this course needs any of them, so none is taught and none is examined.
There is a full worked walkthrough of branches and pull requests at the end of the exemplary solution, published after the session, for whoever wants it.
Take-home until session 5
Work through the Classroom 50 exercise, with the manual open next to it: join the course organisation, accept the practice assignment, clone the repository it gives you, make three commits and push them. About twenty minutes, and nothing is marked, but please finish by Sunday 25 October, 23:59. The link is on the exercise sheet.
It exists so that a problem with your account or your token surfaces now, with three weeks of slack, rather than on the evening Report 2 is due. Please actually do it this week, and tell me if anything did not work.
Register at github.com and send me your GitHub username as a Moodle message. The first box in the Classroom 50 exercise has the details.
Session 5 is the grammar of graphics — the first thing in this course you have genuinely never done, and two full sessions are given to it.
Going further
- Bryan and Hester (2024) — the standard reference for Git with R and RStudio, no command line assumed. Ch. 20 for the vocabulary, ch. 28 for push rejection.
- Wickham et al. (2023), ch. 6 “Workflow: scripts and projects” — the project discipline this session builds on
- The
usethissetup article — what these lines actually do
A repository you hand in should:
- live in the right place: your own GitHub account for today’s, the course organisation for Reports 2 and 3 — Classroom 50 creates those for you
- contain the
.qmd, thedata/, the.Rprojand aREADME.md - contain no rendered
.htmland no_files/folder - have a history of small commits with messages that say what changed
- show an empty Git tab — nothing uncommitted, nothing unpushed
- render from a fresh clone, after a restart of R, on a machine that is not yours