Get to Know GitHub 2: How GitHub maps to Google Docs
Slides 5 to 8 (two problems, the first four cards, the next four cards, the whole loop). 0:06 to 0:13.
What this section has to do
Give people the vocabulary by tying every GitHub word to something they already do in Google Docs and Drive. Nobody should leave this section thinking the words are scary. Keep it moving: 7 minutes for eight terms plus the opener and the loop.
Opener: two problems everyone's had (slide 5, 1 minute)
This came from the March design doc, and it's the hook for the whole section.
- Last save wins. Two people are in the same file, and whoever saves last wipes out the other person's work. Usually nobody notices until something's missing.
- Which version is this? campaign_brief_v2_REAL_final.docx sitting next to campaign_brief_v2_FINAL.docx.
GitHub fixes both. Every version is kept with a note on what changed, so there's only ever one current file. And nobody saves over anybody, because changes come in through a pull request. Tell them to hold onto those two problems, because every card that follows is how GitHub solves one of them.
Good moment for a quick show of hands or chat poll: "Who's had the final_v2 problem this month?"
The eight terms
| GitHub | Google Docs version | Where the analogy breaks |
|---|---|---|
| Repo | A shared Drive folder for one project, with every version kept | A repo keeps the history of every file together, not file by file |
| Branch | File, Make a copy, so the original stays untouched | A branch can be merged back automatically. A Docs copy can't |
| Commit | Naming a version in Version history, with a note | Commits are deliberate. Docs autosaves, GitHub doesn't |
| Pull request | Suggesting mode | A PR covers a whole set of changes across files, not one doc |
| Review | An approval round: comments on lines, then approve or ask for changes | Approval is recorded, and the author can't approve their own |
| Merge | Accepting the suggestions | Merge can be undone with Revert, and the history shows both |
| Main | The approved, final version | On AIMCLEAR's repos, an org rule protects main, so changes come in through a pull request. Docs has no such lock |
| Issue | A ticket that lives with the code, like a ClickUp task stuck to the repo | We're not asking anyone to move their tasks out of ClickUp |
The "where it breaks" column is for you, not the slide. Use it when someone pushes on an analogy.
The clips (slides 6 and 7)
Each card has a frame for a short click-to-play clip of the Google Docs action. The hand-off prompt for recording them on your machine is in the channel files (google-docs-clips-handoff.md). Shot list:
- Repo: opening a shared Drive folder and scrolling its files
- Branch: File, Make a copy, naming the copy
- Commit: Version history, Name current version, typing a short name
- Pull request: switching to Suggesting and typing a change
- Review: adding a comment on a suggestion
- Merge: clicking Accept on a suggestion
- Main: the clean document after suggestions are accepted
- Issue: a comment assigned to someone, or a ClickUp task link
Use the scratch "Campaign brief (demo)" doc with made-up copy, never a real client doc. If the clips aren't ready by Thursday, the cards work without them. Just describe the action as you go.
The whole loop (slide 8, 1 minute)
Branch, commit, pull request, review, merge. That's the whole loop, and it's the same loop whether you click through it yourself or Claude does it for you. Point at the Merge box and say "start the next branch from here," because that's the habit that saves people from conflicts later. Then: "Next I'll run it once in the browser so you can see it."
Likely questions
- "Why not just let it autosave like Docs?" Because a named version with a note is what lets someone review it and lets you find it later. Small and often beats one giant save at the end.
- "What happens if two people change the same file?" Each works on their own branch. GitHub merges them if the changes don't overlap. If they do overlap, GitHub asks a person to pick, and nothing gets silently overwritten.
- "Do I need Issues?" No. They're on the slide so the word isn't a mystery when you see it.
- "What's the difference between Git and GitHub?" Git is the version tracking. GitHub is the website that hosts it and adds the collaboration parts like pull requests and reviews.
Watch out for
- Don't let this turn into a terminology lecture. One sentence per card, then move on.
- Clips can stall a talk. Click once, talk over it, move on even if it's still playing.
- If someone uses Box or Word more than Docs, the analogies still hold: copy, versions, track changes.
Done when
People can say what a branch, a commit and a pull request are in their own words, using the Docs comparison.