GitHub Primer for Dummies

What is Git? (The 10-second version)

Git is just save points for code.

Like save points in a video game. You can experiment safely because you can always load your last save.

The Google Docs mental model

You already know this.

In Google Docs, click File > Version history > See version history and you see:

• 2:01 PM — "added intro"
• 2:10 PM — "fixed typo"
• 2:30 PM — "rewrote ending"

You can click any version and restore it.

That is basically Git.

Why Git exists

Without Git, you end up with files named:

final_final_REALfinal_v7.html

With Git, you click history, go back, done.

What is GitHub?

GitHub is a website that stores your Git-tracked files in the cloud. Think of it like Google Drive but with that version history built in and way more powerful.

Git = the tracking system (runs on your computer) GitHub = the website that hosts your tracked files (in the cloud)

Why do you need it?

1. Backup — If your server dies, your files are safe on GitHub
2. History — Made a mistake? Roll back to any previous version
3. Automation — GitHub Actions automatically deploys changes to your server when you push

For OpenClaw specifically: you edit your agent's personality on your laptop, push to GitHub, and GitHub Actions automatically uploads it to your server. No SSH required.

Key vocabulary (5-year-old version)

Branching: Make a copy before you experiment

The game save slot analogy

You're playing a game. You have a save file:

Save 1 — Boss fight coming

Before you try something risky, you create:

Save 2 — try risky strategy

Now you can:

• Try crazy stuff
• If you win — keep Save 2
• If you die — load Save 1

You never risk your main progress.

That is branching.

The real-world version

You have a working website your company depends on. You want to try dark mode.

Why the Google Docs idea breaks down here

In Google Docs, everyone edits the same document at once. But in software, that would be chaos.

Developers need parallel universes of the project. Branching = parallel universes.

One-liner

Branching is making a safe copy to try changes without breaking the real thing.

Pull Requests: How a bill becomes a law

This is the analogy that makes the entire Git workflow click. It's not a metaphor — it's structurally the same process.

The repo = The law of the country

There is an official body of laws that everyone follows. Stable. Official. Public.

This = main branch

You cannot casually edit the law.

Someone wants to change the law (create a branch)

A politician has an idea: "We should add a new law about recycling."

They don't edit the official law directly. They write a proposed change called a bill.

This bill is a copy of the law with proposed edits.

This = branch

Multiple people can propose different bills at the same time. Parallel changes. Independent work.

They revise the bill (commits)

While working on the bill, it gets revised:

• Version 1: initial draft
• Version 2: added funding section
• Version 3: fixed wording

Each revision is recorded.

These = commits

Submit for review (Pull Request)

The politician submits the bill to Congress:

"Here are my proposed changes to the law."

That submission is literally called a proposal.

This = Pull Request (PR)

Discussion and review (code review)

Now the process becomes very GitHub-like:

• Committees review it
• People debate
• Comments are made
• Changes are requested
• Edits happen again

A bill can go through many revisions before approval. Exactly like PR feedback loops.

Approval = becomes law (merge)

If enough people approve, the bill becomes part of the official law.

This = merge into main

The official "production version" changes.

Rejection = proposal dies (delete branch)

If the bill fails, it disappears. The law stays unchanged.

This = branch deleted

The clean mapping

Why PRs exist (the real reason)

Without pull requests, chaos happens:

• Bugs get merged
• Code breaks
• Nobody knows what changed
• Someone accidentally deletes production

PRs add: review, discussion, safety, accountability, team awareness.

They are less about Git and more about team communication.

GitHub is not just a tool. It's a governance system for changes.

The best one-line explanation

GitHub works like how new laws get proposed and approved.

The whole Git workflow in one story

1. Save your work — Commit
2. Make a safe copy to experiment — Branch
3. Ask team to review your changes — Pull Request
4. Replace the real version — Merge

Git saves your work. Branches let you experiment safely. Pull Requests let teams approve changes before they become official.

And now you understand like 90% of real GitHub.

Setting up Git for the first time

1. Install Git

