Week 1 · Monday, August 24, 2026 · Room D-221

Every change you make, remembered and shared.

Before any Raspberry Pi is powered on, you learn the tool that will carry every line of code you write this semester: Git, and its online home, GitHub. Today you go from never having used either to a repository on the web with your own commits in it. These six pages are the whole path.

1 h theory 2 h lab No hardware today

What happens today

Theory · first hour

A time machine for folders

The problem version control solves, the three areas every Git project has (working directory, staging area, repository), what a commit really is, and the difference between Git on your machine and GitHub in the cloud.

Start with how Git thinks →

Lab · two hours

From empty folder to public history

Configure Git with your identity, create a repository, write a Markdown README, commit it in stages, create a GitHub account and repository, push, then practise the two-person workflow you will use all semester, conflicts included.

Start with the setup →

In the course outline

This is Week 1 of 420-302-VA. Assignment 1 (Git and GitHub, 10 %) is released next week (Week 2, August 31) and demonstrated in class in Week 3 (Monday, September 14); it uses exactly the skills on these pages. Version control is also a graded criterion of the term project: the LIA requires a shared GitHub repository with equal and traceable contributions from every team member, and the commit history is part of the evaluation. Next week the Raspberry Pi arrives; nothing to buy or bring for that beyond your usual kit list on Omnivox.

Why version control exists

You have probably already invented a bad version control system. It looks like this:

project.py
project_final.py
project_final_v2.py
project_final_v2_FIXED.py
project_really_final_this_one.py

Copies with creative names answer one need, keeping old versions, and fail every other one. Which file is actually newest? What changed between v2 and FIXED, and why? Which version worked before the bug appeared? And the moment a second person edits "the final version" at the same time as you, someone's work is silently overwritten. A version control system replaces the pile of copies with a single folder plus a recorded history:

Complete history. Every saved change is a snapshot with an author, a date and a message. You can read the story of the project, compare any two points, and travel back to any of them.
A working undo. Deleted a function last Tuesday and need it now? It is still in the history. Almost nothing committed to Git is ever truly lost, which makes experimenting safe.
Real collaboration. Two people edit at the same time and Git combines the work, telling you precisely when, and only when, you both touched the same line.
An off-site copy and a portfolio. Pushed history lives on GitHub as backup, and a public repository with clean commits is something employers and program coordinators actually look at.

Git, created in 2005 by Linus Torvalds to manage Linux itself, is the version control system essentially the whole industry settled on. GitHub is the largest hosting service built on top of it. Learning them in week one is not a detour from IoT; it is the working method for everything after.

Why this course insists on it, starting now

Your code will live on two machines

From Week 2 you write code on a Raspberry Pi whose boot drive is lent, wiped and re-imaged. From Week 8 an ESP32 joins in. Git is how work moves between machines and survives a re-image: anything not pushed exists in exactly one place.

Your team needs a referee

Assignments are done in teams of two or three, the project in pairs. Git merges parallel work and records exactly who contributed what; the outline makes that traceability part of the project grade, and the teacher is invited into your repositories as a collaborator.

Your project must be replicable

The LIA requires documenting the system on GitHub, configuration, wiring and code, well enough that a third party could rebuild it. The README habits you start today (Markdown, revised in commits) are that documentation.

What you will be able to do by the end of the week

Explain the three areas of a Git project and what add, commit, push and pull move between them.
Install and configure Git with your identity, and check both at any time.
Create a repository, write a Markdown README, and build a history of small commits with messages that say why.
Read your project's story with git status, git log and git diff, and undo an uncommitted mistake safely.
Create a GitHub account and repository, connect your local repository to it, and push and pull changes.
Work in a pair on one repository: pull before you push, and resolve a merge conflict on purpose so the first real one is boring.

Words you will hear all day

Term	Plain meaning	Common mix-up to avoid
Repository (repo)	A folder whose history Git tracks, thanks to a hidden `.git` directory inside it.	Different thing from an apt repository (a package server); Week 3 uses both meanings.
Commit	One saved snapshot of the project: the changes, plus author, date and a message. Both a noun and a verb.	Committing is local. Nothing reaches GitHub until you push.
Staging area	The loading dock where you place the specific changes your next commit will contain.	Editing a file does not stage it; `git add` does.
Remote / origin	A copy of the repository elsewhere, usually on GitHub. `origin` is the conventional name for yours.	"Origin" is a nickname you set, not something GitHub imposes.
Clone	Download a complete repository, full history included, to start working on it.	Not a plain file download; a clone stays connected to its remote.
Push / pull	Upload your new commits to the remote / download and merge the remote's new commits.	Pull first when you share a repo; pushing over unseen work is how pushes get rejected.
Branch	A movable pointer to a line of development; `main` is the default one.	A branch is not a copy of the project, just a lightweight label on the history.
Merge conflict	Git's pause when two changes touch the same lines and it refuses to guess which to keep.	Not an error and not lost work; it is a question addressed to you.
README / Markdown	The front-page file of a repository, written in Markdown, a plain-text formatting language GitHub renders.	Markdown is part of Assignment 1; the file is `README.md`, not `readme.txt`.

Where this fits in the course

Week 1 · Aug 24 · this hub

Git and GitHub

The working method: repositories, commits, pushing, pulling, and the team workflow every later week assumes.

Week 2 · Aug 31

Raspberry Pi: bare board to booted Linux

Hardware, the OS install, the Linux terminal. Assignment 1 is released and uses this week's skills.

Week 3 · Sep 14

Secure configuration

Updates, SSH keys (including one for GitHub, so pushes stop asking questions), the firewall, VNC. Assignment 1 demo.

Working at home

Everything today runs on any computer: install Git (next page), use the same GitHub account, and your repositories follow you between the lab and home with push and pull; that round trip is exactly what remotes are for. If typing in a terminal is brand new to you, the Week 2 terminal page goes deeper; today's pages explain every command as it appears, and only a handful are needed.