Practical #5

Advanced Statistical Programming using R — Collaborative Coding

Author

Leonhard Kestel, Lisa Bondo Andersen, Cynthia Huang

Published

May 15, 2026

ImportantAnnouncement
  1. All the people who submitted the group match making survey should have received an email with their group assignment. If you did not receive it, please check your spam folder and then contact the instructors!
  2. We kindly ask you for a small round of feedback about the practical exercises (only 3 questions): Moodle Feedback

Quiz

Before starting, work through this QUIZ to check your understanding of the concepts covered in this week’s lecture on debugging and on using LLMs (large language models) in a statistical programming workflow.

General Remarks

This practical has two parts, building on the version-control workflow you set up in Practical #4.

  1. Quarto Websites. You will turn your reflection log into a Quarto website project, learn how to execute and display R code inside .qmd documents, and publish the rendered site to the web.
  • How to initialize a Quarto Website project?
  • How to execute and display R code in Quarto?
  • How to use the Quarto CLI to preview, render, and publish your website?
  1. Collaborative Coding with Git and GitHub. These exercises build on the daily push/pull workflow from Practical #4. You need a GitHub account, SSH keys set up, and a repository on GitHub from Practical #4 to follow along.
  • What do git branches and git stash do and how to use them?
  • Where do merge conflicts come from and how to resolve them?
  • How do pull requests work on GitHub?

A consolidated list of links to relevant Quarto and Git documentation is in the Resources section at the bottom of this page.

Quarto Websites

Exercise 1: Initialize a Quarto Website project for your Reflection Log

So far your reflection log has been a single .qmd file. In this exercise you turn it into a Quarto website project — one folder with shared navigation, multiple pages, and a single command to render or preview the whole thing.

TipQuarto tutorial

Work alongside the official walkthrough: Creating a Website — Quarto Documentation. The “Quick Start” section mirrors steps 1.1 and 1.2 below.

1.1 Create the project skeleton