Mac: Already installed. Verify:

git --version

Windows: Download from git-scm.com and install with all defaults.

2. Tell Git who you are

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

This stamps your name on every commit, like signing your work.

3. Create a GitHub account

1. Go to github.com and sign up
2. Pick a username (you'll use this a lot, make it professional-ish)
3. Verify your email

The 4-step workflow (this is 90% of what you'll ever do)

1. EDIT    ─── Change a file on your laptop
2. ADD     ─── Tell Git "include this in my next save"
3. COMMIT  ─── Take the snapshot with a note
4. PUSH    ─── Upload to GitHub

In actual commands:

# 1. Edit the file (use any editor — VS Code, nano, TextEdit, whatever)
#    Let's say you edited agent/workspace/SOUL.md

# 2. Stage the changes
git add agent/workspace/SOUL.md

# 3. Take the snapshot with a description
git commit -m "Updated personality to be more friendly"

# 4. Upload to GitHub
git push

That's it. Four commands. Everything else is extra.

Starting from scratch: your first repo

Option A: Fork an existing repo (recommended for OpenClaw)

1. Go to github.com/jdanjohnson/Openclaw-AI-Assistant-Project
2. Click Fork (top right corner)
3. This creates YOUR copy at github.com/YOUR-USERNAME/Openclaw-AI-Assistant-Project

Then download it to your laptop:

git clone https://github.com/YOUR-USERNAME/Openclaw-AI-Assistant-Project.git
cd Openclaw-AI-Assistant-Project

Option B: Create a new repo from scratch

1. Go to github.com/new
2. Name it (e.g., my-ai-assistant)
3. Check "Add a README file"
4. Click Create repository

Then download it:

git clone https://github.com/YOUR-USERNAME/my-ai-assistant.git
cd my-ai-assistant

Checking what's happening

These are your dashboard commands. Use them constantly.

git status — What changed?

git status

Output:

On branch main
Changes not staged for commit:
  modified:   agent/workspace/SOUL.md

Untracked files:
  agent/workspace/skills/new-skill.md

Red files = changed but not yet staged Green files = staged and ready to commit Untracked = brand new files Git doesn't know about yet

git log — Show version history

git log --oneline

Output:

a3f7c2d Updated personality to be more friendly
b8e1a9f Added heartbeat configuration
c2d4e6f Initial setup

Each line is a commit (save point). The weird letters are the commit ID. The message is what you wrote.

git diff — What exactly changed?

git diff

Shows you line-by-line what you added (green +) and removed (red -). Like tracked changes in Word.

Branches in practice

Create a branch (make a new save slot)

git checkout -b try-new-personality

Now you're on "try-new-personality" branch. Everything you do here is separate from "main."

Do your work, then create a PR

git add agent/workspace/SOUL.md
git commit -m "Experimenting with a more casual personality"
git push -u origin try-new-personality

Then on GitHub:

1. Click the yellow "Compare & pull request" banner
2. Add a description of what you changed and why
3. Click Create pull request
4. Get feedback, make more changes if needed
5. When approved: Merge pull request

This is the bill-becomes-law process in action.

Working with AI agents on branches

This is the real power move. Instead of doing everything yourself:

Main branch (the current law)
  |
  |-- branch: jules/fix-security-todo
  |   Jules found and fixed a TODO comment
  |
  |-- branch: gemini/add-scheduling-skill
  |   Gemini wrote a new skill for calendar management
  |
  |-- branch: devin/update-heartbeat-config
      Devin updated the heartbeat timing

Each agent works on its own branch (writes their own bill). You review their PRs (debate in committee). Merge what looks good (pass into law). Reject what doesn't (kill the bill).

How to give an agent a task

1. Create a branch: git checkout -b agent-name/task-description
2. Push it: git push -u origin agent-name/task-description
3. Give the agent the branch name and task description
4. The agent pushes commits to that branch
5. You review the PR on GitHub
6. Merge or request changes

Scope each task clearly. Tell the agent exactly which files to touch and what "done" looks like. This prevents agents from stepping on each other's work.

The .gitignore file

Some files should NEVER go to GitHub — like secrets and runtime data.

Create a .gitignore file in your repo root:

# Secrets - NEVER commit these
.env
credentials/
*.key

# Runtime data
workspace/memory/
workspace/knowledge/
agents/

# OS junk
.DS_Store
Thumbs.db

# Dependencies
node_modules/

Every line is a pattern. Git pretends those files don't exist.

Using GitHub from VS Code (no terminal needed)

If you'd rather click than type:

1. Open your repo folder in VS Code
2. Click the Source Control icon on the left sidebar (branch icon)
3. Changed files appear listed
4. Click + next to a file to stage it (same as git add)
5. Type a message in the box at the top
6. Click the checkmark to commit
7. Click ... > Push to upload

VS Code also shows diffs inline — green for additions, red for deletions.

Common situations and what to do

"I made a mess and want to start over"

git checkout .

Undoes ALL uncommitted changes. No undo on this one — be sure.

"I want to see what a file looked like before"

git log --oneline                         # Find the commit ID
git show abc1234:agent/workspace/SOUL.md  # View the file at that point in time

"I pushed something I shouldn't have"

git revert HEAD
git push

Makes a NEW commit that undoes the bad one. Safe. Preserves history.

Never try to delete history. Just add a new commit that fixes it.

"Git says there's a conflict"

This happens when two people (or an agent and you) changed the same lines:

<<<<<<< HEAD
Your version of the text
=======
The other version of the text
>>>>>>> branch-name

Open the file, decide which version to keep (or combine them), remove the markers, then:

git add the-file.md
git commit -m "Resolved merge conflict"

"I forgot what branch I'm on"

git branch

The * marks your current branch.

GitHub Actions (the auto-deploy robot)

GitHub Actions are scripts that run automatically when something happens in your repo.

For OpenClaw, the action runs when you push to main:

You push to main
      |
      v
GitHub Actions starts
      |
      v
Downloads your latest files
      |
      v
SSHs into your DigitalOcean droplet
      |
      v
Copies only the changed config files
      |
      v
Restarts OpenClaw
      |
      v
Your agent has the new personality / skills

You can watch it run:

1. Go to your repo on GitHub
2. Click the Actions tab
3. Click the latest workflow run
4. Watch the logs in real-time

If something fails, the logs tell you exactly what went wrong.

Security rules for GitHub

1. Never commit API keys, passwords, or secrets — Use GitHub Secrets instead
2. Never commit .env files — Add .env to .gitignore
3. Review PRs before merging — Especially from AI agents
4. Enable branch protection on main (Settings > Branches > Add rule):
   • Require pull request reviews before merging
   • Require status checks to pass
5. Use GitHub Secrets for sensitive values (Settings > Secrets > Actions)

Cheat sheet (print this out)

DOWNLOAD A REPO       git clone URL
SEE WHAT CHANGED      git status
STAGE A FILE          git add filename
STAGE EVERYTHING      git add -A
TAKE A SNAPSHOT       git commit -m "description"
UPLOAD TO GITHUB      git push
DOWNLOAD LATEST       git pull
SEE HISTORY           git log --oneline
SEE LINE CHANGES      git diff
CREATE A BRANCH       git checkout -b branch-name
SWITCH BRANCHES       git checkout branch-name
LIST BRANCHES         git branch
MERGE A BRANCH        git merge branch-name
UNDO LAST COMMIT      git revert HEAD
WHERE AM I?           git branch (look for the *)

The full summary

Git saves your work. Branches let you experiment safely. Pull Requests let teams approve changes before they become official.

Useful resources

• GitHub Hello World tutorial — official 10-minute intro
• Learn Git Branching — interactive visual tutorial (highly recommended)
• Git cheat sheet (PDF) — print this out

Written by

Ja'dan Johnson

Developer Marketing Manager & Community Architect

Community architect, creative technologist, and ecosystem builder operating at the intersection of technology, culture, and human systems.

TwitterLinkedIn