Two copies, kept in sync.

Git is the tool on your Mac. GitHub is a server in the cloud, plus a website on top of it. Once you see them as two separate things, everything else clicks.

Concept 01 — Git is local. GitHub is remote.

Two tools, same word.

The names look almost identical, which is why this confuses everyone at first. Git (no "Hub") is a program that lives on your Mac. It tracks changes to files in a folder and stores a history of every snapshot you take. It works perfectly fine without an internet connection.

GitHub is a company. They run a server that holds a copy of your project, and they wrap a website around it so you can see files, leave comments, invite collaborators, and review changes from a browser. GitHub uses git under the hood — it's a hosting service for git projects.

The analogy that sticks

Git is Microsoft Word. GitHub is OneDrive.

Word still works without OneDrive — you can edit documents on your laptop forever. OneDrive adds sharing, sync, permissions, and a web UI on top. Same with git and GitHub: git works fine alone; GitHub adds the cloud-shared, browser-accessible, multi-person layer.

YOUR MAC git ~/lab/projects/... a .git folder + your files git push → ← git pull GITHUB'S SERVER github.com lovebuilt/agentic-lab a mirror copy + a web UI Two copies of the same project. Push uploads. Pull downloads.
your repository, in two places at once
Concept 02 — A commit is a snapshot

Every save gets a fingerprint.

A commit is git's word for "save point." Every time you say "commit," git takes a snapshot of every file in the project right now, attaches a message you type, and gives the snapshot a unique 40-character ID called a SHA. The SHA is the fingerprint — no two commits ever share one.

You normally see only the first 7 characters of the SHA. It's enough to be unique. Your AL repo's very first commit was ab39fcd with the message "init: _agentic-lab monorepo bootstrap (AL-2.1)". That's a moment in time, frozen — you can return to exactly that state at any future point.

# What git shows you when you ask for history $ git log --oneline 8545268 AL-2.1: closeout — STATUS flip + SL courtesy note ab39fcd init: _agentic-lab monorepo bootstrap (AL-2.1)
Why the SHA matters

A SHA is not just a label — it's derived from the snapshot itself. If you change one byte of one file in that commit, the SHA changes too. That's how git knows nobody has tampered with history. Any time you see ab39fcd referenced anywhere, you can trust it points to exactly that snapshot.

Concept 03 — A branch is a named pointer

"main" is just a label.

A branch is a name that points to one specific commit. As you add new commits, the branch label automatically moves forward to the newest one. The default branch in every new repo is called main. It's the one place that represents "the official version" — what everyone agrees is the real project.

You can make new branches off of main to try things without disturbing it. A branch named fix/typo-in-readme can hold experimental commits that nobody else sees yet. When you're happy, you ask for those commits to be folded into main. When you're not, you delete the branch — main was never affected.

ab39fcd init 8545268 closeout d2c4a91 next commit main → e7a1f3b fix/typo commits move forward; branches just point at one of them
your AL repo today — main has two commits; a branch could peel off any of them
Concept 04 — push and pull keep them in sync

Upload, download.

Your Mac copy and GitHub's copy don't sync automatically. Each side moves on its own until you tell git to ship updates. git push uploads your local commits to GitHub. git pull downloads commits from GitHub to your local copy.

If you're the only person on the repo, you mostly push. The moment someone else (say, Josh) starts pushing too, you'll pull before you push to grab their changes first — otherwise git stops you with a "your branch is behind" warning and refuses to let you overwrite their work.

# A typical work session $ git pull # grab anything new from GitHub # ... edit some files ... $ git add some-file.md # stage what you changed $ git commit -m "fix typo" # save a snapshot locally $ git push # ship the snapshot to GitHub
The big "why this matters"

Any rule about "what can happen to main" — like "no force-pushes" or "must have a review first" — is enforced when you push. The GitHub server is where the rules live. If GitHub allows the push, your change becomes part of the official history. If GitHub rejects it (because of a rule), your local copy is untouched but the change never reaches the shared version. We'll dig into those rules in Lesson 2.

Concept 05 — Your setup, right now

The AL repo, specifically.

You already have all of this running. The AL-2.1 dispatch set it up on 2026-05-18. Here's where everything lives:

★ Your AL repo today

Two copies. One on disk, one on GitHub.

  • Mac copy · ~/lab/projects/_agentic-lab/
  • GitHub copy · https://github.com/lovebuilt/agentic-lab
  • Visibility · private (only you, for now)
  • Default branch · main
  • First commit · ab39fcdinit: _agentic-lab monorepo bootstrap
  • Most recent · 8545268AL-2.1: closeout — STATUS flip + SL courtesy note

From here on, every lesson is about the rules you can put on that GitHub copy — what to allow, what to block, who gets to do what. That's where the "branch protection" and "GitHub Pro" conversations start.

✦ Lesson 1 recap

What you now know about git vs GitHub…