Your Developer Passport: GitHub

Before You Study (5 mins)

Lesson focus: Developers don't email files to each other. They use Git (a distributed version-control system) and GitHub (a cloud host built on top of Git). Today we get past the lazy "Git = save to GitHub" framing and learn the actual workflow professional engineers use every day. By the end, your Snake game has a public GitHub repository, every change you've made is preserved as a commit, and you have a portfolio link you can put in a CV, in a job application, or in a message to a friend who asked "what have you been building?"

What you should have ready:

• A free GitHub account at github.com — sign up if you don't have one yet
• Terminal fluency from Lesson 04 — we'll use git commands
• Your Snake game project locally
• About 60 minutes
• Patience to set up SSH keys once (the right way) instead of fighting password prompts forever

The Concept

Git and GitHub are not the same thing. Conflating them is the single most common confusion when learners start, and untangling it makes everything else easier.

• Git is a distributed version control system — software that runs on your machine. It tracks changes to files, lets you record snapshots ("commits"), branch off to try something, merge changes back, and inspect history. It works completely offline. It was created by Linus Torvalds in 2005 to manage Linux kernel development.
• GitHub is a commercial hosting service (owned by Microsoft) for Git repositories. It adds a web UI, pull requests, code review, issue tracking, GitHub Actions for CI/CD, and the social features that turned it into the default home for open source.

You can use Git without GitHub. You cannot use GitHub without Git underneath. The two are layered: Git is the engine; GitHub is the cloud platform built on it.

The mental model that makes Git click is the Directed Acyclic Graph (DAG) of snapshots. Every commit is a complete snapshot of your project's files at that moment, identified by a SHA-1 hash. Each commit points to its parent (or parents, in the case of a merge). The history is a graph of these snapshots — not a list of changes. Branches are just named pointers into this graph. Creating a branch is O(1) — instant, free, no copying — because nothing actually moves; only the pointer is named.

The local workflow has three zones, and the movement between them is what you'll repeat thousands of times in your career:

Working Directory  ──git add──▶  Staging Area  ──git commit──▶  Local Repository
   (your edits)                  (what's selected for             (the snapshot
                                  the next snapshot)               history)

When you push, the local repository syncs with the remote — usually GitHub. When you pull, you sync the other way. When two people change the same line, Git refuses to guess which one wins; you get a merge conflict, and resolving it is part of the job.

The professional workflow today is branch + pull request, not "commit straight to main":

1. git checkout -b feature-x — create a branch for your work
2. Edit, commit, edit, commit — repeatedly, on your branch
3. git push origin feature-x — upload the branch to GitHub
4. On GitHub: open a Pull Request — propose merging your branch into main
5. Code review happens in the PR; you push more commits to address feedback
6. Once approved, merge the PR; delete the branch

Even on a one-person project, this discipline pays back: it preserves a clean history, makes feature flags trivial, and turns "rolling back a bad change" into a one-line operation.

Two companion articles deepen this lesson. What is Git and Why Every Developer Needs It explains the snapshot DAG model and the SHA-1 integrity story. GitHub for Beginners — Creating Your First Repository and Pull Request walks through the daily workflow with real commands. Read both this week.

Quick Concepts

What We Will Build

By the end of this lesson, you will have done these specific things:

1. Configured your Git identity so every commit is attributed to you:
   bash

   Copy

   git config --global user.name "Your Name"
   git config --global user.email "[email protected]"
   

2. Generated an SSH key pair for password-less authentication with GitHub:
   bash

   Copy

   ssh-keygen -t ed25519 -C "[email protected]"
   cat ~/.ssh/id_ed25519.pub   # Copy the contents
   

   Then add the public key to GitHub at Settings → SSH and GPG keys.
3. Initialized your Snake game folder as a Git repository: cd snake-game && git init.
4. Created your first commit:
   bash

   Copy

   git add .
   git commit -m "Initial commit: working Snake game from Lesson 01"
   

