GitHub Workflow

So far, every change you've made has happened in the browser, directly on GitHub.com. That's fine for quick edits, but real project work happens in an editor on your own computer. Today connects the two — and the habit you build today is the one you'll use for every project this semester.

Why We Do This

Every time you save meaningful progress on a project, you make a commit — a snapshot of your work at that exact moment, with a short note explaining what changed and why. Do this regularly, and your commit history becomes something genuinely valuable: a real record of how your project actually grew, not just the finished result.

This isn't busywork or a school-only exercise — it's how software actually gets built, everywhere, by everyone.

The Basic Mechanics

Three moves make up almost everything you'll do:

  • Pull (or fetch) from origin — get the latest version from GitHub, in case anything changed there since you last worked
  • Commit — save a snapshot of your current changes, locally, with a message explaining it
  • Push to origin — send your local commits up to GitHub, where they're backed up and visible

"Origin" is just the name for the copy of your repo that lives on GitHub. The copy on your own computer is your local copy. Pulling brings changes down from GitHub to you; pushing sends changes up from you to GitHub.

Why Documentation Matters

Code that works isn't the same as code that's understandable. Comments in your code, clear commit messages, and a well-written README are all forms of documentation — they explain your thinking to someone else. That "someone else" might be a teammate, a future employer looking at your portfolio, or future-you in three months, having completely forgotten how any of this worked.

This course treats documentation as a real, core skill — not an afterthought tacked onto the "real" work.

How Your Repo Structure Works

Your repo isn't a black box that GitHub manages for you behind the scenes — it's a real folder, with real subfolders and files, identical whether you're looking at it on your H: drive or on GitHub.com. Clone your repo, and you get an actual folder you can open in File Explorer or VS Code. Add a file locally, commit it, push it — and it shows up on GitHub in exactly the same place you put it.

Why GitHub Instead of OneDrive?

You already have OneDrive through the school — so why bother with something new?

  • OneDrive saves your current file. GitHub saves every meaningful version, with your own notes on what changed and why — a real project history, not just a backup.
  • Git is built for code specifically. It can show the exact lines that changed between versions, not just "this file is different now."
  • This is the actual tool the software industry uses. GitHub experience is a real, transferable skill for post-secondary and employment — a OneDrive folder isn't.
  • Your GitHub portfolio is something you can genuinely show someone. A OneDrive folder was never built to be shared as "here's my work."

The Workflow, Every Time

  1. Pull origin — check for anything new before you start
  2. Make your changes — write code, edit files, whatever the task calls for
  3. Commit — save a snapshot locally, with a message
  4. Push to origin — send it up to GitHub

Writing a Good Commit Message

A commit message has two parts:

  • Summary (always) — a short, specific line. "Fixed bug" tells nobody anything. "Fix average calculation to ignore empty scores" actually explains it.
  • Description (when it helps) — a sentence or two on why you made the change, not just what changed.

Good habit to build now: write your commit message like you're leaving a note for someone who's never seen your code before — because eventually, that's exactly what it is.

Today's Activity

Now that you know the why and the how, let's actually use it.

  1. Download the activity file for your track (below), and save it into a 0_getting_started folder in your cloned repo
  2. Commit that addition — your first commit of the day
  3. Do the activity — work through the notebook at your own pace
  4. Commit your finished (or in-progress) work
  5. Push to origin — send it up to GitHub and confirm it's there

Beginners: variables, input, conditionals, and loops, ending with a combined challenge.
Download 0.3_intro_to_python.ipynb

Ready for something harder: build a Magic 8-Ball, with six tiers to climb as far as you want. AI is fine to use, but comments and clean syntax are expected either way.
Download 0.3_challenge_magic_eightball.ipynb

Naming your own file for the first time in this new tool? Quick reference: Naming Conventions (snake_case, and why it matters).

Need help getting GitHub Desktop installed and connected first? See the GitHub Desktop Setup Guide (coming soon).

What's Next

Coming up: Unit 1 — Python Foundations starts next class. Track placement (Core/Extended) will be shared then, based on what's been observed across 0.1–0.3.