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:
- You can put a file into an AIMCLEAR repo and open a pull request from the browser
- You can review somebody else's pull request
- You know what never goes into GitHub
- You know Claude can do all of this for you once you get how it works
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)
- The team can find it. Your work lives in your own project folder in AIMCLEAR's GitHub, so the people you work with can find it and use it.
- It can be audited. Nobody can reasonably go through everyone's laptops hunting for everything people have built to check it for safety. Put the stuff you've built with AI in your own project folder in AIMCLEAR's GitHub, and it can actually be audited for security and safety.
- A second set of eyes. Someone on the dev team can see exactly which lines changed in a script. It isn't a new approval step, it's help when you want it.
- Keys get caught. An automatic check looks at everything you add and flags API keys and passwords before they end up in the main copy.
- You can see what changed. Every version is kept, with who changed what and why. Drive and Box will tell you a file changed, but not what changed inside a script.
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:
- Tour the repo (github.com/aimclear/github-practice): files, the README, who changed what last
- Open a file and hit History to see every version of it
- Edit it with the pencil icon
- Commit changes..., write a short note, choose "Create a new branch for this commit and start a pull request", type the branch name, then Propose changes
- Create pull request with a short description, then pick a reviewer from Reviewers (gear icon, right side)
- Files changed tab: red is what came out, green is what went in
- Leave a comment on a line. A dev team helper approves the demo PR, so there's no switching to a second account. If a line comment needs resolving, resolve it, then merge
- Add file, then Upload files, for something that already lives on your laptop
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.
- 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.
- Add file > Create new file. Name it
people/firstname-lastinitial.md, likepeople/laura-w.md. We have two Lauras, two Joes, and Tim H plus Timothy, so the last initial matters. - Three lines: your name, your team, and one script or AI tool you've built or want to build.
- Commit changes..., choose "Create a new branch for this commit and start a pull request", and name the branch
add-firstname-lastinitial, likeadd-laura-w. Then Propose changes. - Create pull request, then use Reviewers (gear icon, right side) to pick your partner.
- 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.
- 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:
- Passwords, API keys, tokens. Use a placeholder like
YOUR_API_KEY_HERE. Real keys go in LastPass, or ask the dev team where they belong. - Client data. Exports, customer lists, emails, ad account data. Test with dummy data, like the alias account from the governance meeting.
- Personal stuff. Your own logins, or private details about someone, like HR, health or home addresses. Notes on client work are fine.
If you commit a secret anyway:
- Tell the dev team right away. Nobody's going to be mad, we just need to move fast. It happens, we've all done it. We fix it and move on.
- Deleting the file doesn't fix it. Git keeps every version, so the key has to be rotated (the old key gets turned off and a new one is made).
Where things go:
- Owner: AIMCLEAR, not your personal account. Stuff on laptops can't be audited, but stuff in the org can. It also means the team can find it.
- Visibility: Private. Public means anyone on the internet can read it, so nothing gets flipped to public without asking first.
- What goes in is your stuff, the stuff you built with AI. Don't download something you found online and run it. New tools get approved first, per the new software policy.
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.
- 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.
- Make a branch first, from Current Branch > New Branch.
- Work like you normally do. When you come back to Desktop, the Changes tab shows exactly what's different, red out and green in.
- Write a short summary, Commit, then Push origin. Origin just means the copy on GitHub.
- 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:
- "Save this script to my repo on a new branch and open a PR for review."
- "Before you commit anything, check it for API keys, passwords or client data."
- "Write a README for this: what it does, how to run it, who owns it."
- "What changed in this repo since last week?"
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)
- If you've built it and you might use it again, it goes in AIMCLEAR's GitHub.
- Your homework: hit Use this template on github.com/aimclear/employee-repo-template, make your own repo under AIMCLEAR (Create a new repository, Owner AIMCLEAR, Private), and move everything you've built that you still use into it by [date].
- What else exists, no deep dive: Actions are automatic checks, like Gitleaks checking every push. Branch protection is why main wouldn't take a direct edit in the demo. The template brings the Gitleaks check, and an org rule protects main.
- Stuck? Email me at timothy@aimclear.com, or grab anyone on the dev team. I'm happy to field them. No question is too basic. Anyone who wants the command line, or help getting Claude Code working with GitHub, grab time with me.
- Open floor.
Prep before Thursday
- Everyone has a GitHub account, accepted the AIMCLEAR org invite, has 2FA on, and knows to sign in with that invited account on Thursday. Skip this and the hands-on turns into 15 minutes of password resets.
- Make the practice repo, github.com/aimclear/github-practice: README, a
people/folder with a placeholder file in it (Git can't hold empty folders), the Gitleaks workflow, and write access for everyone attending. - Confirm github.com/aimclear/employee-repo-template has Template repository turned on, the Gitleaks workflow, and a placeholder file in
scripts/. A template copies files and branches only, not settings, branch protection, secrets or collaborators, so main's protection comes from the AIMCLEAR org rule the dev team sets up. - Real scripts go in each person's own repo under the AIMCLEAR org. Make sure members can create repos there, or set them up ahead of time.
- Pick the deadline for moving existing scripts in.
- GitHub Desktop is a slide walk only, no live demo, so there's nothing to install for the session.
- Line up a helper or two for the Meet chat, and one dev team helper to approve the demo PR.
- Slides: the 17-slide Get to Know GitHub deck.
- Record a Claude PR ahead of time for section 7.
- Record it for anyone who's out.
After the session
- Post the recording link in the Meet chat follow-up and with the homework.
- Clean up the practice repo: merge or close every open training PR and delete the add-firstname-lastinitial branches.
- Keep the people/ files if you want a roster of who's been through it, or clear them (keep the placeholder file) so the practice repo starts clean.
- Check employee-repo-template still has the Gitleaks workflow and Template repository is still on.
- Close the demo PR and delete its branch if it was only for the session.
Cheat sheet (handout)
- Repo: the project, with every version
- Branch: your workspace
- Commit: a saved version with a note
- Pull request: ask for review before it goes live
- Main: what's live
- Never commit: keys and passwords, client data, personal stuff
- Committed a secret? Tell the dev team right away
- Always: AIMCLEAR org, private, a README on every script
- Or just tell Claude what you're trying to do