Git and GitHub for Beginners — A Practical Guide

Introduction

Git has a reputation for being confusing, and most of that reputation comes from learning it as a pile of commands instead of as one idea: a time machine for your code. This guide teaches Git the way you'll actually use it — initializing a project, saving checkpoints, experimenting safely with branches, and collaborating through GitHub — using a real project you build as you read.

If you've followed any tutorial on this site, you already have the perfect candidate project to version control.

The Mental Model

Git tracks snapshots, not changes. A commit is a full picture of your project at one moment, plus a pointer to the previous picture. That's it. Everything else — branches, merges, GitHub — is bookkeeping around snapshots:

Repository (repo) — your project folder + its entire history.

Commit — one snapshot with a message explaining it.

Branch — a movable label pointing at a snapshot.

GitHub — a website hosting copies of repos for sharing and backup.

Step 1: Start Tracking a Project

code

cd my-project
git init
git add .
git commit -m "Initial version of my project"

git init creates the hidden .git folder — your time machine's storage. git add . stages everything; git commit saves the snapshot. From here on, you can always get back to this state:

code

git log --oneline        # see your history
git status               # what's changed since the last commit

Step 2: The Daily Workflow

Real Git usage is a three-step loop you'll repeat thousands of times:

code

# 1. Make changes to your files
# 2. Check what changed
git diff
# 3. Save a checkpoint
git add .
git commit -m "Add input validation to the form"

Commit messages are notes to your future self. "Fixed stuff" tells you nothing in six months; "Fix crash when email field is empty" is gold. Commit when you reach a working state — small, frequent checkpoints beat rare giant ones.

Step 3: Branches — Experiment Without Fear

A branch is a parallel timeline. Main stays stable while you try something risky:

code

git switch -c dark-mode      # create and move to a new branch
# ... make changes, commit them ...
git switch main              # back to stable — your experiment vanished (safely stored)
git switch dark-mode         # back to the experiment

When the experiment works, merge it back:

code

git switch main
git merge dark-mode
git branch -d dark-mode      # delete the now-redundant branch

If both branches edited the same lines, Git asks you to resolve a conflict — open the marked file, keep what you want, delete the <<<<<<< markers, and commit. Conflicts aren't errors; they're Git refusing to guess.

Step 4: GitHub — Backup and Collaboration

code

git remote add origin https://github.com/yourname/my-project.git
git push -u origin main

Now your repo lives on GitHub: backed up, shareable, and open for collaboration. The daily rhythm becomes:

code

git pull        # get others' work first
git push        # share yours

Pull requests (PRs) are how teams merge branches: you push a branch, open a PR on GitHub, teammates review and comment, then it merges. Even solo, PRs are worth using — they give you a diff to review before code lands on main.

Step 5: The Recovery Commands You'll Eventually Need

code

git restore file.py           # discard uncommitted changes to a file
git restore --staged file.py  # unstage, keep the changes
git reset --hard HEAD~1       # nuclear: delete last commit AND changes (careful!)
git revert HEAD               # safer: add a new commit that undoes the last one

The golden rule: if commits exist, almost nothing is truly lost. git reflog shows every place your branch has ever pointed — it has rescued every developer at least once.

Common Mistakes & Fixes

"I committed to main but meant a branch" — git switch -c new-branch carries your uncommitted/committed work along; main never moved yet.

"My commit has a typo in the message" — git commit --amend -m "Better message" (only before pushing).

"Git says my file is ignored but I want it tracked" — check .gitignore; secrets and node_modules belong there, your source doesn't.

"I pushed a secret key" — rotate the key *first* (it's compromised regardless), then remove it from history; deleting the file in a new commit doesn't erase history.

Key Concepts

Snapshots, not diffs — commits are full states linked in a chain.

Branches are labels — cheap, movable pointers, not copies.

Staging area — add selects what the next snapshot includes.

Push/pull — syncing your local history with GitHub's copy.

What to Try Next

Put one of this site's projects on GitHub — the to-do list app is a great first repo.

Add a README.md and a .gitignore to every repo, starting today.

Try a pull request on your own repo: branch → push → PR → merge.

Learn .gitignore patterns properly — pair with the virtual environments guide so venvs never get committed.

FAQ

What's the difference between Git and GitHub?

Git is the version-control tool running on your machine; GitHub is a hosting service for Git repositories. You can use Git forever without GitHub; GitHub is useless without Git.

How often should I commit?

Whenever you reach a state you might want back — typically every 30–90 minutes of work, or at every 'it works now' moment. More frequent, smaller commits make history readable and rollbacks precise.

What do HEAD and origin mean?

HEAD is 'where you are right now'; origin is 'the copy on GitHub'. They appear in almost every error message, so learning these two words decodes most Git confusion.