Set Up Your Course Project

Lab · Module 2 · Wed Aug 26

Welcome to the Module 2 lab

You read M02 · Introduction to the Tools before today. The Module gave you the conceptual map — what R, RStudio, Quarto, and Git + GitHub each do, how they fit together, and the mechanics of each. Today is the hands-on part. The lab instructor is in the room, your laptop is open, and you’ll get everything from M02 working end to end so you can build on it for the rest of the semester.

Three goals for today:

Confirm your setup works end to end — RStudio talks to R, the course project opens, the lab template renders to clean HTML.
Get hands-on with the lab template — render it, then practice the edit-render workflow by adding a Descriptive Statistics section of your own.
Make your first commit and push to GitHub — turn your project folder into a Git repository, commit today’s work, and publish the repository to your GitHub account as a cloud backup.

If your M02 setup didn’t quite work · flag the lab instructor now

If you tried the M02 install steps and got stuck — RStudio won’t open, an installer hit an error, your laptop turned out to be too old, or you didn’t have time to get to it before today — find the lab instructor before you go any further on this page. We have the hour, the room, and the willingness to get you unstuck.

It’s worth pausing here rather than pushing through — a shaky install will cause friction all semester, and we’d much rather spend 15 minutes now getting you solid. Everything that follows assumes a working R + RStudio setup. If you got partway through (e.g., R installed but RStudio didn’t, or packages didn’t install), bring whatever you have — we’ll pick up from there.

If your setup is working, keep reading.

What you’ll leave with

A confirmed, working R and RStudio setup with the required course packages
A successfully rendered m02_lab.html next to your .qmd source in programs/
A new Descriptive Statistics section you wrote — practice with the edit-render loop you’ll use every week
Your PSY652_project published as a private repository on GitHub — your first cloud backup

Step 1 · Confirm your setup is working

This first step is a quick confidence check. If anything below doesn’t behave, that’s your cue to flag the lab instructor before moving on.

Open the course project

In your file browser, navigate into the PSY652_project/ folder you unzipped after M02. Double-click PSY652_project.Rproj. RStudio should open with the project loaded — confirm that PSY652_project appears as the active project in RStudio’s project indicator (top-right) or in the window title, and that the Files pane (bottom-right) shows entries such as data/, documentation/, output/, programs/, README.md, and PSY652_project.Rproj.

Run the version + library checks

In the Console pane (bottom-left), type each of the following and press Enter:

R.version.string
library(tidyverse)
library(here)
library(skimr)
library(gtsummary)

The first line should print an R version string like "R version 4.5.0 (...)". Each library() call should then return you to the > prompt without complaint. Some packages announce themselves when they load and others are silent, and both are normal. Expect tidyverse to print an “Attaching core tidyverse packages…” block, and here to print a single line like here() starts at /Users/you/Documents/PSY652_project — that one is worth reading, because it confirms here found your project root, which is what makes here("data", ...) paths work. skimr and gtsummary load without comment. What you’re looking for is the absence of a line beginning with Error.

We check all four because your lab notebook uses all four. Testing only tidyverse would let a missing skimr or gtsummary stay hidden until Step 6, when it is harder to sort out.

Checkpoint 1 · Setup is working

You should see:

A clean R version 4.X.Y string in the Console
All four library() calls returning to the > prompt with no line beginning with Error:
PSY652_project/ files visible in the Files pane

If any of these are off, flag the lab instructor — everything after this point builds on a working setup, and now is exactly the right time to sort it out.

WebR vs your RStudio · the playground vs the workshop

Many of this semester’s lab pages let you run R code in a sandbox embedded in the browser (the magical WebR — WebAssembly R). Click Run Code below to try it:

Now run the same line in your RStudio Console on your own computer. The result should match. The browser sandbox is great for quick practice on the course website, but it does not have access to the files in your PSY652_project folder, and it resets every time you refresh the page. Your real analysis work for this course lives in RStudio on your laptop.

The WebR sandbox is a playground; RStudio is your workshop. For the first few labs, the materials will provide much of the code you need to copy and paste from the website into RStudio. As the semester goes on, you’ll write more and more of your own code in RStudio, using the website materials as a reference.

Step 2 · Open the M02 lab notebook

The first few weeks’ labs each have their own prebuilt notebook file in programs/. For today, the file is m02_lab.qmd.

In RStudio’s Files pane (bottom-right):

