Git & GitHub for Non-Developers

You've used version control before without knowing it:

• "Report_FINAL.docx"
• "Report_FINAL_v2.docx"
• "Report_FINAL_v2_ACTUALLY_FINAL.docx"
• "Report_FINAL_v2_ACTUALLY_FINAL_revised_JUDY.docx"

This is version control done badly. Git does it properly.

What Git gives you:

1. Complete history: Every change ever made, by whom, when, and why. Not just the current state — the entire evolution.
2. Safe experimentation: Try something new without risking your working version. If it doesn't work, undo it. If it does, keep it.
3. Collaboration without overwriting: Multiple people can edit the same project simultaneously. Git merges changes intelligently.
4. Accountability: "Who changed this and why?" has a definitive answer.

Git vs. GitHub:

• Git is the tool that runs on your computer and tracks changes.
• GitHub is a website that hosts Git repositories online, enabling collaboration, backup, and sharing.

Git works without GitHub (it's purely local). GitHub doesn't work without Git (it's built on top of it).

Who should learn Git:

• Developers (obviously)
• Writers (track drafts, collaborate with editors)
• Designers (version control for config files, documentation)
• Data analysts (track changes to scripts and queries)
• Anyone who's ever lost work to a crashed laptop or an overwritten file

Git has just a few core concepts. Everything else is built on these:

Repository (repo): A folder that Git is tracking. It contains your files AND a hidden .git folder with the complete history.

Commit: A snapshot of your project at a specific point in time. Like a save point in a video game. Each commit has:

• A unique ID (hash)
• The changes made
• Who made them
• When
• A message describing why

Branch: A parallel version of your project. The main branch is called "main" (or "master" in older repos). You create new branches to work on features without affecting main.

Merge: Combining changes from one branch into another.

The basic workflow:

1. Make changes to files
2. Stage changes (select which changes to include)
3. Commit (save the snapshot with a message)
4. Push (upload to GitHub)

Essential commands:

git init                    # Start tracking a folder
git add filename            # Stage a file
git add .                   # Stage all changed files
git commit -m "message"     # Save a snapshot
git status                  # See what's changed
git log                     # See history
git push                    # Upload to GitHub
git pull                    # Download latest from GitHub

Commit messages matter:

Bad: "fixed stuff", "updates", "asdfg"
Good: "Fix login button not responding on mobile", "Add search filtering to product list"

Your future self will thank you when searching through history to find when and why something changed.