If You Want to Ride the Horse, You Need to Speak Its Language: A Non-Engineer's Survival Guide to Git and GitHub

I know, I know. This post is a bit nerdy. But it’s necessary.

Especially if you’re working with a lot of LLMs lately — Claude Code, Cursor, Lovable, Codex, whatever — and you keep bumping into words like commit, push, branch, PR, and you nod along pretending you know what’s going on. I’ve been there. Half the people I talk to are there.

So today I’m putting on the nerd t-shirt. With the pocket protector. The whole costume.

Because here’s the thing: if you want to ride a horse, you need to know its language. And the language of this whole AI-coding world — the place where your code actually lives — is Git and GitHub.

Why You Even Care About This (If You’re Not a Developer)

Let me be clear: I’m not writing this for engineers. They already know.

I’m writing this for the product people, the founders, the marketers, the curious folks who started doing some “vibe coding” with Lovable or Cursor or Claude Code and now realize there’s a whole machinery behind the cute chat window.

Here’s the simple mental model:

• GitHub is basically the place — the repository — where your code lives in the cloud
• That repository is connected to something like Amplify, Vercel, Netlify, or whatever else, that takes your code and ships it to the world
• Every time you (or your AI agent) saves a meaningful change, that change goes through Git — the system that tracks everything

So when your LLM tells you “I committed the changes” or “I’ll open a PR” — that’s not random jargon. That’s the actual workflow. And if you don’t know what those words mean, you’re trusting a black box. Which, by the way, is fine for a while. Until it isn’t.

The 3 Words You Probably Already Know

If you’ve used any AI coding tool for more than 10 minutes, you already met these three:

• commit — a snapshot of your files at one moment in time, with a message and an author. Like saving your game, but with notes
• push — uploads your commits to the remote (GitHub). “Send what I did to the cloud”
• merge — joins two branches together. Combines two parallel lines of work into one

If you understand these three, you’re already 30% there. Now let me give you the other 15 that will make the rest of the conversations stop feeling like Klingon.

The Other 15 (The Glossary That Actually Matters)

I’ll give them in a logical order — not alphabetical — so the picture builds up naturally.

The “where things live” words

• repository (repo) — the project folder, but tracked by git. Every change is recorded. Forever (more or less).
• working tree (or “working copy”) — the actual files you see in your editor. The physical files on your disk right now.
• staging area (or “index”) — the waiting room between your working tree and your next commit. You “stage” the files you want to include with git add.
• HEAD — a pointer to “where you are right now” in the history. The current commit you’re sitting on.
• branch — a separate line of development. Like a parallel copy of your project where you can work without disturbing anyone else. Most projects have a main branch (the official one) and many feature branches.

The “talking to GitHub” words

• remote — a git server that holds a copy of your repo. Usually GitHub.
• origin — the conventional name for your main remote. When someone says “push to origin,” they mean “push to the GitHub copy.”
• fetch — downloads info from the remote but does NOT touch your files. Just an FYI download.
• pull — fetch + merge. Downloads and applies changes to your local files.
• clone — downloads a whole repo from a remote, the very first time. After this, you have a local copy.
• fork — makes a copy of a repo under your own GitHub account. Typical for open source contributions.

The “things go wrong / things get fancy” words

• rebase — like merge, but it rewrites your commits as if they happened after the other branch. Result: a cleaner, linear history. Powerful, but can bite you if used wrong.
• conflict — when git can’t decide between two changes on the same line. You have to resolve it manually. Annoying. Normal.
• stash — temporarily hides your uncommitted changes so your working tree is clean. You bring them back with pop. Lifesaver when you need to “just check something quickly.”
• squash — compresses multiple commits into a single one. Very common at PR merge time: “squash merge” = your branch’s 12 messy commits become 1 clean commit on main.
• tag — a permanent label on a specific commit. Usually used for releases (v1.0.0, v2.3.1).
• cherry-pick — grabs one specific commit from a branch and applies it to another. Surgical. Useful when you only want one change, not the whole branch.

The “humans need to talk about this” word

• PR / Pull Request — a GitHub request to merge one branch into another. This is where code review happens — your teammates (or your AI) check the changes before they go in.

And one more: gh vs git

This trips up everyone:

• git — the version control system itself. Everything that lives locally on your machine.
• gh — the official GitHub CLI. Everything that lives on GitHub.com — pull requests, issues, releases, auth.

So: git commit (local), gh pr create (GitHub). Different tools, complementary jobs.