Click on the programs folder to navigate into it.
Click on m02_lab.qmd to open it in the Source pane (top-left).
Start by putting your name on it. At the top of the file, in the YAML header, replace "Your Name" on the author: line with your actual name. Every notebook you submit this semester carries your name this way — it’s worth doing first, before anything else.

You met every element of this notebook — the YAML header, section headings, the Setup section and its code chunk loading this week’s packages (tidyverse, here, skimr, gtsummary), the Import-Data chunk with read_rds(here("data", "nhanes.Rds")), and the chunk options like #| warning: false — in M02’s Your first Quarto notebook section. If anything looks unfamiliar, jump back to M02 or ask the instructor.

What’s lab_template.qmd, then?

Sitting next to m02_lab.qmd in programs/ is a file called lab_template.qmd — a clean, minimal skeleton of a lab notebook (YAML header, a Setup section with its code chunk, and a couple of standard sections). You don’t edit it in place; in Module 6, you’ll save a copy of it to start the new lab notebook.

Next to it is lab_template_annotated.qmd — the same skeleton, but with a comment explaining every YAML line, chunk option, and section. Open that one whenever you forget how a Quarto notebook is put together; think of it as a cheat sheet you can return to at any point this semester. (The first few weeks’ labs come as pre-built files, m02_lab.qmd through m05_lab.qmd — that is where the actual lab work happens until we get to Part 2 of the course.)

Checkpoint 2 · Notebook is open

In the Source pane (top-left) you should see m02_lab.qmd open — the YAML header at the top, the Setup section and its code chunk with library(tidyverse), the Import-Data chunk, and the section headings you read about in M02.

Step 3 · Run each chunk and watch what happens

Before we render the whole document, let’s run each chunk one at a time. This gives you a feel for the inline workflow you’ll live in for the rest of the semester (M02’s Running code · inline and rendered is the conceptual companion). Two things to watch as you go:

Where the output appears. When you run a chunk, RStudio executes it in your current R session. Depending on your RStudio output setting, the printed result may appear directly below the chunk or over in the Console, Plots, or Viewer pane. Either location is normal — you can switch between them under the gear icon at the top of the Source pane.
The Environment pane (top-right) populating. Each chunk that creates a new object (nhanes <- ..., for example) adds that object to the Environment pane the moment the chunk finishes. By the end of the template, the pane shows everything that’s live in your R session.

Run them in order

Find the green arrow at the top-right corner of each chunk. Click it once per chunk, in order:

The Setup section’s code chunk — loads tidyverse, here, skimr, gtsummary. You may see package-startup messages when it runs. Where they appear — inline, in the Console, or not at all — depends on your chunk-output setting and on options like message: false. What matters is that the chunk finishes without an error and the packages are loaded (M02 covers this in Reading warnings and messages while you work).
The Import-Data chunk — runs nhanes <- read_rds(here("data", "nhanes.Rds")). Nothing prints (assignment is silent), but watch the Environment pane: an entry for nhanes appears, along with a row count and column count. That’s R confirming the dataset is live in memory.
The Glimpse chunk — runs nhanes |> glimpse(). A one-line-per-variable summary appears — below the chunk or in the Console, depending on your setting: row count, column count, then each column with its type tag (<dbl>, <fct>, …) and the first several values.

Checkpoint 3 · Inline runs work

The Environment pane (top-right) now shows nhanes with its row × column count.
The Glimpse chunk’s output appears as a tidy one-line-per-variable summary — below the chunk or in the Console, depending on your RStudio setting.
No message beginning with Error: appears anywhere.

If anything is off — flag the instructor before moving on.

Step 4 · Restart R, then render

You’ve just confirmed the chunks run inline. Now we’ll switch to the rendered-document workflow: render the whole document from a clean slate. The clean-slate step matters — M02’s advanced-box on restarting R explains why. The short version: a rendered HTML is the version someone else will read, and it should reflect only what your code produces from a fresh session — never leftover state from your earlier inline experiments.

Two steps, in order

Restart R. In RStudio’s top menu, click Session, then Restart R (or press Cmd/Ctrl + Shift + F10). The Environment pane empties (no nhanes anymore) and every package unloads. Do it here so you can watch that happen — it makes the next point concrete: the rendered document cannot lean on anything left over from your interactive session. You won’t need to restart manually before every future render, because Render already runs the document in a fresh, separate R session. Reach for a restart when your session feels stale and you want to be sure of what you’re looking at.
Click Render. Find the Render button near the top of the Source pane — the icon is a right-pointing arrow next to the word Render. Click it.

