The one idea

Think of it as a time machine for your files

Every change you record is a snapshot — saved with a note about what you did and why. You can rewind to any moment, compare two versions, or undo a mistake without ever losing your work. GitHub is just where you keep a shared, online copy so other people can see it too.

The basics

A repo

Your project folder — except it quietly remembers itself. It's all the files in a project plus every past version of each one. When someone grabs a copy, they get the files and the whole history.

The basics

A commit

One saved snapshot of your work, with a one-line caption. You don't commit every tiny tweak — you commit at moments that make sense, like “finished the intro.”

git commit -m “finished the intro”

The basics

A branch

A “what-if” side track. You work your changes there, out of the way. If it works out, you roll it back into the main line. If not, you delete the track and try another — the real thing was never touched.

The basics

main

The official, current-best version of the project. Branches are your side experiments; main is where the good stuff finally lands. (Older projects may call it “master.”)

Two copies

Your computer ⇄ GitHub

Your computer (local)

Your complete private copy — full history included, and it works offline. This is where you edit and take your snapshots.

▲ push · upload ▼ pull · download

GitHub (remote)

The shared, online copy — a public album anyone you allow can see. You upload snapshots here; others download them.

Housekeeping · set up before step 1

The bouncer — .gitignore

A tiny file at the top of your project folder. Each line is a rule saying “don't record this in any snapshot.” You set it up once, and every commit after honors it.

Why bother?

Keep secrets out — passwords and API keys never ride up to GitHub.
Skip huge folders that get rebuilt — dependencies, build output.
Leave out personal junk that only makes sense on your own machine.

A few patterns you'll actually use

.envYour secrets — API keys, database passwords

node_modules/A JavaScript dependency folder (huge, rebuilt each time)

*.logAny file ending in a “.log”

.DS_StoreInvisible Finder metadata (macOS)

build/ dist/Compiled output — made fresh on every build

!important.txtThe rare “un-ignore” — include one file you'd said to skip

Make one in 10 seconds

touch .gitignore

then

echo ".env" >> .gitignore

That creates the file, then writes a rule on its own line — add as many as you want. Or without a terminal: make a blank file called .gitignore in the folder and type one pattern per line.

One file, one line per rule, at the top of the project — that's it.

Your first run · start here

The whole thing — from an empty folder to GitHub

1

Turn this folder into a repo

You're already inside the project folder. One command, once.

git init

2

Start a branch, so you're not working on main yet

“draft” is a fine name — anything works.

git switch -c draft

3

Make your changes

Just edit your files like always. Git is watching quietly in the background.

4

Record a snapshot with a one-line note

“add, then commit” — that's the whole recording ritual.

git add . → git commit -m "first pass"

5

Send it up to GitHub

Only the first time: connect GitHub first with git remote add origin <url>. After that, a bare git push just works.

git push

That's the entire first run — after this, work is just a repeat loop.

Cheat sheet

The commands you'll actually use

git initTurn a normal folder into a repo (do once, at the start)

git statusWhere am I and what has changed? Your best friend.

git add .Choose all current changes for the next snapshot

git commit -m “my note”Take the snapshot and attach your message

git branchList your side tracks (you should see main)

git switch -c my-featureStart a new branch and jump on it

git switch mainJump back to the main timeline

git pushUpload your snapshots to GitHub

git fetchPeek at what's new on GitHub — leaves your work alone

git pullGrab what's new from GitHub and fold it into your work

git clone <URL>Download someone's whole repo (files + history) locally

git help <command>Built-in help for any command above

The save ritual

Recording work, in 3 moves

1edit your filesJust do normal work — no Git needed.

2git add .Put the changed files on a tray for the next snapshot.

3git commit -m “what I did”Take the photo, caption it, file it in the history.

add decides what's in the shot · commit takes it

The daily loop

A typical day, in order

●
git status — check where you are
●
make your edits
●
git add . then git commit — record a snapshot
●
git push — send it up to GitHub
●
Before editing more, git pull to catch anyone else's changes

status · add · commit · push → your muscle memory

Don't panic

You can't lose work

Git keeps every commit around. Deleted a file? Bad typo? “Let me just undo that” is usually one step away — git status tells you exactly where you are.

✓ The scariest Git command is still less final than a normal “Save”.

Translation

Git words → plain English

repoyour project folder, with a memory of every version

commita snapshot plus a note about what you did

brancha side-track experiment you can toss or merge

pushupload my snapshots to GitHub

pulldownload new snapshots from GitHub into mine

clonedownload a whole repo onto my computer