usethis::git_sitrep()Exercise: your Report 1, on GitHub
Session 4 — Applied Data Science 2026
Report 2 is not submitted as a file. It is submitted as a repository — and the first time you do that should not be the night it is due.
So today you do it with the report you have already written, in a room with somebody to ask.
Alone or in pairs.
Your task: by the end of this session, your Report 1 project exists on GitHub, in your own account, with a
.gitignore, a README, and at least three commits with sensible messages.
Open your Report 1 project — the .Rproj, not the .qmd.
If you do not have a finished Report 1, use your session 3 exercise project instead. Everything below works identically.
1 Check your setup
Run this in the console:
You are looking for three things in the output: your Name, your Email, and
• Personal access token for "https://github.com": <discovered>
Run whichever applies, then check again:
usethis::use_git_config(
user.name = "Your Real Name",
user.email = "your.name@stud.uni-flensburg.de")
usethis::create_github_token() # then copy the ghp_... string
gitcreds::gitcreds_set() # then paste itFull instructions are in the setup tutorial. If it still fails, put your hand up rather than spending ten minutes on it.
git_sitrep() prints your token’s permissions and the email addresses GitHub has for you. Fine on your own screen, not on a shared one.
2 Decide what stays out — before anything else
Look at your project folder. List, on paper or in a comment, every file and folder in it, and mark each one in or out.
Then write the ignore rules:
usethis::use_git_ignore(c("*.html", "*_files/"))Your Report 1 folder already contains a rendered .html and a _files/ folder. Once a file is committed, adding it to .gitignore will not remove it — so this has to happen before there is any history at all.
Can code recreate this file? If yes, it stays out. If no, it goes in.
Your .qmd — no, you wrote it. Your data/ — no, it came from outside. Your .Rproj — no, it defines the project. The HTML — yes, render it again.
3 Start the history and put it on GitHub
usethis::use_git()Say yes to committing, and yes to restarting RStudio.
Before you click yes on the commit, read the list of files it shows you. Your .qmd, your data/, your .Rproj and .gitignore should be on it. Your .html should not. If it is, stop and fix task 2 first.
Then:
usethis::use_github(private = TRUE)Your browser opens on the new repository. Check that data/ is there and that the HTML is not.
You did not restart, or you have the .qmd open rather than the project. Close everything, open the .Rproj, look again at the top-right pane.
use_github() fails with an authentication error
Your token is the problem, not your project. Run gitcreds::gitcreds_set() again with a fresh token from usethis::create_github_token(), then rerun use_github() — the work you have already done is not lost.
4 Do the loop three times
Make three separate, small changes to your report, and commit each one on its own with its own message. Push after the third.
Suggestions, if you do not have changes of your own to make:
- Add a sentence to the limitations section
- Change one number in a
filter()and see the result move - Fix a heading, or add one
For each one: read the Diff before you commit it.
Not one commit called changes. Each message must be able to finish the sentence “if you apply this commit, it will …”.
5 Add a README
Create a new text file in the project root called README.md. Four things, six lines is plenty:
- What this project is
- What the data is and where it came from
- How to reproduce it
- Who wrote it
Commit it and push. Then look at your repository page in the browser — the README is now the first thing on it.
6 Break something, and get it back
Do this twice, because the answer is different each time.
First, with no checkpoint:
- Delete a whole chunk from your
.qmd. Save. Do not commit. - Look at the Git tab, open the Diff, and read what you just destroyed.
- Click Revert.
Confirm the chunk is back.
Now with a checkpoint. This is the habit worth leaving with:
- Add a sentence you want to keep. Save, and stage it — tick the box, but do not commit.
- Now break the document: delete a chunk, or mangle a
filter(). Save. - Revert.
Look carefully at what you get back and write down what you observe: did Revert undo only step 5, or did it also undo the sentence you staged in step 4?
There is a reasonable argument for either answer, and what RStudio’s button does here is worth knowing rather than guessing. We collect the answers in the debrief.
Either way the practical rule is the same, and it is the point of the task: commit whenever a piece of work is finished, and you never have to wonder how far back Revert will take you.
It throws away the changes it is showing you, with no undo of its own. That is what makes it useful and what makes it worth reading the diff first. Do this on a change you actually want to discard.
7 The check
Open your repository page in the browser, in a fresh tab, and confirm all seven:
8 If you finish early
Your repository is private, so swap laptops with a neighbour instead of URLs. Open their repository page in their browser and answer, from that page alone and without asking them: what is this project, where did the data come from, and how would you reproduce it?
If you cannot answer all three, tell them which one was missing.
On GitHub, click your .qmd, then History. Find the commit where you changed the number in task 4, and open it. Then find the same commit in RStudio’s Git → History window. Same information, two places.
This is the real test, and it is the one Report 2 is marked on.
Clone your repository into a new place: on its GitHub page, green <> Code button → HTTPS → copy the URL. In RStudio: File → New Project… → Version Control → Git, paste the URL, and as the parent folder choose the Desktop (not the folder your project is already in). Create Project.
That is a fresh copy from GitHub — nothing of your working copy is involved. In the new window: restart R, render.
Does it produce your report? If not, something it needs was never committed. Find out what, commit it, and try again. Delete the clone when you are done.
Deliberately break the rule from task 2, so you have seen it happen.
Create a file scratch.R, commit it, push. Now add scratch.R to your .gitignore and commit that. Then edit scratch.R and save.
Does the Git tab still report the change to it? Should it? What does that tell you about what .gitignore actually does?
Then delete scratch.R and commit the deletion, which is the tidy way out.
Simulate the two-machines problem without a second machine, using task (c)’s clone as the “library computer”.
In the clone, change the title of your report, commit, push. Then in your original project — which knows nothing about that — change the last line, commit, and try to push.
What does Git say? Follow its advice. What does the title say afterwards, and why was there no conflict?
Not part of this course, and nothing you hand in needs them. There is a full worked walkthrough at the end of the exemplary solution if you want it.
9 Take-home until session 5
The Classroom 50 exercise — start it now if you have time left, otherwise do it this week. Nothing is marked, and it takes about twenty minutes: join the organisation, accept the link on that sheet, clone the repository it gives you, commit, push. The manual has every click.
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.