Quarto opens a fresh R session, runs every chunk in order, and writes the rendered HTML as m02_lab.html right next to the .qmd file in your project’s programs/ folder. In this course template, the HTML stays as a single self-contained file because the notebook YAML uses embed-resources: true. RStudio’s preview pane should pop the rendered HTML open automatically — you’ll see your titled report with a table of contents on the right.

Checkpoint 4 · Render works

After clicking Render:

RStudio will usually open the rendered HTML automatically, in whichever preview location it is configured to use.
In the Files pane (bottom-right), navigate to programs/ in your project. You should see m02_lab.qmd and a new m02_lab.html sitting next to it.
The rendered page should not need a companion m02_lab_files/ folder, because the YAML uses embed-resources: true (see M02’s YAML walkthrough). If a folder by that name is left over from an earlier test render, you can delete it.
Opening the HTML in a browser (in the Files pane, click m02_lab.html → View in Web Browser) should show a titled report with a table of contents — usually in the right margin, if your browser window is wide enough — and four section headings: Setup, Import Data, Glimpse, and Descriptive Statistics (that last one is still empty — you’ll fill it in Step 5).

If the render fails — look for a message beginning with Error in the Console or the Render pane — copy that message and ask the lab instructor before moving on.

Reading the glimpse() output · spotting variable types

The # Glimpse section you just rendered printed a compact one-line-per-variable summary. It looks something like this:

Rows: 5,000
Columns: 7
$ id              <dbl> 62163, 62172, 62174, ...
$ sex             <fct> male, female, male, ...
$ age             <dbl> 14, 43, 80, 80, 5, ...
$ age_group       <fct> Under 26, 36 to 45, 65 and older, ...
$ marital_status  <fct> NA, Single, Married, ...
$ education       <fct> NA, High School Graduate or GED, ...
$ SBP             <dbl> 107, 103, 97, ...

Each angle-bracketed tag is the column’s type — R’s label for what kind of values live inside:

<int> integer (whole numbers — for example, a count)
<dbl> double-precision numeric values, displayed as whole numbers or decimals (id, age, and SBP here)
<chr> character (text in quotes — names, free-text responses)
<fct> factor (categorical with fixed levels — what sex, marital_status, education, and age_group all are here)
<lgl> logical (TRUE / FALSE — common in filters)

Notice id sitting there as <dbl>. It is stored as a number, but it is an identifier, not a quantity — averaging it would be meaningless. This is M01’s point exactly: a column’s storage type does not tell you how the variable should be analyzed.

You’ll put the tags to work in the very next step. The three variables you’re about to summarize (sex, marital_status, education) are all <fct> factors — their factor class tells R these values are fixed categories, which lets tbl_summary() recognize their levels and display them as categorical summaries without any recoding.

(You’ll meet type conversion and NA handling in M04. For today, just know what the tags mean.)

Step 5 · Put your project under version control

You read about Git and GitHub in M02 and installed GitHub Desktop. Now we’ll do the actual work. We do it in two stages, and the order matters: first we put the project under version control, then you make a change, and then you commit that change. That sequence is what lets you watch Git notice a specific edit — which is the whole idea.

A useful way to think about it: Git keeps a local history of your project on your laptop, and GitHub stores a copy of that history in the cloud. By the end of this lab your PSY652_project will exist in both places.

Open GitHub Desktop

If GitHub Desktop isn’t open already, open it now. You should see your GitHub.com username under GitHub Desktop → Settings → Accounts (Mac; older versions say Preferences) or File → Options → Accounts (Windows) — if you don’t, the M02 Module walkthrough for connecting your account isn’t done. Flag the instructor.

Turn your project folder into a Git repository

Right now PSY652_project/ is just a folder. Git is not yet paying attention to it. We need to initialize it as a repository — a folder Git tracks so it can save a recoverable history of your work.

Do this here in GitHub Desktop — don’t create the repository on github.com first. We build it locally now and publish it to GitHub in Step 7. (Creating it on the web first, with a README or .gitignore, would collide with the README.md and .gitignore your project already ships.)