From inside the folder where you want the website to live (e.g. your statprog-debugging repo from Practical #4, or a fresh folder), use the quarto create CLI command to scaffold a website project called reflection-log. It should create a folder containing _quarto.yml, index.qmd, about.qmd, and styles.css.

quarto create project website reflection-log

Or in RStudio: File → New Project → New Directory → Quarto Website.

1.2 Inspect the generated files

Open _quarto.yml and locate the three sections that drive a Quarto website:

  • project: — declares the project type (website) and where rendered output goes
  • website: — title, navbar, sidebar, search, footer
  • format: — output format defaults shared across every page

Then open index.qmd and about.qmd and compare their YAML headers to a standalone .qmd.

1.3 Move your reflection log into the project

Copy your existing reflection log .qmd (and any past weekly entries) into the new project folder. You can either keep one combined file with sections per week, or split it into one file per week (e.g. week01.qmd, week02.qmd, …) — your call.

1.4 Configure the navbar

Edit _quarto.yml so the site has a sensible title and the navbar lists each page. See Website Navigation — Quarto Documentation for the full set of options.

A minimal _quarto.yml for a per-week structure:

website:
  title: "My Reflection Log"
  navbar:
    left:
      - href: index.qmd
        text: Home
      - href: week01.qmd
        text: Week 1
      - href: week02.qmd
        text: Week 2

1.5 Preview the site

Start a live preview in the terminal — your browser should open with the rendered site, and edits to any .qmd reload automatically. Leave this running while you work on the next exercises.

quarto preview

Exercise 2: Executing and displaying R code in Quarto

Quarto code chunks let you mix narrative, code, and output in one document. In this exercise you add R chunks and use chunk options to control what is shown.

TipQuarto tutorials

Reference pages for this exercise:

2.1 Add a code chunk

Edit one of your reflection log pages and add an R chunk that loads the palmerpenguins package and previews the first few rows of the penguins dataset. Save — the preview should reload and show both the code and the resulting table.

```{r}
#| label: penguins-glimpse
library(palmerpenguins)
head(penguins)
```

2.2 Control what is shown with chunk options

Chunk options sit on #| lines at the top of each chunk. Try each of the following on the chunk from 2.1 and observe the effect on the rendered output:

  • echo: false — hide the source, show only the output
  • eval: false — show the source, don’t run it
  • include: false — run the code (useful for setup) without showing source or output
  • warning: false / message: false — silence warnings or messages from packages

2.3 Add a labelled plot

Add a second chunk that produces a scatter plot of bill_length_mm against bill_depth_mm (coloured by species). Give it the label fig-penguins and a caption, then reference it in your prose with @fig-penguins — Quarto numbers it automatically.

```{r}
#| label: fig-penguins
#| fig-cap: "Bill length vs. depth across penguin species."
library(ggplot2)
ggplot(penguins, aes(bill_length_mm, bill_depth_mm, colour = species)) +
  geom_point()
```

2.4 Set project-wide code display options

Open _quarto.yml and add display defaults under format: html: so that every page on the site folds its code chunks into a “Show code” toggle, numbers lines, and offers a copy-on-hover button. The full list of options is in HTML Code Blocks.

format:
  html:
    code-fold: true
    code-summary: "Show code"
    code-line-numbers: true
    code-copy: hover

Exercise 3: Use the Quarto CLI to preview, render, and publish your website

Collaborative Coding with Git and GitHub

These exercises assume you have completed Practical #4: a GitHub account, SSH keys set up on your machine, and a local repository (e.g. statprog-debugging) already pushed to GitHub.

Exercise 4: Branches and stash

Branches let you work on a change without affecting the main history until you are ready. git stash is a quick way to put unfinished work aside without committing it.

4.1 Create a branch

  1. Create and switch to a new branch called improve-exercise1.

    git switch -c improve-exercise1

  2. Make a small but visible change to your .qmd — for example, add a comment explaining the NSE bug in your own words. Stage and commit it.

    git add .
git commit -m "add explanation of NSE bug"

  3. Switch back to main — your change should disappear from the working directory. Then switch back to improve-exercise1 and watch it reappear. This is the point of branches.

    git switch main
git switch improve-exercise1

  4. Push the branch to GitHub so it is visible to others.

    git push -u origin improve-exercise1

4.2 Stash an unfinished change

Sometimes you need to switch context before a change is ready to commit.

  1. Make a small edit to a file — but do not commit it.

  2. Stash the change, then confirm with git status that the working directory is clean.

    git stash
git status

  3. Retrieve your stashed change.

    git stash pop

git stash is handy for very short interruptions. For anything longer, a WIP commit (git commit -m "wip") is safer: it shows up in git log and is harder to lose. You can always amend or squash it before you push.

Exercise 5: Merge conflicts

When two different locations change the same line of the same file independently, Git cannot decide which version to keep. This is a merge conflict. It sounds alarming but is a normal part of collaborative work — this exercise creates one in a controlled setting so it is not a surprise later.

The scenario: you make a change on GitHub via the web interface while your local copy is still at the old version. When you try to push, Git rejects it. After a git pull, you will see the conflict markers.

5.1 Make a local change without pushing

Make sure you are on main, then edit the first line of your .qmd — for example, change the title slightly. Stage and commit, but do not push yet.

git switch main
git add .
git commit -m "change title locally"

5.2 Make a conflicting change on GitHub

  1. Go to your repository on GitHub.
  2. Click on your .qmd file to open it.
  3. Click the pencil icon (Edit this file) in the top right.
  4. Change the same first line — use different wording than your local version.
  5. Scroll down and click Commit changes (the default message is fine).

Your local repo and GitHub now have different histories from the same starting point.

5.3 Try to push — and fail

Push the local commit. What happens?

git push

Git will reject it because the remote has commits your local repo does not have — you should see a message like ! [rejected] main -> main (fetch first).

5.4 Pull and see the conflict

Pull the remote changes. Git will try to merge them into your local history and stop when it hits the conflicting line. Open the file — you should see conflict markers like:

<<<<<<< HEAD
This is your local version.
=======
This is the GitHub version.
>>>>>>> abc1234

5.5 Resolve the conflict

Edit the file to keep the version you want (or combine both). Remove all three marker lines (<<<<<<<, =======, >>>>>>>) completely. Save, then stage, commit, and push the resolved file.

NoteOptional: RStudio UI

In the Git pane, the conflicted file is marked with a U (unmerged). Click it to open in the editor, which highlights the two versions in colour.

git add .
git commit -m "resolve merge conflict: keep local title wording"
git push

Everything between <<<<<<< HEAD and ======= is what your current local branch has. Everything between ======= and >>>>>>> <hash> is what came in from the remote. Your job is to decide what the file should look like, remove all three marker lines, and save.

TipPrevention is better than cure!

The best prevention is to pull before you start working and to push at the end of each session. The longer you wait to push, the more likely a conflict becomes.

Exercise 6: Pull requests

A pull request proposes changes to a repository on GitHub. Instead of editing someone’s code directly, you make your changes on a copy (a fork), then open a pull request to ask them to review and merge your changes.

Work with the person sitting next to you.

6.1 Exchange repository URLs

Share the GitHub URL of your statprog repository with your neighbour.

6.2 Fork and clone your neighbour’s repository

  1. Go to your neighbour’s repository on GitHub.

  2. Click Fork in the top right. This creates a full copy under your own account.

  3. On your fork, copy the SSH URL (green Code button → SSH).

  4. Navigate to a folder outside your existing project and clone your fork into a new directory (e.g. neighbour-debug).

    cd ..
git clone git@github.com:YOUR-USERNAME/statprog-debugging.git neighbour-debug
cd neighbour-debug
TipFork vs clone

A clone is a local copy on your computer. A fork is a copy of a repository on GitHub, under your own account. When you fork and then clone, you end up with: original repo → your fork on GitHub → your local clone. Changes you push go to your fork until you open a pull request.

6.3 Make a change on a branch

  1. Create and switch to a new branch.

    git switch -c <name-of-your-branch>

  2. Make a small improvement to your neighbour’s repository.

  3. Stage, commit, and push the branch to your fork (use -u so future pushes don’t need the upstream).

    git add .
git commit -m "fix typo in exercise 2 solution comment"
git push -u origin <name-of-your-branch>

6.4 Open a pull request

  1. Go to your fork on GitHub. Click the Compare & pull request banner (or go to Pull requests → New pull request).
  2. Check that the base repository is your neighbour’s repo and the base branch is main.
  3. Write a short description: what did you change and why?
  4. Click Create pull request.

6.5 Review and merge your neighbour’s pull request

  1. Go to your own statprog repository → Pull requests tab.

  2. Open the pull request. Check the Files changed tab.

  3. Leave at least one comment on a specific line (hover to reveal the blue +).

  4. Click Merge pull request → Confirm merge.

  5. Pull the merged change into your local main.

    git switch main
git pull

For a small change, check: does the change do what the description says? Is the commit message informative? You can also check out the branch locally to test it:

git fetch origin <branch-name>
git switch <branch-name>

Switch back when done: git switch main.

6.6 Reflect

Discuss briefly with your neighbour:

  • What would have happened if you had both edited the same line of the same file?
  • When would you use a branch on your own solo project?

Reflection Log

  1. Take a few minutes to write this week’s reflection log.
  2. Commit and push.
TipWhat to write about

Some prompts: What was the most confusing part of the pull-request cycle? When do you think you will use branches in your own projects? Did you get a merge conflict — what caused it and how did you resolve it?

Resources

Quarto Websites & Code

Git & GitHub