The Typical Workflow (How These Words Actually Connect)

Here’s how a normal flow looks. This is the picture worth printing out:

[Working tree]   ← you (or your AI) make changes
     ↓ git add <file>
[Staging area]   ← changes prepared for snapshot
     ↓ git commit
[Local branch]   ← snapshot history on your disk
     ↓ git push
[Remote branch]  ← history on GitHub
     ↓ open PR (gh pr create)
[Pull Request]   ← review + automated checks (CI)
     ↓ merge
[Main branch]    ← official project history
     ↓ (auto-deploy via Amplify / Vercel / Netlify)
[Production]     ← your users see it

That’s it. That’s the whole loop most teams live in. Once you internalize this, 90% of what your LLM tells you suddenly makes sense.

A Real Example: You’re Vibe Coding a Landing Page

Let’s say you’re using Cursor or Claude Code to build a landing page for your new product. You’re not a developer. You’re just describing what you want.

Here’s what’s happening under the hood, translated:

1. You start a new repo on GitHub (gh repo create my-landing-page)
2. You clone it locally (git clone ...)
3. The AI generates the code. The files appear in your working tree
4. The AI runs git add . → files go to staging
5. The AI runs git commit -m "Add hero section" → snapshot saved
6. The AI runs git push → snapshot goes to GitHub
7. Vercel (or Amplify) sees the push, builds the site, deploys it
8. You go check the URL. It’s live.

Now you say “change the headline.” The AI repeats steps 3 → 7. New version live.

Now imagine you want to try a risky change without breaking the live site:

1. The AI creates a branch: git checkout -b experiment-new-design
2. It makes changes there. Commits there. Pushes there.
3. Your main branch (the live one) is untouched
4. You preview the experiment branch on Vercel (it gives you a preview URL automatically)
5. You like it? Open a PR, merge into main → live
6. You hate it? Delete the branch. Nothing on the live site changed. Zero risk.

This is the magic. Branches are how you experiment without consequences.

The Commands You’ll Actually Type (Or Read in AI Output)

Not all of them. Just the essentials. The ones you’ll see every day:

# Get a project
git clone <url>

# See what's going on
git status                       # what changed?
git log --oneline                # recent commits
git diff                         # what's different right now?

# Save your work
git add <file>                   # stage a specific file
git add .                        # stage everything
git commit -m "your message"     # snapshot

# Sync with GitHub
git pull                         # get latest changes
git push                         # send your changes

# Branches
git checkout -b new-branch       # create + switch to a branch
git checkout main                # switch back to main
git branch                       # list branches

# When things break
git stash                        # hide uncommitted changes
git stash pop                    # bring them back
git reset --hard HEAD            # nuke all local changes (careful!)

# GitHub-side stuff
gh pr create                     # open a pull request
gh pr view                       # check a PR
gh repo view --web               # open the repo in your browser

That’s it. Like 15 commands. Once you recognize these in your AI’s output, you stop being a passenger and start being a co-pilot.

Why This Actually Matters (The Honest Reason)

Here’s the deeper point. When you work with LLMs on real projects — not just one-shot prompts but ongoing work — you’ll inevitably hit moments like:

• “Wait, why did the AI overwrite my changes?”
• “Where did the previous version go?”
• “Why is the live site broken? I didn’t change anything!”
• “The AI says the PR is ready — what do I check?”

If you don’t speak Git, every one of these moments becomes panic. If you do — even just the basics — they become debug-able.

And here’s the bigger picture: AI agents are getting better at autonomous coding. They’ll create branches, open PRs, request reviews, merge. You won’t have to do any of it yourself. But you’ll still need to understand what they did. Otherwise, you’re just clicking “approve” on things you don’t grasp. Which is exactly how things break.

Quick PSA

Yes, “work in three” sounds like “working tree.” But it has nothing to do with the number three. Just the working folder (“the tree of files you’re working on”). I lost embarrassing amounts of time being confused about this. Don’t be me.

Closing Thought

I’m not asking you to become a Git wizard. I’m not even asking you to use the command line if you don’t want to (GitHub Desktop and the buttons inside Cursor / VS Code work just fine).

I’m asking you to learn the vocabulary. 18 words. One workflow diagram. 15 commands.

That’s the cost of being able to ride the horse — instead of being the passenger praying it doesn’t run off a cliff.

Because in this AI era, the people who understand the plumbing under the magic will move differently than the people who just type prompts and hope.

Don’t be the second kind.