In GitHub Desktop, click File → Add Local Repository.
Browse to your PSY652_project/ folder and select it. Because it isn’t a Git repository yet, GitHub Desktop will not simply add it — instead it offers to create one. Which version you see depends on your GitHub Desktop release, and both lead to the same place:
- Some versions grey out the Add Repository button and show a warning line containing a blue create a repository link. Click that link.
- Newer versions let you click Add Repository, then show a message reading “This directory does not appear to be a Git repository. Would you like to create a repository here instead?” — with the same blue create a repository link. Click it.
Either way, you end up in the Create a New Repository dialog described next. If you see neither — the folder is added with no complaint — then it already contains a .git folder from an earlier attempt; stop and flag it, rather than layering a second repository on top.
In the dialog that opens:
- Name: PSY652_project (already filled in)
- Local path: leave the prefilled path alone. GitHub Desktop treats this as the parent folder and puts the repository inside it. Before you click Create, read the path once: it should end in exactly one PSY652_project — not PSY652_project/PSY652_project. If you see the name twice, click Choose… and pick the folder that contains your project.
- Description: leave blank or write a short note
- Initialize this repository with a README: leave unchecked — your project already ships a README.md
- Git ignore: leave as None — your project already ships with a .gitignore file, which GitHub Desktop will respect
- License: leave as None
Click Create Repository.

Now check what just happened — two possibilities, both normal

When GitHub Desktop creates a repository from a folder that already has files in it, it will usually make a first commit for you, called Initial commit. Usually — not always. So don’t assume; look.

Click the History tab (left side, next to Changes), and see which one you got.

A · History shows a commit called “Initial commit.” GitHub Desktop committed your existing files for you. The Changes tab will look empty and Commit to main will be greyed out — nothing is wrong, your files are all inside that commit. Carry on to the next paragraph.

B · History is empty, and the Changes tab lists several dozen files. Also completely normal — the automatic commit is a convenience, and it doesn’t always fire. Make it yourself; it takes about ten seconds:

Click the Changes tab. Every file should have a checked box beside it — leave them all checked.
In the Summary field at the bottom left, type: Initial commit - course project scaffold
Click Commit to main.

The Changes tab empties out and History shows your commit. You are now in exactly the same place as everyone who got option A — and you got to make your first commit a step early.

If Commit to main stays greyed out, or you get an error: your GitHub account probably isn’t connected. Git will not record a commit until it has a name and email attached, and GitHub Desktop takes those from your signed-in account — which is also the most common reason the automatic commit doesn’t happen. Re-check Settings → Accounts (Mac) or File → Options → Accounts (Windows), then flag the instructor.

Either way, you now have one commit containing your project files. This is exactly why we set Git up before you edit anything: in Step 6 you’ll make a real change to your notebook, and in Step 7 the Changes tab will show that one file — a much clearer first lesson than a list of forty.

Now look at what Git is and isn’t tracking. In the History tab, click that first commit. The right pane lists every file in it. Scroll the list: you should see your .qmd files, README.md, .gitignore, and documentation/references.bib — and nothing from data/. Your project’s .gitignore is doing its job. Open .gitignore from RStudio’s Files pane and skim it: each group of entries carries a one-line comment on why those files are skipped — your data stays local, and rendered .html isn’t committed because it regenerates from your .qmd source. (The M02 module walks through it in full.)

Checkpoint 5 · Repository created

In GitHub Desktop, the top of the left panel should show Current Repository: PSY652_project.

Click the History tab. You should have at least one commit — either GitHub Desktop’s Initial commit or the one you made yourself. Click it. In the file list on the right you should see:

Your .qmd files, README.md, .gitignore, and the documentation/ codebooks
Nothing from the data/ folder

Also glance at RStudio’s Files pane: your project should not now contain a second, nested PSY652_project/ folder inside itself. If it does, flag the instructor — the repository was created one level too deep.

If you see data/nhanes.Rds in that commit, stop and flag the instructor now. That means .gitignore is not being applied.

Step 6 · Add a Descriptive Statistics section

Now let’s practice the workflow you’ll use every week: add the two approaches below to your m02_lab.qmd notebook under its existing # Descriptive Statistics heading, write a short interpretation, render, and see your new content in the HTML. We’ll summarize three categorical variables in nhanes.Rds — variables you already met in M01 — using two tools you’ll reach for in many later labs (skim() and tbl_summary()).

The three variables:

sex — sex of the participant (factor with 2 levels: female, male)
marital_status — current marital status (factor with 6 levels: Divorced, Live with Partner, Married, Single, Separated, Widowed)
education — highest level of education completed (factor with 5 levels, from 8th Grade or Less through College Graduate)

