Get to Know GitHub 3: The whole loop, live
Slide 9 (Watch it once, in the browser). 0:13 to 0:22. Screen share in the shared practice repo, github.com/aimclear/github-practice.
What this section has to do
Show the loop end to end in the same browser screens people will use right after this. The goal is recognition: when they hit the hands-on, every button should be one they've already seen you click.
Show-then-explain
From the March design doc: name each idea out loud as you click it, instead of only on the earlier slides. "That's the branch. That's the commit. That's the pull request." The words from section 2 land on something real, and people connect the Docs analogy to the GitHub button.
Before you share your screen
- Browser zoom at 125 to 150 percent so people can read on a laptop.
- Signed in, practice repo open in one tab, the PR list in another.
- A dev team helper ready to comment on and approve the demo PR, because you can't approve your own PR. No switching to a second account.
- Close Slack, email and anything with client names on screen.
- Have the file you'll upload ready on your desktop, with no secrets and no client data in it.
Click-by-click script
| Step | Click | Say |
|---|---|---|
| 1 | Repo home page | "This is the repo. Files, the README that explains it, and who changed what last." |
| 2 | Open a file, then History | "Every version of this one file, with who and why. This is the version history from the Docs slides." |
| 3 | Pencil icon | "I'm editing right in the browser." Make a small, visible change. |
| 4 | Commit changes... | Choose "Create a new branch for this commit and start a pull request" and type the branch name. GitHub offers a new branch because an org rule protects main. "Notice it won't let me change main directly. That's the branch from earlier: my own copy." Write a short note. "That note plus the save is a commit." Click Propose changes. |
| 5 | Create pull request | Write a one-line description. Add a reviewer: the gear icon next to Reviewers, on the right side, then pick the dev team helper. "This is suggesting mode. I'm asking to merge my branch into main." |
| 6 | Files changed tab | "Red came out, green went in. This is what the reviewer actually looks at." |
| 7 | Comment on a line | Have the dev team helper leave a comment on one line. "An open comment has to be resolved before Merge unlocks." Resolve it. |
| 8 | Approve, then Merge | "I can't approve my own PR, so someone else has to." Have the dev team helper approve (Files changed > Submit review, or Review changes in the older layout > Approve > Submit review), then merge. "That's accepting the suggestions. It's in main now." |
| 9 | Add file, Upload files | "For something that already lives on your laptop." Drag in the prepared file, commit to a new branch. "Browser uploads get the same key check as everything else." Don't bother finishing this PR on screen. |
Three things to point out as they happen
These came out of the dry run in aimclear/TimothyEastvold:
- An org rule protects main on AIMCLEAR's repos, so GitHub won't let you commit straight to it and offers a new branch for you.
- You can't approve your own PR. Someone else has to.
- An open comment has to be resolved before Merge unlocks.
Each one is a guardrail, not an error. Say it that way: "This is GitHub making it easy to get a second set of eyes."
Backup plan
If the live demo misbehaves (GitHub is slow, the helper can't get in, your share freezes):
- The backup recording is github_training_pr_loop_demo.gif in your Downloads folder.
- The real finished example is PR #2 in aimclear/TimothyEastvold. Open it and walk the Files changed and Conversation tabs.
- Don't debug live for more than 30 seconds. Switch to the backup and keep the timing.
Likely questions
- "What if I pick the wrong branch?" Nothing breaks. Your change sits on a branch until someone merges it, and a PR can be closed without merging.
- "Can I undo a merge?" Yes. A merged PR has a Revert button, which opens a new PR that takes the change back out. The history keeps both.
- "Who should I ask to review?" Someone on the dev team. Add a note on what the script is for and request a dev team reviewer.
- "Do I have to write a description?" One line on what changed and why is enough. It's for the reviewer and for you in six months.
Done when
Everyone has seen every button they'll need in the hands-on, and the three guardrails have names.