Get to Know GitHub: Outline

Thursday, Oct 29, 12:00 to 1:00 PM CT on Google Meet. Alyssa sent the invite to everyone@.

Section docs: 1 Why · 2 Google Docs map · 3 Live loop · 4 Hands-on · 5 What stays out · 6 GitHub Desktop · 7 Claude · 8 Wrap-up

Why we're doing this

This came out of the AI/Software Governance meeting on Oct 7. Most of us are building scripts, little HTML tools and prompt files with ChatGPT and Claude now, and almost all of it lives on somebody's laptop. Laura's ask was pretty simple: show everyone how GitHub works, then make it where that stuff goes.

Nobody here needs to become a developer. You already work in systems with drafts, versions, approvals and rollbacks every day. GitHub is the same idea, just for files.

What I want everyone walking out with:

Not covering: the command line, Actions or deployments. If you want any of that, grab me for a 1:1.

Run of show (60 minutes)

Time What How
0:00 to 0:02 Join buffer Ask "where does your work live right now?" in chat while people join
0:02 to 0:06 Why we're doing this Me talking
0:06 to 0:13 How GitHub maps to stuff you already do Me talking, slides
0:13 to 0:22 The whole loop in the browser Screen share. A dev team helper approves the demo PR
0:22 to 0:37 Everyone opens a pull request Hands-on, in pairs. Re-post pairs at 0:22, hard stop at 0:37
0:37 to 0:43 What stays out of GitHub Me talking
0:43 to 0:45 GitHub Desktop Slide walk only, no live demo
0:45 to 0:50 Letting Claude drive Pre-recorded Claude PR, live if time allows
0:50 to 0:54 The rule, homework and help Me talking
0:54 to 1:00 Q&A Open floor

1. Why we're doing this (4 min)

Laptops are already backed up, so this isn't about losing files.

The rule from leadership: if you've built it and you might use it again, it goes in AIMCLEAR's GitHub.

2. How GitHub maps to stuff you already do (7 min)

Start with two problems everyone has had. Last save wins: two people edit the same file and whoever saves last wipes out the other person's work. And which version is this: campaign_brief_v2_REAL_final.docx. GitHub fixes both. Every version is kept with a note on what changed, and nobody overwrites anybody, because changes come in through a pull request.

If you've worked in Google Docs, you already get most of this.

GitHub What it's like
Repository (repo) A shared Drive folder for one project, with every version kept.
Branch Making a copy to work in, so the original stays untouched.
Commit A named version in version history, with a note on what changed. Small and often beats one giant save at the end.
Pull request (PR) Suggesting mode. You're asking to merge your branch into main, and someone sees exactly what changed before it's accepted.
Review An approval round. Comments on specific lines, then approve or ask for changes.
Merge Accepting the suggestions. Your changes are now in main.
Main The approved, final version. On AIMCLEAR's repos, an org rule protects main, so changes come in through a pull request.
Issue A ticket that lives with the code. Basically a ClickUp task stuck to the repo.

One slide to close it out: 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.

3. The whole loop in the browser (9 min)

I'll share my screen in the practice repo and run the loop once. As I click each step, I'll name it out loud (that's the branch, that's the commit) so the words from the Google Docs slides land on something real:

4. Everyone opens a pull request (15 min)

Pairs get posted in the Meet chat before we start, and again at 0:22. A couple of dev team folks hang out in the chat for anyone who gets stuck. Hard stop at 0:37.

  1. Open the shared practice repo, github.com/aimclear/github-practice (link in chat). It's one repo for everyone, so pairs can review each other's PRs. Your own repo comes after.
  2. Add file > Create new file. Name it people/firstname-lastinitial.md, like people/laura-w.md. We have two Lauras, two Joes, and Tim H plus Timothy, so the last initial matters.
  3. Three lines: your name, your team, and one script or AI tool you've built or want to build.
  4. Commit changes..., choose "Create a new branch for this commit and start a pull request", and name the branch add-firstname-lastinitial, like add-laura-w. Then Propose changes.
  5. Create pull request, then use Reviewers (gear icon, right side) to pick your partner.
  6. Review your partner's PR as practice: Files changed > Submit review (older layout: Review changes). Leave one comment, pick Approve, then Submit review. Approve only, and don't click Merge.
  7. I'll merge a few live so everyone sees it land. If a line comment needs resolving before merge, I'll resolve it, then merge.

If someone can't get into the repo, their partner shares their screen and drives, and they follow along. Everyone needs to be signed in to the GitHub account that was invited to AIMCLEAR. If a pair needs to talk, use a 1:1 Meet link. No breakout rooms, since they need host setup and aren't recorded.

Common snags (the 4 Hands-on doc has the fixes): branch name already exists (add your last initial, or another letter), can't find Propose changes, a 2FA prompt, and Gitleaks check pending or Waiting for a runner (keep going, I merge after).

Done early? Make your own repo from github.com/aimclear/employee-repo-template: hit Use this template > Create a new repository, set Owner to AIMCLEAR, and pick Private. Then upload a script from your laptop that you've already checked for keys into scripts/ on a new branch and open a PR for it. The template brings the Gitleaks check along. It runs on GitHub for every push, browser uploads included, and flags keys before anything gets merged into main. A flagged key has already left your laptop and still needs rotating (the old key gets turned off and a new one is made), so stop and tell the dev team.

5. What stays out of GitHub (6 min)

Never commit:

If you commit a secret anyway:

Where things go:

6. GitHub Desktop (2 min)

If you'd rather not do this in the browser, GitHub Desktop is the same loop as an app on your laptop, for Windows or Mac. This part is a slide walk only, no live demo.

  1. Update GitHub Desktop to 3.5.5 or newer (that's what supports commit hooks), sign in with your GitHub account, and clone your repo. It shows up as a normal folder you can open and save into.
  2. Make a branch first, from Current Branch > New Branch.
  3. Work like you normally do. When you come back to Desktop, the Changes tab shows exactly what's different, red out and green in.
  4. Write a short summary, Commit, then Push origin. Origin just means the copy on GitHub.
  5. Preview Pull Request, then it's the same review and merge we just did.

Gitleaks runs on GitHub for every push, browser uploads included. If it's also set up on your laptop, it runs every time you commit from Desktop and catches a key before it leaves your machine. That hook needs setting up on each laptop (the template can't do it), and the dev team can help. Desktop has a Bypass Commit Hooks option. Don't use it. This is also what Claude Desktop and Claude Code are doing under the hood, which is next.

7. Letting Claude drive (5 min)

Most of you are in Claude Desktop or Claude Code every day already, and that's probably how a lot of this will actually happen. Claude knows how to do every step we just did: branches, commits, PRs, all of it. What it needs from you is what you're aiming for.

Stuff you can just say:

Demo: show a pre-recorded Claude PR (I handed Claude a script and the first prompt), then look at the PR it opened together. Running it live is a bonus if time allows.

Why we did it by hand first: it helps to know what Claude is doing for you. Claude opens the pull request. Add a note on what the script is for, and someone on the dev team will review it. You don't need to judge the code yourself. If Claude can't reach GitHub from your machine, ping me and we'll get you set up.

8. The rule, and questions (4 min, then Q&A to 1:00)

Prep before Thursday

After the session

Cheat sheet (handout)