Hey - Tom here.

If you've ever Googled "Git vs GitHub" and walked away more confused than when you started, I get it.

I was there once.

Once you grasp what each tool actually does, version control becomes a skill that makes you significantly more hireable.

And I'm not exaggerating when I say, it dramatically improves your overall coding experience and makes your life easier.

Here's what we're covering this week:

• What Git is (and why it exists independently of GitHub)
• What GitHub is (and why it's become the industry standard)
• The exact workflow you need to understand to use both effectively
• Common mistakes

Let's get into it...

Git ≠ GitHub

Git is version control software that runs on your computer.

It tracks changes to your code, lets you experiment without breaking things, and allows multiple people to work on the same project without overwriting each other's work.

Git exists entirely on your local machine.

You don't need the internet.

You don't need GitHub.

GitHub is a website that hosts Git repositories.

It's where you store your Git-tracked projects so others can access them, collaborate on them, and review your work.

Think of it like this:

• Git is like Microsoft Word with version history turned on — you can save versions, go back, branch off drafts, all locally.
• GitHub is like OneDrive or SharePoint — a place to store, sync, and collaborate on those Word docs with others.

You don’t need OneDrive to use Word, but it’s how teams work together effectively.

Why This Distinction Matters

1. Git Works Offline, GitHub Doesn't

You can commit changes, create branches, and manage your entire project history on a flight with no WiFi.

GitHub only comes into play when you're pushing (uploading) or pulling (downloading) changes.

This means your local Git repository is the source of truth for your work, not GitHub.

2. GitHub Is One of Many Options

Git can work with GitLab, Bitbucket, or even just shared folders on a company server.

GitHub happens to be the most popular hosting platform, but it's not Git itself.

If your company uses GitLab, you're still using Git - just with a different hosting service.

3. Understanding Git Makes GitHub Make Sense

Most GitHub confusion comes from not understanding the underlying Git concepts.

Once you know what a commit, branch, or merge actually does in Git, the GitHub interface just becomes a visual representation of those actions.

The Core Git Workflow (No GitHub Required)

Here's what's happening on your local machine when you use Git:

1. Initialise a Repository

You tell Git to start tracking changes in a folder:

git init

2. Stage Your Changes

You select which modified files you want to include in your next save point:

git add filename.sql

or add everything:

git add .

3. Commit Your Changes

You create a save point with a description of what you changed:

git commit -m "Fixed the date filtering logic in sales query"

4. Create Branches

You make a copy of your work to experiment without affecting the main version:

git checkout -b experimental-feature

5. Merge Changes Back

When you're happy with your experiment, you combine it back into the main version:

git checkout main

git merge experimental-feature

All of this happens locally. No internet connection needed.

Normally though you wouldn't merge a branch into main straight away, but more on that in a minute...

Where GitHub Enters the Picture

GitHub adds three critical capabilities:

1. Collaboration

Multiple people can work on the same project. GitHub handles combining everyone's changes and resolving conflicts when two people edit the same file.

2. Backup & Access

Your code lives on GitHub's servers. If your laptop dies, your work is safe. You can pull it down on any machine.

3. Code Review & Project Management

Pull requests let teammates review your code before it goes live. Issues track bugs and feature requests. Actions automate testing and deployment.

The Standard Workflow (Git + GitHub)

Here's how Git and GitHub work together in practice:

On Your Machine (Git):

1. Clone the repository: git clone https://github.com/company/project.git
2. Create a branch: git checkout -b fix-broken-query
3. Make your changes
4. Stage them: git add modified_file.sql
5. Commit them: git commit -m "Descriptive message"

Connecting to GitHub:

6. Push your branch to GitHub: git push origin fix-broken-query

On GitHub (Website):

7. Open a pull request
8. Team reviews your code
9. Once approved, merge it into the main branch

Back on Your Machine:

10. Switch to main: git checkout main
11. Pull the latest changes: git pull origin main

The key insight: Git handles all the version control mechanics. GitHub handles the collaboration and hosting.

Common Mistakes

Mistake #1: Treating GitHub as a backup tool

Don't just upload files manually through the GitHub website.

Use proper Git commands to commit and push.

The commit history is what makes version control valuable.

Mistake #2: Working directly on main

Always create a branch for your work.

Merging broken code into main affects everyone on your team.

If you're like me, you will break things from time to time.

Having a clear separation of what was done when (different branches) helps roll back to when it worked.

Mistake #3: Vague commit messages

"Fixed stuff" tells you nothing in six months.

Write: "Corrected timezone conversion in user_activity table".

Mistake #4: Not pulling before you start work

If you don't pull the latest changes first, you'll create merge conflicts when someone else has already updated the same files.

You always want to start working based on the most recent version of the codebase.

Pull from master first, then branch off, then develop.

TL;DR:

• Git is version control software - it tracks changes and manages project history on your computer
• GitHub is a hosting platform - it stores Git repositories and enables team collaboration
• You use Git locally to commit changes, create branches, and manage versions
• You use GitHub remotely to share code, review work, and coordinate with teammates
• Master Git first - GitHub's features only make sense once you understand the underlying version control concepts

Understanding Git conceptually takes an hour.

Using it confidently without constantly second-guessing yourself takes structured practice.

That's where premium comes in.

This week you'll get:

• The Complete Git Workflow Walkthrough - A step-by-step guide from repository setup to your first successful push to Github. You'll learn the exact commands and when to use them
• Git Command Cheatsheet - A reference guide for every command you'll actually use in daily work. No obscure flags you'll never need - just the essential commands with real-world context for when to use each one.
• Full Premium Archive Access - Every past edition's exercises, code examples, and resources. All downloadable and yours to keep.

You'll walk away with a working Git repository, real commits in your history, and the confidence to use version control in interviews and on the job.

Ready to get stuck in? Click below and join us 👇🏻