Git for Scientists

Lars Schöbitz

Global Health Engineering - ETH Zurich

July 15, 2026

Part 1: Welcome {background-color=“#5c5751”}

Meet the lecturer

Lars Schöbitz

• Environmental Engineer
• Retired researcher
• RStudio certified instructor
• Data steward at ETHZ

Your turn

Think about the last time you published a written document:

• Which tasks gave you joy?
• Which tasks were challenging or frustrating?

Take some written notes.

What this day is, and is not

• Today is the Git and GitHub foundation for collaboration: create, clone, commit, push, branch, pull request, review, merge.
• Today is not an AI workshop. Working with AI coding agents builds on exactly these skills; that is the follow-up workshop.
• It is safe to fail here. Everything we do today is reversible, and breaking things is part of the plan.

Defuse the AI-agent expectation gap now, in minute 5, not in minute 90. Say the safe-to-fail promise out loud; it comes back in B3 with the revert demo.

• Git and GitHub -> what we learn today
• Quarto and R -> you will see them, not learn them
• RStudio IDE -> our interface, could also be VS Code, Positron IDE, GitHub Desktop, and others

Meeting you where you are

How you store your data today

Most of you already store data in machine-readable formats, which is exactly what Git and Quarto reward. The spreadsheet users are Arti’s group; the day nudges toward CSV without making a fuss about it.

What you want to learn

From your pre-course survey (n = 18), three groups:

• Covered directly today (10): use Git without fear, the full commit cycle, branching, documenting a reproducible workflow, and collaborating and reviewing through pull requests.
• Partially covered (1): rebasing and staging in a systematic way. We build the foundation; the advanced moves are a natural next step.
• The follow-up workshop (7): Git together with AI coding agents. Today is the Git foundation that makes it possible.

Counts are editorial (n = 18); refresh them if the roster changes. The three buckets map onto the three personas in learner-persona.md: Arti wants to stop being afraid of Git, Bianca wants confident collaboration and pull-request review, Cem wants control and provenance of AI-assisted work. Around seven of you asked for agentic-coding topics; name that and tie it back to the “not an AI workshop today” framing from the opening. One off-topic answer (analysing data) folds into the R-you-will-see-not-learn framing.

Meet Arti

Three personas describe this room (Arti, Bianca, Cem). My focus learner is Arti.

• Background: post-doc, in a group of mixed Git fluency.
• Knows: some R; lives in Word, Docs, and email; versions files by hand. Tried Git once, an error stopped them cold.
• Wants: to collaborate without fear.
• Needs: a safe-to-fail room.

Learner personas in the Greg Wilson / Teaching Tech Together sense, synthesised from this cohort’s survey (see learner-persona.md). Say the focus-learner idea out loud: I teach to Arti, which also serves Bianca (early finisher, curious about the command behind each click) and Cem (wants AI provenance; today is the foundation, agentic coding is the follow-up).

Course structure

• My turn: Lecture segments + live coding
• Your turn: Individual or 2-people team exercises (in break-out rooms on Zoom)

Course icons

Two icons tell you where a step happens:

•   in the RStudio IDE, on your own machine
•   on GitHub, in the browser

Watch for these on every “Your turn” slide.

Learning objectives

By the end of this workshop, you will be able to:

1. Commit cycle: create and clone a repository, and run the full pull, stage, commit, push cycle from the RStudio IDE, including reverting a commit.

2. Collaboration: create a branch and open a pull request, review a colleague’s pull request, and merge it after review.

3. Concept map: draw how Git and GitHub fit together.

Bloom check: objective 1 is Apply (create, clone, run, revert are observable procedures you can check in the room); objective 2 is Apply plus Evaluate (reviewing a pull request is a judgement); objective 3 is Understand/Create (drawing the concept map externalises the mental model, and it is the measurement bookend for the day). Publish was removed as a core objective; publishing and a one-page personal website are offered as a follow-up on the website repository (profile links and bio), not dropped silently.

Schedule

Time	Module
09:30 - 10:00	Arrival
10:00 - 10:30	Part 1: Welcome, concept-map intro, baseline map
10:30 - 10:50	Part 2: Create & Clone
10:50 - 11:00	Break
11:00 - 11:30	Part 3: The commit cycle
11:30 - 11:50	Part 4: Team work
11:50 - 12:45	Lunch Break
12:45 - 13:05	Part 5: Work on a branch
13:05 - 13:45	Part 6: Pull Request, Review, Merge
13:45 - 13:50	Movement Break
13:50 - 14:00	Part 7: Merge conflict
14:00 - 14:30	Part 8: Concept map revisit and wrap-up

Concept maps

Concept maps

A concept map is things (nodes) joined by labelled arrows, where every label is a verb.

Per Greg Wilson, Teaching Tech Together: concepts as nodes, labelled relationships as edges. Not a flowchart, not a timeline, not a list; no start, no end.

One sentence on why: experts use concept maps to make their mental models visible. Yours today will show how you currently think documents travel, and this evening the second map will show what changed.

8-10 minutes for this intro including the exemplar walk-through.

Your turn: your baseline map

How does a document you write reach your co-author and come back? Draw it as a concept map.

• Things as nodes, arrows with verb labels.
• There is no wrong map; this one is yours.
• Keep the map. You will need it again at the end of the day.

  In the room: place the yellow sticky note on your laptop when your map is done.

  On Zoom: write “done” in the chat.

One single prompt, not a fused double question. Expected content: email attachments, Dropbox, Google Docs, file naming (final_v2, final_final). That is the point; the day connects Git to these habits. Do not correct anything here.

Bounded regroup: 2 minutes, then park-and-pair; 1:1 fix at the next break.

Part 2: Create and clone {background-color=“#5c5751”}

Create and clone: Arti’s project

Arti (before)

• starts a new folder on her laptop
• adds data as .xlsx
• adds a .docx report
• adds an R script

Arti (after)

• creates a repository on GitHub
• clones it and opens an RStudio project
• adds data as .csv
• adds a Quarto document and an R script

Same project, two ways. Read the columns as pairs: each line on the left has a Git/GitHub answer on the right. This is the whole block in one slide; the highlighted lines are what we do together next.

My turn

Sit back and watch.

Note down any questions as they come up. We pick them up right after.

Demo script:

• Create the repo on GitHub with a README so the clone is never empty.
• RStudio settings: Tools > Global Options > General: Save workspace to .RData on exit: Never. Tools > Global Options > Code: check use native pipe operator.
• Clone into the pre-work folder structure (~/Documents/gitrepos/gh-org-gitforsci-ghe is the example from the setup test; for their own repos, gh-USERNAME).
• The .Rproj and .gitignore explanation lives here, not on a slide: .Rproj holds RStudio project settings, .gitignore lists what Git should not track; the yellow ? icons mean Git sees the files but nobody has told it what to do with them yet. This answers the recorded learner question “why do .Rproj session files show up?”. Mention that hidden files (starting with a dot) are hidden by the operating system.

Your turn

  On github.com

1. Create a repository called website, public, with a README (so the clone is never empty).

  In RStudio

2. Set two options once (Tools > Global Options): General > never save .RData on exit; Code > use the native pipe |>.

3. Clone: File > New Project > Version Control > Git, paste the HTTPS URL, create the project inside your gitrepos/gh-USERNAME folder.

4. Find .gitignore and website.Rproj in the Git tab with their yellow ? icons.

  In the room: place the yellow sticky note on your laptop when you see the two yellow ? icons.

  On Zoom: write “done” in the chat.

Screenshots of the Code button, the New Project dialog, and the Git tab go here once available. .Rproj holds RStudio project settings; .gitignore lists what Git should not track; the yellow ? icons mean Git sees the files but has no instruction for them yet. Bounded regroup: 2 minutes, then park-and-pair; 1:1 fix at the next break.

  Everyone with the two yellow ? icons? Take your sticky note back down.

We move on together.

Local and remote

The summary of what we just did. Advance one element per press: the remote on GitHub (a cloud), then your local repository, then clone down, then push up and pull down.

Anything from creating and cloning you’d like clarified before the break?

Take a break

Please get up and move!

Part 3: The commit cycle {background-color=“#5c5751”}

A button is a command

• RStudio is a GUI, a graphical user interface.
• When you click Pull in the Git tab, RStudio runs git pull for you.
• Every button we use today is a Git command underneath. Clicking it is not a lesser path.

This is the slide for Arti: the point-and-click interface is not cheating. The push button runs git push. Say it plainly and come back to it whenever someone worries they are “not really doing Git”.

The commit cycle: Arti’s commit

Arti (before)

• opens a .docx
• edits the text, it autosaves
• automated version history
• sends an email to say what changed and why

Arti (after)

• opens a Quarto file
• edits the text, it autosaves
• after meaningful changes: pull, stage, commit, push
• the commit message says what changed and why

My turn

Sit back and watch.

Note down any questions as they come up. We pick them up right after.

Demo script:

• Edit README, save, point out the blue M next to the file in the Git tab.
• Sync in 4 steps, said as a mantra: Pull (nothing to get, but build the habit), Stage (checkbox), Commit (message: “describe the repo content”), Push. Then open the repo on GitHub and show the commit message and the file change there.
• Revert demo, instructor only: make a deliberately bad commit (for example delete half the README), commit it, then revert it via the history; show that the history keeps both the mistake and the undo. Say the safety-net message out loud: almost everything in Git is reversible. This answers the recorded learner question “how do I take a commit back?”.
• Credentials moment: hands up, who was asked for a username and password? Walk through gitcreds::gitcreds_set() in the console with the PAT from pre-work step 4. This is the moment credentials get fixed for everyone, before the afternoon depends on pushing.

Your turn

The cycle, always in this order: Pull, Stage, Commit, Push (PSCP).

  In RStudio

1. Edit your README.md: describe your website in one sentence. Save, and spot the blue M in the Git tab.
2. Run the full cycle: Pull, Stage, Commit (a message that says what changed), Push.

  On github.com

3. Open your repository and find your commit message and your change.

  In the room: place the yellow sticky note on your laptop when you can see your commit on GitHub.

  On Zoom: write “done” in the chat.

Goal: every learner has at least 2 commits pushed to their own repo by the break. The revert stays instructor-only in this block; learners do not revert here. PSCP is the mantra; say it every time. Bounded regroup: 2 minutes, then park-and-pair; 1:1 fix at lunch.

Our turn

Now the same cycle, but starting on GitHub. In your website repository:

  On github.com

1. Edit README.md and commit the change (the pencil icon, then “Commit changes”).

2. Add a file inside a new folder (Add file > Create new file, type data/notes.md).

  In RStudio

3. Pull to bring both commits down to your laptop.

  Place the yellow sticky note on your laptop when the two new commits show up in RStudio.

This closes the loop: a commit can start on GitHub, not just in RStudio, and Pull is how it reaches the laptop. It sets up why Pull leads the PSCP mantra.

The commit cycle

The summary of what we just did. Advance one element per press: working files, stage, commit as a labelled snapshot, the history line growing, then push.

Anything from the commit cycle you’d like clarified before we move on?

Part 4: Team work {background-color=“#5c5751”}

Team work

Arti (before)

• opens SharePoint
• finds Cem’s docx file
• edits it in track changes
• autosaves
• emails Cem to say it is done

Arti (after)

• opens the project in RStudio
• finds Cem’s Quarto file
• edits
• runs the PSCP mantra
• comments / closes open issue to say it’s done

This slide sets up the cliffhanger. Arti does everything right and still cannot push to a teammate’s repository. That is the safe-to-fail moment: nothing is broken, and the afternoon answers why.

Find your partner

• You are in a pair with the partner you were told about before today.
• Write each other’s GitHub username on your sticky notes.
• Keep that sticky note. Your partner returns after lunch.

The sticky notes with usernames are the pairing record and carry into the pull-request block as reviewer assignments. If someone has no partner, they pair with the helper or the instructor.

Your turn

  On github.com

1. Browse to github.com/USERNAME, where USERNAME is your partner’s username.

  In RStudio

2. Clone their website repository (Code button, HTTPS URL, File > New Project > Version Control > Git) into a new folder gitrepos/gh-USERNAME that reflects your partner’s username.

3. Edit the README: add “This repo contains a personal website for USERNAME.”

4. Run the mantra: Pull, Stage, Commit, Push.

What happens?

  In the room: place the yellow sticky note on your laptop when something unexpected happens.

  On Zoom: write “blocked” in the chat.

Everyone hits the push wall: 403, no write access. That is the plan; it is the safe-to-fail moment with the lowest stakes of the day. Nobody’s work is harmed, nothing to clean up. Screenshot of the 403 error goes here once available. Bounded regroup: 2 minutes, then park-and-pair; 1:1 fix at lunch.

What just happened?

• Your push failed: you can read their repository, but you have no write access.
• Giving everyone write access (“collaborator”) exists, but it does not scale, and it means anyone can change anything at any time.
• So how do teams actually propose and review changes? That is exactly what we solve after lunch: branches and pull requests.
• But before that, one last exercise to tie the morning together.

The cliffhanger, stated explicitly. The morning ends with a question the afternoon answers. Do not resolve it now. The fork route (contributing to someone else’s repo without write access) is the follow-up offer for building a personal website; mention it exists, do not teach it here.

Exercise: Match the Git command to the button

A one-page handout: draw a line from each Git command to the button that runs it in RStudio or on GitHub.

• 3 minutes on your own.
• 5 minutes comparing with your partner.
• The point: clicking a button runs the same command a terminal user types.

Timer is set to 3 minutes for the solo pass; restart it for 5 minutes when pairs start comparing.

Handout from gitforsci-dev/exercises (command-gui-matching). Print one learner sheet per person; remote participants receive it by email. Review as a group with the answer key afterwards. This is the “a button is a command” idea from B3, made concrete.

Lunch

The afternoon starts hands-on, and your partner is waiting for you.

Return time is set on the day (timing to be finalised with a fresh schedule). The afternoon starts hands-on as the re-energizer; anyone who arrives late can join mid-exercise without missing slides.

Part 5: Work on a branch {background-color=“#5c5751”}

Work on a branch: Arti’s branch

Arti (before)

• one shared file
• everyone edits the same copy
• edits clash: two people change the same line and one overwrites the other

Arti (after)

• creates a branch for their work
• edits safely, away from main
• their changes wait until the team is ready to bring them in

My turn

Sit back and watch.

Note down any questions as they come up. We pick them up right after.

Demo script:

• New repo, new move. Clone the team manuscript repo (same moves as this morning).
• Git pane: New Branch, name it dev. Read the message about origin out loud.
• Open manuscript.qmd, edit the author details, Render.
• Switch between main and dev in the Git pane: before the commit nothing differs; after the commit, the change lives only on dev.
• Commit “update author details”, push.

Packages are already installed from the pre-work setup test, so the render takes seconds. If a render fails on a missing package, the commented install chunk sits at the top of manuscript.qmd; do not run installs for the room, park that learner and pair them. The branch created here feeds the pull request in the next block, so keep momentum.

Your turn

Your team shares one manuscript repository, washinvestments-<team> (for example washinvestments-red).

  On github.com

1. Find and clone your team’s washinvestments-<team> repository (org page, search your team name).

  In RStudio (one person drives)

2. Git pane: New Branch, name it dev.
3. In manuscript.qmd: put in your own author details in one of the two author slots. Render.
4. Run the mantra: Pull, Stage, Commit, Push with the message “update author details”.

  In the room: place the yellow sticky note on your laptop when your push has finished.

  On Zoom: write “done” in the chat.

Team repos are washinvestments-<team>, created from the reworked manuscript template (two author slots, no publishing). Team names are set on the day; use the placeholder until then. Screenshots of the New Branch, Render, and Git-tab buttons go here once available. One person drives so the branch and commit are shared; the partner reviews in the next block.

Branching

The summary of what we just did. Advance one element per press: the main line, the dev branch splitting off, commits landing on the branch, and the merge point left empty until the pull request in the next block.

Part 6: Pull request, review, merge {background-color=“#5c5751”}

Review

Arti (before)

• emails file / SharePoint
• uses comment function
• poor record of who changed what, when

Arti (after)

• opens a pull request
• her partner leaves line comments
• the change is merged after review, with a full record

Same review habit Arti already has (comments in tracked changes), now on GitHub with a record. This is the moment the day was built for.

My turn

Sit back and watch.

Note down any questions as they come up. We pick them up right after.

Demo script:

• On GitHub: switch to dev, click Compare & pull request. Title: “Add author details to manuscript”.
• Request a reviewer. Walk the tabs: Commits, Files changed.
• As the reviewer: start a review, leave line comments, submit. Review comment examples to reuse verbatim: “That’s not a good title for a manuscript. Please suggest 2 alternatives.” and “This list is not complete.”
• Open an issue with a task list next to the PR. Merge, confirm, tick off the task.
• Back in RStudio: switch to main, read the “behind origin/main, can be fast-forwarded” message out loud, Pull. Then the gotcha: switch back to dev. Name it as a habit: merged? Then pull main, and go back to your working branch.

Your turn

You each take a role: Author owns the pull request; Reviewer reviews it.

Author (goes first)

  On github.com

1. Open a pull request from your dev branch. Title it so your reviewer knows what changed.
2. Request a review from your partner.
3. Read the review. Then either make the proposed changes and push again, or merge as is. Confirm the merge.

  In RStudio

4. Switch to main, Pull, and switch back to dev.

Reviewer (goes second)

  On github.com

1. Open your partner’s pull request.
2. Start a review: leave at least one line comment.
3. Add an overall comment, then submit the review.

  In the room: place the yellow sticky note on your laptop after the switch back to dev. Then swap roles.

  On Zoom: write “done” in the chat.

Two roles, then swap, so everyone both opens a PR and reviews one. Everyone has read access to their partner’s repo, so no seed PR is needed. Screenshots go in the placeholder above once captured.

Target: every learner opens a PR, writes at least one line comment, merges, and pulls. This block is protected: if the day is behind, cut elsewhere, never this. Bounded regroup: 2 minutes, then park-and-pair.

The pull request

The summary of what we just did. Advance one element per press: the open merge point from the branching drawing, the pull request, the human review at the join, then the merge.

Part 7: Merge conflict {background-color=“#5c5751”}

When two edits meet: Arti’s conflict

Arti (before)

• two people edit the same line
• last save wins
• the other edit is silently lost

Arti (after)

• Git spots the clash and stops
• it marks both versions in the file
• Arti chooses, nothing is lost

The reassuring frame: a merge conflict is not a failure, it is Git refusing to guess. Nothing is lost; the human decides. This is the payoff of the “safe to fail” promise from the morning.

My turn

Sit back and watch.

A conflict is coming. Watch how Git asks me to choose.

Demo script (instructor only, no learner exercise in this block):

• Set up the clash on purpose. On GitHub, edit one line of manuscript.qmd on main directly (for example the manuscript title) and commit.
• In RStudio, on dev, edit the same line differently. Commit.
• Pull. Git stops and reports a conflict in manuscript.qmd.
• Open the file. Walk the conflict markers out loud: <<<<<<< HEAD is your version, ======= is the divider, >>>>>>> is the incoming version.
• Choose: delete the markers and keep the line you want (or combine both). Save.
• Stage, Commit (“resolve conflict in title”), Push.
• Say the safety message: Git never threw away either edit; it handed you both and waited. Almost everything in Git is reversible, and a conflict is Git protecting your work, not breaking it.

Keep this instructor-only; a learner conflict exercise is a natural follow-up but risks eating the protected pull-request time.

Resolving a conflict

When Git stops, it writes both versions into the file:

<<<<<<< HEAD
Investments in WASH: a five-year review
=======
WASH investments: evidence from five years
>>>>>>> main

• <<<<<<< HEAD: your version
• =======: the divider
• >>>>>>> main: the incoming version

Delete the markers, keep the text you want, then Stage, Commit, Push.

The reference slide learners can look back at. Keep it plain: a conflict is a normal part of collaboration, resolved by choosing.

Part 8: Concept map revisit and wrap-up {background-color=“#5c5751”}

Your turn: your map, revisited

Draw a concept map of Git and GitHub as you understand them now.

• 5 minutes: Use the words from today: repository, clone, commit, push, pull, branch, pull request, merge, review.
• 5 minutes: Pin it on the wall next to your morning map, so both maps sit side by side.
• 5 minutes: Walk to your team member’s two maps and talk through what changed between morning and now.

With your consent, I would like to photograph both maps (anonymously) to improve this workshop.

This block is protected and runs even on the worst day.

The comparison is the measurement instrument for the whole redesign. Consent is asked on the slide; photograph only the maps of learners who agree, no names on the photos. Send the written consent request by email ahead of the workshop, so the on-slide ask is a reminder, not the first time they hear it.

Fallback if the morning baseline went badly: draw the Git concept map yourself on the board as the closing recap and have the room call out the verb for each arrow (see the handbook, concept maps as bookends).

Wrap-up

What you learned today

Matched to the three objectives from this morning:

• Commit cycle: you created and cloned a repository and ran the full pull, stage, commit, push cycle.
• Collaboration: you opened a pull request, reviewed a partner’s, and merged after review.
• Concept map: you drew how Git and GitHub fit together, twice, and saw what changed.

Why this matters

• Issues, commit messages, and pull-request reviews are visible to other people. They show how you work and communicate.
• That signal only grows as more content is AI-generated: a clear issue with a good task description guides your collaborators, and guides any AI agent you run on the repository.
• The issue tracker is a TODO list attached to the work. Tasks live on the repository, and once closed they stay there, next to the commits and messages that resolved them.

What you also learned today

• RStudio IDE, now with muscle memory
• Quarto: one document; reproducibility; many use cases
• Reversibility as a habit: commit early, revert when needed

What comes next

• GitHub Project and Task Management is the next workshop (tentatively 26 August, 09:30–14:30). It builds on exactly what you did today: branches, pull requests, review.
• Want to keep practising? Work with me on a small, free personal website to rehearse branching, pull requests, and reviews on something that is yours.
• Interested in either? Email me and you will hear from me when dates are set.
• Start your first own project with Git and GitHub this week (already have a project? Read here).
• Keep learning by doing: open pull requests to yourself, review your own diffs.

The next workshop date (26 August) is tentative; confirm before the slide goes live. The AI-agent workshop framing from the opening still holds as the longer horizon; this slide names the concrete, dated next steps.

Feedback, and thanks!

• Please fill in the post-course survey (link shared by email, 5 (max 10 minutes), anonymous).
• Share your open questions: Google Doc or Issue tracker; I will answer all of them next week

Survey link goes out by email right now, while the slide is up, so phones can grab it. End on momentum: recap done, next step named, thanks.

Thanks!

Slides created via revealjs and Quarto: https://quarto.org/docs/presentations/revealjs/

Access slides as PDF on GitHub

All material is licensed under Creative Commons Attribution 4.0 International.