Module 4: Git & GitHub#

By the end, you can:

  • Record your bridge lab in Git.
  • Push it to GitHub.
  • Clone it into a new folder and run your scripts again.

Bring:

  • ~/bridge-lab from the earlier modules.
  • Git and a GitHub account.
  • Use this practice lab for the exercises.

Practice roadmap#

Start where you are · Choose your target

Start at 01 to see Git history in a game, 02 for branching and remote history, 03 for recovery and debugging, or 04 for team workflows. Use the game mission and local lab below to build your first snapshots.

From local Git practice to recovery and collaborationFour connected stops: Oh My Git! for visual snapshots and branching practice, Learn Git Branching for commit and remote graph challenges, Git Exercises for recovery and debugging, and optional GitHub Skills for reviews, conflicts and releases.01020304PlayBranchRecoverCollaborate
  1. 01Foundation · Play with history

    Oh My Git! ↗

    Download · Windows, macOS or Linux · No GitHub account needed

    Complete the introductory mission below using the command cards, then repeat the operations in the game's terminal. Watch commits and branch pointers change as you edit, stage and commit. Continue to branching and merging levels when you can explain the two snapshots.

    Move on when: you can create two commits, compare their contents and explain the difference between editing, staging and committing.

  2. 02Intermediate · Reshape history

    Learn Git Branching ↗

    Free browser simulator · JavaScript enabled · No account

    Work through Ramping Up and Moving and Staging Work, then the Remote tab's To Origin And Beyond challenges. Practise detached HEAD, cherry-picking, interactive rebase and synchronising divergent remote branches. Match each goal graph rather than copying its solution.

    Move on when: the selected sequences are solved and you can predict which commits and branch pointers each command changes.

  3. 03Advanced · Recover and debug

    Git Exercises ↗

    Free · Git + Bash + internet · OpenSSL for the bug exercise

    Follow the site's clone and setup instructions. Tackle commit-lost with reflog, split-commit, rebase-complex with rebase onto, and find-bug with bisect. The checker inspects real repository state: recover a lost commit, separate changes, transplant selected history and identify the first failing commit.

    Move on when: all four tasks are accepted and you can explain each method. Submit with git verify or the task's explicit push instructions.

  4. 04Optional stretch · Team workflows

    GitHub Skills ↗

    GitHub account · Separate exercise repositories · GitHub Actions

    Complete Review pull requests, Resolve merge conflicts and Release-based workflow. Copy each exercise into its own repository and follow its automated feedback. Public exercise repositories avoid private Actions-minute use.

    Target: apply a review suggestion, resolve a pull request conflict, and complete a tagged release with release notes and a hotfix release.

Keep local exercise folders outside bridge-lab and use separate GitHub Skills repositories. Practise resets and history rewriting in disposable exercise repositories; avoid rewriting commits that teammates already depend on.

Game mission: Oh My Git!Make a snapshot. See what Git remembers. | 3 challenges

Start here#

  1. Download Oh My Git! for your OS.
  2. Extract it and launch the included executable/app.
  3. Open the introductory chapter and read each level’s goal.
  4. Run the commands below in the game’s black terminal.

Warm-ups, if shown:

  • Living dangerously: open form.txt, add a reason on a new line and save.
  • Making backups: repeat in form2_really_final.txt.
  • Save: Ctrl+S (Windows/Linux) or Cmd+S (macOS); click Next Level after completion.

Challenge 1: Enter the time machine#

Try the blue init card before opening the walkthrough.

Walkthrough: start tracking
  1. Drag the init card upward to play it.
  2. Check the goal completes, then click Next Level.
  • Meaning: Git is ready to track history; no snapshot exists yet.

Challenge 2: The command line#

  1. Click the black terminal.
  2. Enter this command and press Enter:
git init
  1. Check the goal completes and continue to Your first commit.
  • Meaning: typing the command performs the same action as the init card.

Challenge 3: Your first commit#

Save two versions of the glass.

Walkthrough: two snapshots
  1. In the game’s terminal, record the full glass:
git add glass
git commit -m "Full glass"
  1. Open glass, change its text to The glass is empty. and save.
  2. Record the changed glass:
git add glass
git commit -m "Empty glass"
git log --oneline
  1. Click each snapshot in the visual history and compare the contents.
  • Success: two commits appear and the level completes.
  • Meaning: add selects content; commit records that selection.
  • Stuck? Read the goal and run git status; editing alone does not create a commit.
  • Can’t run the game? Practise the same operations in the lab below.
  • Reference: official introductory levels.

Your lab#

  • Git: saves version history on your computer.
  • GitHub: hosts the history you push online.
  • Flow: edit → save → add → inspect → commit → push.

Open Setup first, then follow sections 4.1–4.4.

Setup · Git identity and defaults (once)

Replace the name/email with yours; use a verified GitHub email or your no-reply address from Settings → Emails.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main
  • Name/email: label the author of your commits; these are not login credentials.
  • Default branch: new repositories start on main.
  • --global: saves settings for your user on this machine; do this once.