For each variable you want to know (a) how observations are distributed across the categories, (b) whether there is missing data, and (c) how much. We’ll use two readable approaches. Try both, add them under the existing # Descriptive Statistics heading, and then re-render.

Approach 1 · skimr

nhanes |>
  select(sex, marital_status, education) |>
  skim()

skim() is a rapid screening summary: a complete-rate column (how much is missing), the number of unique levels, and the counts for the most common levels. Note that last point — for a variable with many categories, skim() shows the top few rather than every level, so it tells you the shape of a variable quickly without necessarily being the complete picture.

Approach 2 · gtsummary

nhanes |>
  tbl_summary(include = c(sex, marital_status, education))

tbl_summary() produces a publication-ready table: every category with its count and percentage, an Unknown row when values are missing, and proper variable labels when the data carries them. Where skim() is a broad screen, tbl_summary() is what you’d show a reader.

m02_lab.qmd already contains an empty # Descriptive Statistics heading at the bottom, with a TODO comment block right under it. That comment block lists the same three things this step asks for. Replace it with the two chunks above, then add your two-to-three sentence interpretation underneath them (the next section spells out what to write). Save the file, and render the document again. (To insert a code chunk, click the green +C button at the top of the Source pane, press Cmd+Option+I (Mac) / Ctrl+Alt+I (Windows), or just type the ```{r} and ``` fences yourself — don’t paste the code as plain prose.) Rendering runs the whole notebook top-to-bottom in a fresh session, so it loads the packages and data in the right order — you don’t need to run the new chunks inline first.

Then write what you see

A Quarto notebook is a document, not a place to park code. So underneath the two outputs, take a moment to write two or three sentences answering these:

Which of the three variables have missing values?
Why are so many values missing for marital_status and education? (Think back to M01 — this is missing by design, not a data error.)
What does tbl_summary() show you that is harder to see in the skim() output?

Render once more when you’ve written it. This is the habit the whole course is built on: code, output, and your reading of it, side by side in one document.

Checkpoint 6 · Descriptive stats render

Your rendered HTML’s Descriptive Statistics section — empty at Checkpoint 4 — should now contain a skim output block, a tbl_summary table, and your two or three sentences of interpretation.

If tbl_summary errors out, re-check that you typed the variable names exactly — they’re case-sensitive and use underscores (not hyphens).

If instead you tried running the new chunks inline (green arrow) and got could not find function "skim" or object 'nhanes' not found — that is a consequence of restarting R in Step 4, which cleared your session. Re-run the Setup and Import Data chunks first (top to bottom), or just click Render, which always starts fresh and loads everything in order.

Step 7 · Commit your change and publish to GitHub

You made a real change in Step 6. Now watch Git notice it, record it, and send it to the cloud.

Commit the change

Switch to GitHub Desktop and click the Changes tab. This time it will not be empty — it should list programs/m02_lab.qmd, the file you just edited. Click it, and the right pane shows your edit line by line: added lines in green, removed lines in red. This is what version control is for. You can see exactly what changed, before you record it.

A commit is a labeled checkpoint recording the tracked changes you include. You write a one-line message describing what changed, click a button, and Git records it in your local history.

In the bottom-left of GitHub Desktop:

In the Summary field, type a short message describing what you did:
```
Add Descriptive Statistics section to M02 lab
```
Notice that the message describes the change, not the file. Update m02_lab.qmd would be useless to future-you; this tells you what happened.
Leave the larger Description box empty — this change doesn’t need one.
Click the big blue Commit to main button. (main is the name of your repository’s primary branch — the main version of the project.)

The Changes list empties out, and the History tab now shows your commit sitting on top of the first commit from Step 5.

Checkpoint 7 · Your commit is recorded

Click the History tab. At the top you should see your commit, with the message you wrote — sitting above the first commit from Step 5 (whoever made it, GitHub Desktop or you).

Click your commit. The right pane should show programs/m02_lab.qmd and the lines you added, highlighted in green. It should not show your rendered m02_lab.html — .gitignore keeps it out, because it regenerates from the source every time you render.

Is Commit to main still greyed out? Then your Step 6 edit wasn’t saved. Go back to RStudio, press Cmd/Ctrl + S on m02_lab.qmd, and look at the Changes tab again.

You are looking at more than a receipt. That History tab is the thing that makes committing worth doing: every entry is a version of your project you can go back to. Right-clicking a commit — or a file in the Changes tab — is how you get at that, and it is the reason the next lab keeps asking you for commit messages that say something.

