2  Teaching philosophy

Three principles drive every decision in this workshop.

2.1 Teach on a need-to-know basis

Git is large. The workshop is not. You are not teaching Git; you are teaching the smallest set of Git that lets a researcher collaborate on GitHub confidently. That means a handful of actions (clone, pull, stage, commit, push, branch, pull request) and almost no theory about how Git works underneath.

One small addition earns its place: reverting the latest commit. Demonstrate it once, live. Make a change, commit it, then undo that commit and watch the file return to its earlier state. This is the safety net that regular committing buys you, and seeing it work does more to settle nerves than any reassurance. It also reinforces the habit of committing often, because frequent commits are what make the net fine-grained.

Resist the urge to explain the object model, the staging area as a concept, or rebasing. A learner who can complete the collaboration cycle has succeeded. The mechanics underneath can wait until they have a reason to care.

New educator — you will be tempted to add “just one more useful thing.” Every addition adds cognitive load and costs hands-on time, which is the scarcest resource in the room. When in doubt, cut.

2.2 Make the room safe to fail

Most learners arrive convinced they will break something. The whole workshop is built to prove them wrong. Git is, in fact, the safest place to make mistakes, because almost everything is reversible. Say this out loud, early, and then let them experience it.

Practically, this means:

  • Everyone works in their own repositories inside a dedicated organization for the cohort. Nobody can damage the real material.
  • Mistakes are demonstrated on purpose. Show a bad commit, then revert it. Show a merge that needs attention, then resolve it.
  • Support runs over email and GitHub issues (see Chapter 6): a learner who is stuck emails you, or opens an issue on their setup repository and assigns you, and that habit carries beyond the course.

The emotional outcome matters as much as the technical one. A learner who leaves believing “I can try things and undo them” will keep using Git. A learner who leaves anxious will not.

This is where mindset matters. Aim to leave every learner with “I can do this,” not “this is not for me.” Be alert to stereotype threat: people who do not see themselves as typical programmers can underperform simply from the worry that they will confirm a stereotype, and an offhand remark or an impatient response can trigger it. Keep the room warm, treat every question as reasonable, and never imply that a step is obvious. The chapter on motivation and demotivation in Teaching Tech Together (https://teachtogether.tech/en/index.html#s:motivation-demotivation) covers this well.

2.3 Put collaboration at the center

Many Git courses teach the solo workflow first and add collaboration as an advanced topic. This workshop inverts that. Collaboration is the reason researchers care about Git and GitHub, so it is the spine of the day from the first hands-on task.

The pull request is the centerpiece. Branching, committing, and pushing all exist in the workshop because they lead to a pull request that a collaborator reviews and merges. Lean hard on a comparison your learners already know: a pull request is where you comment on a change before accepting it, exactly like tracked changes and comments in Microsoft Word or Google Docs. Someone proposes an edit, someone else reads it, leaves comments on specific lines, and only then is it accepted. Make this analogy early and return to it often. It turns an unfamiliar Git concept into a familiar habit, and it is the moment most researchers realize GitHub is doing something they already do, just kept next to the code and data instead of in a separate document.

This also gives you a test for what belongs in the session. When you sequence the day (Chapter 11), ask of each step: does it move learners toward opening or reviewing a pull request a human can read? Branching, committing, and pushing all pass that test, because they set up the review. A step that does not lead toward a reviewed change is probably not worth the scarce hands-on time.

Collaboration on GitHub is also project management, and it is worth naming that. GitHub Issues are tasks, and they live at the level of the repository, attached to the work they describe rather than scattered across email or a separate tracker. If a pull request is a comment on a change, an issue is a comment on the project as a whole: a note pinned to the folder the work lives in, where the next person will actually find it. Researchers recognize this immediately, because it is the same instinct as leaving a comment in a shared document, only kept next to the code and data instead of away from it.

2.4 Teach to a focus learner

The room is never uniform. The course keeps three learner personas (Appendix C), synthesised from pre-course surveys in the sense of Teaching Tech Together: Arti, the fearful outsider; Bianca, the collaboration-driven R user; and Cem, the controlled-AI researcher. Pick the persona the day is calibrated to and teach to them. In the reference run that is Arti: a room paced for Arti stays safe to fail, while Bianca gets the command behind each click as stretch material and Cem gets the provenance framing and the pointer to the agentic follow-up. Reading the survey results back to the room through these three, in Part 1 of the run of show (Chapter 11), is also how learners see themselves in the day.

2.5 Where these principles come from

These principles are not abstract ideals. They come from observing a research group from the inside, and from running this workshop with real research groups and watching where people get stuck and where they light up. The four hand-drawn concept drawings that assemble stage by stage on the slides (Chapter 4) carry the same spirit: friendly, low-stakes, collaboration-first. Keep that tone in the room. The Openscapes lesson series (Stewart Lowndes et al. 2024) shares this collaboration-first approach and is one of the post-workshop readings.

The pedagogy also rests on the work of Greg Wilson and the book Teaching Tech Together (Wilson 2019), which distills how people actually learn technical skills. Read it alongside this guide; it is the single best companion to what follows. The Carpentries, which Wilson co-founded, run instructor training where these principles are taught in depth (https://carpentries.org/instructor-training/), and it is well worth the time if you plan to teach often.