4.1 · Create a local snapshot
  1. In ~/bridge-lab, create README.md with a title and the run instruction uv run scripts/check-in.py.
  2. Create .gitignore with these lines:
.venv/
__pycache__/
.env
.DS_Store
  • Ignore: local environments, caches, secret settings and macOS metadata. Keep passwords and private keys outside the lab.
cd ~/bridge-lab
git init
git add .
git diff --cached
git commit -m "Save my bridge lab"
git log --oneline
  1. Initialise: git init starts a repository; the setup above makes its first branch main.
  2. Stage: git add . selects new/changed files under this folder, respecting .gitignore for untracked files.
  3. Inspect: git diff --cached shows the staged content; press q if a pager opens.
  4. Commit: saves the staged snapshot locally; -m supplies its message.
  5. History: git log --oneline lists commits compactly; expect one commit.
  • Check before committing: source files are staged; .venv and private data are absent.
  • Later edits: save and add again before committing; commit uses the staged version.
4.2 · Connect to GitHub: generate → copy → paste

If you already have a working GitHub SSH key, reuse it. Otherwise:

  1. Generate a key pair:
ssh-keygen
  1. Accept the default save path if unused; do not overwrite an existing key. Enter a passphrase when prompted.
  2. Find the output line Your public key has been saved in …. Use that exact .pub path with cat:
cat "/path/from/ssh-keygen.pub"
  1. Copy the entire printed line.
  2. On GitHub: Settings → SSH and GPG keys → New SSH key.
  3. Choose Authentication Key, name the device, paste and save.
  • Replace the example path: use the public-key path printed on your computer.
  • Key pair: share the .pub file; keep the private key on your machine.
  • Default location: SSH can use the key directly; an agent is optional. Enter your passphrase when asked.
Optional SSH options: when to use them and why

Choose a key type and label — use this instead of plain ssh-keygen when you want to specify both:

ssh-keygen -t ed25519 -C "[email protected]"
  • -t: chooses Ed25519; -C: adds an email label to identify the key.

Avoid repeated passphrase prompts — load your private key into an agent for this session:

eval "$(ssh-agent -s)"
ssh-add "/path/to/private/key"
  • eval ...: starts the agent and connects this shell to it.
  • ssh-add: unlocks and loads the private key; replace the path and omit .pub.

Use a custom key path — if you saved outside the default location, add/update this block in ~/.ssh/config:

Host github.com
  IdentityFile /path/to/private/key
  IdentitiesOnly yes
  • IdentityFile: chooses your private key; IdentitiesOnly: limits which identities SSH offers.

Check the connection — use this before pushing or when diagnosing login problems:

ssh -T [email protected]
  • -T: disables terminal allocation; GitHub authenticates you without providing a shell.
  • First host prompt: compare with GitHub’s fingerprints before accepting.
  • Success: GitHub greets your username; “no shell access” is expected.
4.3 · Push your commits to GitHub
  1. On GitHub, create a Private repository named bridge-lab.
  2. Leave README, license and .gitignore unchecked; you already have local files.
  3. Copy its SSH URL and replace YOUR_USERNAME below:
cd ~/bridge-lab
git remote add origin [email protected]:YOUR_USERNAME/bridge-lab.git
git push -u origin main
  1. Remote: origin is a nickname for your GitHub repository’s URL.
  2. Push: uploads commits from main; -u remembers the upstream so later pushes use git push.
  • Check: GitHub shows your README, code and commit; .venv is absent.
  • Remember: GitHub receives pushed commits, not unsaved or uncommitted edits.
4.4 · Clone and continue working

Use a destination that does not already exist; replace YOUR_USERNAME.

cd ~
git clone [email protected]:YOUR_USERNAME/bridge-lab.git bridge-lab-recovered
cd bridge-lab-recovered
git log --oneline
uv run scripts/check-in.py
  1. Clone: downloads working files and Git history, and sets up origin automatically.
  2. Enter: cd moves into the recovered copy.
  3. Verify: your commit appears and the NumPy script runs; uv prepares its dependencies.
  • Already set up: no new git init or remote add is needed.
  • During this exercise: edit only the recovered copy.

Finish without copying#

  1. In the recovered copy, add a sentence to README and save.
  2. Stage, inspect, commit with a useful message, then push.
  3. Check that the new commit appears on GitHub.
CommandRemember
git statusWhat changed; what is staged?
git add README.mdSelect the saved changes
git diff --cachedInspect what you will commit
git commit -m "Explain my NumPy example"Record a local snapshot
git pushSend commits to GitHub
  • I completed the three guided game levels.
  • I can explain add, commit and push.
  • My cloned script runs and my second commit is on GitHub.

Stuck?

  • SSH permission denied: check your public key on GitHub and load the matching private key in the same terminal environment.
  • origin exists: inspect git remote -v; correct a wrong URL with git remote set-url origin YOUR_COPIED_SSH_URL.

Explore: run git diff before staging, then git diff --cached after staging. Explain the difference.

References: Git tutorial · GitHub SSH setup.

Bridge complete: keep your repository and notes as your reference for the main course.

Backward 03 HTTP and Devtools 01 Vscode 1 Basics Forward