You do not need any of it today. When you do, it is written up in Going back to an earlier version.

Publish your repository to GitHub

So far everything lives on your laptop. To back it up, we publish the repository.

Click the Publish repository button at the top of GitHub Desktop.
A dialog opens:
- Name: PSY652_project (already filled in)
- Description: optional
- Keep this code private: ✅ leave this checked — your course work should be private. (You can change this later if you ever want a repo public; many researchers keep theirs private until a paper is submitted.)
Click Publish Repository.

GitHub Desktop uploads your commits to your GitHub.com account. When it finishes, the Publish button changes to Fetch origin — that’s GitHub Desktop’s way of saying “this repo is now connected to a copy on GitHub.”

Verify what actually reached the cloud

In GitHub Desktop, click Repository → View on GitHub. Your repository opens in the browser. (This is more reliable than hunting through github.com’s menus, whose labels change — some layouts say Your repositories, others just Repositories.)
You should see your programs/ and documentation/ folders, and your commit message at the top of the file list.
Click Commits (or the commit-count link) to see both commits — the one from Step 5 and the one you just made.

What is now on GitHub: your tracked source files and the commit history you pushed. If you moved to a different computer, you could clone this repository and get those files and that history back.

What is not on GitHub: anything .gitignore excludes — the data/ folder, the output/ folder, and your rendered .html files. Those stay on your laptop. On a new machine you would re-download the course data separately and regenerate the HTML by rendering your .qmd files. That is the intended design, not a gap: Git holds the source, and the source rebuilds the rest.

Checkpoint 8 · Your work is on GitHub

On github.com, your PSY652_project repository:

Is marked Private
Contains your programs/ and documentation/ folders
Does NOT contain data/ or the rendered m02_lab.html (confirms .gitignore is working)
Shows your commit message — the one you wrote in Step 7 — at the top of the file list

If anything’s off — flag the instructor. The point of doing this in lab is so we catch it together.

The everyday loop · what you’ll do from now on

Now that the setup is done, the day-to-day rhythm is short. Note where it starts:

Open GitHub Desktop first. Click Fetch origin, and if it offers Pull origin, click that too. Working solo this rarely changes anything — but starting here is the habit that keeps group projects out of trouble, so build it now.
Open the project in RStudio and do your work in your .qmd files.
When you’ve finished a coherent chunk of work, switch back to GitHub Desktop and read the Changes tab to see what you actually changed.
Write a one-line commit message (Add age-group filter to wrangling chunk, not Update). Click Commit to main.
Click Push origin — your committed, tracked files are now synchronized with GitHub. Anything ignored, and anything you haven’t committed, stays only on your computer.

The cycle: pull → edit → commit → push. You’ll do this dozens of times across the semester. By Week 3 it’s muscle memory.

Submit your rendered report

One last thing before the debrief. Upload programs/m02_lab.html to Canvas, under this week’s lab assignment. That single self-contained HTML file is the deliverable — you don’t submit the .qmd, and you don’t submit a zip. Every lab this semester ends the same way, so it’s worth forming the habit now: render, check the HTML, submit the HTML, then commit and push.

(Group projects make the pull-first habit essential — pull before you edit each session, to grab teammates’ changes — plus a few coordination habits. See Collaborating with Git for group projects when your Project 1 team forms in Week 5.)

Lab debrief · 5 minutes

That’s everything. When you’re ready, save your work and look up — we’ll spend the last few minutes pulling today together while it’s fresh.

Lab debrief · what did we learn by doing?

The sticking point. What was the single most frustrating moment today — an install, a path, a render, GitHub Desktop? What finally moved it? (Say it out loud: if one person hit it, others did too, and next week’s lab assumes today’s setup works.)
Inline vs. render. In Step 4 you restarted R and rendered, and things that had worked inline suddenly failed. What is the actual difference between clicking the green ▶ and clicking Render — and why is the render the one that tells you the truth about your document?
What Git is not. Your commit contains your .qmd files but not data/nhanes.Rds. If your laptop died tonight and you cloned your repository onto a new machine tomorrow, what would you get back, and what would you have to rebuild? Is that a flaw or a design choice?
The point of all this. You spent a whole lab on tooling and produced almost no statistics. What did you actually buy, and who is the beneficiary — you today, you in April, or someone else entirely?