lecture.studio

Version control for lecture slides: git for a course folder

By Ekrem Çetinkaya · Published

Put the course folder in git when the decks are text: one repository per course, one folder per week, a commit after each lecture's edits and a branch only when two people change the same week at once. Ignore exported PDFs and the assistant's caches. The payoff is a diff between this year's week 5 and last year's, and a history of why a slide changed.

This guide is for instructors who already keep decks as Markdown (Marp, or any text format) and want the version history without turning teaching into software engineering. It stops well short of pull requests.

Why version-control slides at all?

Three situations come up every term:

  1. "What did I change since last year?" With PowerPoint files, the answer is a manual side-by-side. With text in git, it is git diff between two tags.
  2. "That slide was right last week." A commit per lecture means the previous version is one command away, with the date and a message saying why it changed.
  3. Two instructors, one course. A shared repository gives both people the same files, with a record of who changed what, instead of week5-final-v2-JD.pptx.

None of this works with binary slide files, which is the strongest argument for keeping the decks as text in the first place.

A layout that works

os-course/
  syllabus.md
  sources/            readings the whole course cites
  themes/             the Marp theme, so a clone renders the same
  week-01/
    deck.md
    assets/
  week-02/
    deck.md
    …
  .gitignore

One deck per week, images next to it, and the course-wide material at the root. Numbered folders sort correctly and match the syllabus table.

What to commit and what to ignore

Commit the decks, the syllabus, the assets, the theme and the notes. Ignore what can be regenerated or is too large to diff:

*.pdf
*.pptx
*.html
.DS_Store
.cache/

Sources are a judgement call: your own notes and slides, yes; a publisher's PDF chapters, probably not in a repository you might share. If the readings must be in the repo, keep the repository private.

A weekly routine

  1. Before the lecture: edit the week's deck, then commit with a message that says what changed and why (week 5: replace the scheduling example with the lab data).
  2. After the lecture: note what ran long or did not land in the deck's own comments, commit again (week 5: notes after lecture).
  3. At the end of term: tag it (git tag fall-2026) so next year's diff has a fixed point.

Two commits a week is all it takes for the history to be useful.

Sharing with a co-instructor

Push to a private repository on any git host, add the co-instructor, and agree on one rule: pull before editing, commit and push after. When both of you must change the same week in the same afternoon, one of you works on a branch and merges; otherwise stay on main. Merge conflicts in Markdown are readable, which is the other benefit of text.

Git without the command line

If the command line is the reason a colleague does not do this, the tools have caught up. Editors show diffs inline, and some slide tools include the routine. Lecture Studio keeps the library folder as plain files and, when that folder is a git repository, shows a bar at the bottom of the workspace with the branch, the changed files, Pull, Push and a What changed? field with Commit all; a plain folder can be turned into a repository from Settings. The commit-per-lecture routine above is then two fields and a button. The app runs on macOS 15 or later; git works without the assistant, which needs an Oberik project key.

FAQ

Should lecture slides be in git?

If they are text (Markdown, LaTeX), yes: the history and the diffs are the whole point. If they are PowerPoint or Keynote files, git stores them but cannot diff them, and the benefit is small.

What should I ignore in a course repository?

Exported PDF, PPTX and HTML, OS files such as .DS_Store, caches, and usually publisher PDFs of the readings. Commit the decks, syllabus, images and theme.

How often should I commit?

Once before each lecture (the changes) and once after (the notes). Tag the end of each term.

Can two instructors edit the same course in git?

Yes. Share a private repository, pull before editing and push after. Use a branch only when both need the same file at the same time.

More guides