14. Github
Note: The video covers material not in the guide below — please watch in full.
Action Step
Complete this before moving on.
Do your first commit and push using GitHub Desktop. Go to your personal repo, commit any changes you have, and push them to GitHub. Then create a new file in VS Code called github-test-push.md, save it, commit it in GitHub Desktop, push it, and go to github.com to verify it shows up. Also take a look at the LeanScale organization page to see the team repos there.
Training Guide
In the setup training, you created a folder on your computer — Documents/GitHub/YourName-Repo — and you cloned a bunch of team repos into the same place. You followed the steps, clicked the buttons, and now you've got folders full of files sitting on your machine.
But here's something that might not be obvious: those files are living locally on your computer right now. They're not "in the cloud." They're not automatically syncing anywhere. They're just folders on your hard drive. GitHub is the place they go when you choose to sync them — and understanding that distinction matters.
(Let's start with what GitHub actually is)
What GitHub Is
Think of GitHub as a coder's Google Drive. It's a place in the cloud where files get stored, backed up, and shared with a team. Developers have been using it for decades to manage code — but we're using it for the same reason, just with different types of files.
So why not just use Google Drive? Two reasons:
Speed for the AI. When your files live locally on your computer — right there in Documents/GitHub/ — Claude Code can read, edit, and create files instantly. It's working directly in your file system. If those files lived in Google Drive, the AI would need to connect through an MCP or API (you'll learn what those are in an upcoming training) and pull them down through the network. That eats into your token window (now you know what that is) and slows everything down. Local files = fast AI.
Version control. Google Drive tracks some version history, but GitHub was built for it. Every change you save gets a timestamp, a description, and a full record of what changed. If something breaks or you want to go back to an earlier version, you can. It's like having an unlimited undo history for your entire workspace.
(OK so the files are local — how do they get to GitHub?)
It Doesn't Sync Automatically
This is the part that trips people up. Google Drive, Dropbox, iCloud — those sync automatically. You save a file and it's in the cloud seconds later. GitHub does not work that way.
GitHub was designed for developers. And developers don't want automatic syncing. They need to review their changes, test their code, and decide exactly what gets pushed up and when. They work in branches — parallel versions of the same project — and they merge things together carefully. Automatic sync would be a disaster for that workflow.
For you, it's simpler. You don't need branches. You don't need complex merges. But you do need to understand that your changes stay local until you push them. Nothing goes to the cloud automatically.
And honestly? Most of the time, that's fine. A lot of your day-to-day work will just live locally on your machine — your drafts, your notes, your projects. You don't need to push every time you save a file. You push when you have something to share with the team, or when you want to back up work you don't want to lose.
The more common scenario is actually pulling. Someone on the team updates a shared repo — new playbooks, updated brand guidelines, a new skill. They'll tell you: "Hey, go pull the latest." If you're looking for something in a team repo and it's not there, that's your cue to check if there's an update to pull. And if it's still not there, ask the person to push it so you can pull on your end.
(Here's the tool that makes that easy)
GitHub Desktop — Your Sync Button
GitHub Desktop is the app you downloaded in the setup. It's the visual interface that sits between your local files and GitHub in the cloud. There are other ways to commit and push — the terminal, VS Code extensions, even Claude Code itself — but we recommend GitHub Desktop because it's one of the easiest.
Here's the mental model:
- Your local files (Documents/GitHub/) — this is where you work. Claude Code creates and edits files here.
- GitHub Desktop — this is the bridge. It shows you what changed and lets you sync.
- GitHub (github.com) — this is the cloud. Where your files get backed up, shared, and stored.
The key actions:
- Commit — save a snapshot of your changes with a short description. Think of it as putting a label on what you did. "Updated client brief." "Added new research notes." This doesn't send anything to the cloud yet — it just packages your changes.
- Push — send your commits to GitHub. Now it's in the cloud. Now it's backed up. Now your team can see it.
- Pull — grab the latest changes from GitHub to your local machine. If a teammate pushed something, pulling brings their changes to your computer.
Most of the time you're just working locally. When you need to share something or back it up, you commit and push. When someone tells you there's an update, you pull. We'll walk through this hands-on in a later training — for now, just understand the flow.
(One more thing — let's talk about the repos you cloned)
Your Repo vs Team Repos
In the setup, you cloned several repos — LeanScale Context, Customer Warehouse, Teamwork, Skills and SOPs, and others. You also created your own personal repo (YourName-Repo).
Here's the difference:
Team repos are shared. Everyone on the team can see them, pull from them, and push to them. These contain shared resources — brand guidelines, customer data, project management info, skills and SOPs. When someone updates a team repo, you pull to get the latest version.
Your personal repo is yours. It's where your individual work lives — your notes, your drafts, your projects, your experiments. You push it to GitHub for backup, but it's your workspace.
Think of it like a shared office. The team repos are the shared drives — everyone has access to the same documents. Your personal repo is your desk — your stuff, organized your way, backed up to the cloud.
And here's a detail that matters: they live in different places on GitHub. The team repos live under the LeanScale organization — that's why you had to accept an invite to access them. Your personal repo lives under your own GitHub account. You created it yourself in the setup. If you go to github.com and click your profile, you'll see your repo there. If you go to the LeanScale org page, you'll see all the team repos there.
(Let's put this into practice)
Exercise: Push Your First Change
Let's do this for real. You're going to make a change in your personal repo and push it to GitHub.
- Open VS Code and navigate to your YourName-Repo folder in the sidebar
- Save the file (Command + S)
- Open GitHub Desktop
- Make sure your YourName-Repo is selected in the top-left dropdown
- Click Commit to main
- Click Push origin at the top
Now go to github.com, navigate to your repo, and you should see your change right there. That file went from your computer → to the cloud. That's the whole flow.
See Both Worlds
While you're on GitHub, take a look at where things live:
- Click your profile icon (top right) → Your repositories — you'll see your personal repo here. This is yours.
- Now go to the LeanScale organization page — you'll see the team repos here. LeanScale Context, Customer Warehouse, Skills and SOPs, all of them. These belong to the org.
Two different places. Two different purposes. Team repos for shared work, your repo for your own.
(Next up: how to teach your AI repeatable processes with skills and SOPs)
Comment in Slack
Post your answer in your onboarding channel.
What was your biggest takeaway(s) from this training?