5. Created a new GitHub repository (the empty kind, no README) and connected your local repo to it via git remote add origin [email protected]:<you>/snake-game.git.
6. Pushed your code: git push -u origin main. Refreshed the GitHub page and saw your code online.
7. Created a feature branch to add one improvement: git checkout -b feature-difficulty. Made a change in code (e.g., add a difficulty level). Committed. Pushed.
8. Opened a Pull Request on GitHub from feature-difficulty into main. Read your own diff. Merged it. Deleted the branch with git branch -d feature-difficulty.
9. Wrote a real README.md — the project's front door. Used it to introduce your project: title, what it does, how to run it, screenshot or demo link.

Step 9 is the most important. The README is what every visitor sees first. A good README in 2026 takes a stranger from "what is this" to "I can run it" in under 60 seconds.

Think About

Before studying, consider:

1. If you make a change today and break the game, how do you get back to the working version from yesterday? (Hint: Git checkout to a previous commit's SHA. Time travel is real and free.)
2. A friend wants to contribute one small fix to your Snake game. They live in another city. Without GitHub, what is the workflow? Email zip files? With GitHub: they fork, fix, open a PR, you merge. Same outcome; orders of magnitude less friction.

By the End

After this lesson, you'll:

• ✅ Have configured Git with your name and email
• ✅ Have an SSH key pair set up and added to GitHub
• ✅ Have a public repository at github.com/<you>/snake-game with your code in it
• ✅ Have made at least 3 commits with descriptive messages
• ✅ Have created, pushed, and merged your first feature branch via Pull Request
• ✅ Have a real README.md that introduces your project to a stranger
• ✅ Be ready to publish every project you build for the rest of your career

The first PR is the hardest. Every one after is muscle memory. 🌍

What We Learned

• Git ≠ GitHub. Git is the version-control engine running locally. GitHub is the cloud platform built on top of Git that adds web UI, code review, and collaboration features.
• A commit is a snapshot, not a diff. Git stores complete file states (deduplicated by hash) and represents history as a directed acyclic graph. This is why operations like branch creation are instant and merging is mathematically sound.
• Branches are just named pointers. Creating a branch costs almost nothing — no file copying, no time penalty. This is why the professional workflow is "branch per feature," not "edit main and hope."
• The professional workflow is branch → PR → review → merge. Even solo, this discipline produces clean history, makes rollbacks trivial, and prepares you for collaboration the moment a second contributor appears.
• SSH key authentication beats HTTPS passwords. Set it up once; never type a password to GitHub again.
• A good README is the project's front door. It is what every visitor — recruiter, collaborator, future you — sees first.

Commands We Used

# One-time identity setup (your name + email appear on every commit)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# One-time SSH setup (so you don't type passwords)
ssh-keygen -t ed25519 -C "[email protected]"
# Then copy ~/.ssh/id_ed25519.pub into GitHub Settings → SSH keys

# Initialize a project under Git tracking
cd snake-game
git init
git branch -M main          # Rename default branch to 'main'

# Daily workflow: stage, commit
git status                   # What's changed?
git add .                    # Stage everything
git add file.js              # Or stage one file
git commit -m "Add difficulty levels"

# Connect to GitHub remote and push
git remote add origin [email protected]:<you>/snake-game.git
git push -u origin main      # First push — sets upstream tracking
git push                     # Subsequent pushes

# Branching and PRs
git checkout -b feature-difficulty
# ... edit, add, commit ...
git push -u origin feature-difficulty
# Open the PR on GitHub, review, merge

# Inspecting history
git log --oneline --graph --all   # The DAG, in your terminal
git show <commit-hash>            # See exactly what one commit changed

# Time travel
git checkout <commit-hash>        # Look at the project as it was
git checkout main                 # Come back to the present

A minimal but professional README:

# Snake Game

A small browser-based snake game built with HTML, CSS, and JavaScript
as part of the [ABCsteps](https://abcsteps.com) AI Engineering Course.

## Demo

Live demo: https://your-username.github.io/snake-game/
(Or run locally — see below.)

## Running locally

```bash
git clone [email protected]:your-username/snake-game.git
cd snake-game
npm install
npm run dev
# Open http://localhost:3000

What I learned building this

• Game loop fundamentals (requestAnimationFrame)
• Collision detection between snake and food
• Modular file structure (HTML / CSS / JS separation)
• AI-assisted development with verified output

License

MIT — feel free to fork and learn.

### Why It Matters

Git is the most important tool you will learn in this course. Editor preferences shift, frameworks come and go, even programming languages cycle through fashion — but every commit you make for the next twenty years will use the same Git command vocabulary. There is no professional engineering job where Git is optional.

The deeper compounding effect is in how Git changes your relationship to code. Once you trust the time-travel ability — once you've used `git checkout` to bounce between past versions and *prove* it's safe — you start *experimenting*. You try refactors you'd otherwise be scared to attempt. You delete code aggressively. You take risks. The safety net of "I can always go back" makes you bolder, and bolder engineers ship better software.

GitHub specifically is the visible portfolio of an engineer's work. In 2026, hiring managers look at GitHub before they look at résumés. A polished `github.com/<you>` profile with five well-documented repositories beats a CV listing fifty technologies. Each commit you make is a public artefact, and the contribution graph (the green squares) is a visible record of how you spend your time.

What this lesson glossed over but you'll need within months:

- **Interactive rebase** (`git rebase -i`) — clean up your commit history before merging. Squash messy fixups, reorder commits, edit messages.
- **Cherry-pick** (`git cherry-pick`) — take one commit from one branch and apply it to another.
- **GitHub Actions** — automated CI/CD: run tests on every push, deploy to production when `main` updates.
- **Branch protection rules** — make `main` un-pushable directly; require PR + approval. The standard for any team setup.
- **Resolving merge conflicts in real life** — every senior engineer hits these weekly; the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) are not errors but Git telling you it cannot decide between two human intents.

The companion articles cover all of this in depth:
- [What is Git and Why Every Developer Needs It](/blog/what-is-git-and-why-every-developer-needs-it) — for the snapshot-DAG model and the SHA-1 integrity story.
- [GitHub for Beginners — Creating Your First Repository and Pull Request](/blog/github-for-beginners-creating-your-first-repository-and-pull-request) — for the daily workflow, with the conflict markers and protection rules walkthroughs.


### Checklist

- [ ] My Git is configured with `user.name` and `user.email`
- [ ] My SSH public key is added to GitHub Settings
- [ ] My local Snake game repo has at least 3 commits
- [ ] My code is published at `github.com/<my-username>/snake-game`
- [ ] I created a feature branch, pushed it, and merged it via a PR
- [ ] My repository has a README.md that explains the project to a stranger
- [ ] I can describe in my own words what a "commit" is


### Quick Quiz

**Q1:** What is the difference between Git and GitHub?
- A) Git is paid; GitHub is free
- B) Git is the local version-control engine; GitHub is the cloud platform built on top of it ✓
- C) Git is for code; GitHub is for documents

**Q2:** What is a commit?
- A) A snapshot of your project's files at a moment, identified by a hash ✓
- B) A diff between two file versions
- C) A backup zip file uploaded to the cloud

**Q3:** Why are Git branches "cheap"?
- A) Because they don't cost money
- B) Because creating one is just naming a pointer to a commit — no file copying ✓
- C) Because they automatically expire after 24 hours

**Q4:** What is a Pull Request (PR)?
- A) A request to download data from GitHub
- B) A formal proposal on GitHub to merge one branch into another, with review and discussion ✓
- C) A way to revert a commit

**Q5:** Why use SSH keys instead of HTTPS passwords for GitHub?
- A) SSH is faster
- B) SSH avoids per-session password / token prompts and is the professional default ✓
- C) HTTPS doesn't work with GitHub anymore


### Bonus Challenge

Make your repository public, click GitHub's green "Code" button, copy the link, and send it to two people:

1. **Someone who codes** — ask them for one piece of honest feedback on the README or the code structure.
2. **Someone who doesn't code** — ask them if they could figure out what the project is and how to play it from your README alone. If the non-coder gets stuck, the README needs work.

Iterate the README based on the feedback. The README that survives this test is the one that earns you the next conversation — with a recruiter, a collaborator, or a friend who wants to learn the same way you did.


### Next Lesson

**Lesson 06:** Netflix's Secret — Docker

**You'll learn:** Your code is on GitHub. But "it works on my machine" is the most famous bug in software engineering. Today we package your app into a *container* — the same technology Netflix, Spotify, and your bank use to ship the same app to millions of different machines without "but I have a different version of Node" excuses.


*Module A complete. You're publishing engineering work. Five down, fifteen to go.* 🏗️