Stage 2 of 6 · Theory · about 20 minutes

How Git thinks

Git's commands stop feeling arbitrary the moment you see the map they move things across. There are four places your work can be, and every command you learn today is just a move between two of them.

The four areas

The whole course in one picture. Edits live on the left; each command moves work one step to the right; pull and clone bring the shared history back down to any machine.

Working directory. The ordinary folder you see in the file explorer. You edit here with any editor; Git watches but changes nothing on its own.
Staging area. A loading dock. git add places specific changes on it, which is how you build tidy commits ("just the README fix, not my half-finished experiment"). Nothing is saved to history yet.
Local repository. The history itself, stored in the hidden .git folder. git commit turns whatever is staged into a permanent snapshot here. All of this works offline.
Remote. A copy of the repository on a server, GitHub for us. git push uploads your new commits; git pull downloads and merges everyone else's.

Why the extra staging step?

Beginners sometimes find add before commit bureaucratic. It is the feature: you choose what goes into each snapshot, so one commit can mean one idea. "Fix sensor timeout" and "rewrite README intro" become two readable commits instead of one blob labelled "stuff". Your future self, your teammate and your grader all read this history.

What a commit really is

A commit is not "a save" of one file. It is a snapshot of the whole project at one moment, wrapped with metadata:

The snapshot: the state of every tracked file. Git stores this efficiently, unchanged files are not duplicated, but conceptually the whole project is in there.
Author and date: taken from the identity you configure on the next page. This is how "equal and traceable contributions" is literally measured in the project.
A message: your one-line explanation. The habit that separates useful histories from useless ones: say what and why, not "changes".
A parent: a reference to the commit that came before, which is what turns isolated snapshots into a history.

Each commit also gets an identifier, a long string like a1b2c3d..., computed from its contents. You will normally see the first seven characters in git log --oneline; that is enough to name any point in history exactly.

History is a chain (and a branch is a sticky note)

Each commit points to its parent. The arrows point backwards in time, and a branch like main is just a movable label on the newest commit of a line of work.

Because every commit knows its parent, Git can reconstruct the project at any point, show what changed between any two points (git diff), and tell who wrote each line and when. And because a branch is only a label on a commit, creating one is instant and free: you move the label forward as you commit, without touching anyone else's line of work. You will make one deliberately in the team stage; heavier branching workflows come naturally later in the semester.

Everyone has the whole history

Git is a distributed version control system: when you clone a repository, you get the complete history, not a viewing window into someone's server. Three practical consequences for this course:

You can work offline. Commits, logs, diffs and branches all happen locally. Only push and pull need the network, useful when the class Wi-Fi has a bad day.
Every clone is a backup. If the lab PC is wiped or your Pi's drive is re-imaged, any other clone (GitHub's, your teammate's, your laptop's) holds everything.
Speed. Reading history never waits on a server; it is all on disk beside your files.

Git versus GitHub

Git · the tool

A program installed on your computer
Tracks history in the .git folder
Works completely offline
Free, open source, owned by no company
What you use: the git command

GitHub · the service

A website that hosts Git repositories
Adds a web view of code and history, plus issues, pull requests and access control
The shared meeting point for your team, and for the teacher as collaborator
One host among several (GitLab, Bitbucket, ...), the one this course uses
What you use: your account at github.com

The distinction matters in sentences you will hear all semester: "commit your work" needs only Git; "hand in on GitHub" means push. When both are gone from your machine, your code still exists in every other clone; that is the design.

The first chapter of the free official book covers everything on this page with more history and pictures: Pro Git, "About Version Control". Atlassian's What is version control? is a shorter second telling of the same story.

Check yourself

You edited a file and saved it in your editor. Where does the change live, in Git's terms?

Only in the working directory. It is not staged (no git add yet), not in history (no commit), and not on GitHub (no push). Saving in an editor and saving to history are different acts.

What four things does every commit contain?

A snapshot of the tracked project, the author and date, a message, and a reference to its parent commit. The parent links are what make history a chain you can travel.

Your teammate says "I committed the fix, why don't you see it?" What is the most likely answer?

A commit is local. Until they git push and you git pull, their snapshot exists only in their local repository.

Why does git add exist instead of committing everything that changed?

The staging area lets you choose the contents of each snapshot, so one commit can express one idea. Readable history is the whole point, and in this course it is also graded.

The class network goes down. Which of these still work: commit, log, push, branch?

Commit, log and branch: they are local operations on your full copy of the history. Only push (and pull, clone, fetch) need the network.