Funcognito — Explore and learn anything, you got this!

0.2 Git and GitHub for your own work

Describes Git and GitHub as of August 2026

What this is and why it exists

Git is the seatbelt of everything you will build here: every experiment recoverable, every mistake undoable, every project shareable. It is also, bluntly, résumé infrastructure — a recruiter looking at your GitHub sees months of green squares and finished work, or nothing. Learn the daily four commands until they are muscle memory; learn recovery before you need it.

The vocabulary

  • Repository (repo) — a folder whose entire history Git records.
  • Commit — one saved snapshot of the project with a message; the unit of history.
  • Staging (add) — choosing which changes go into the next commit.
  • Branch — an independent line of work inside one repo; the default is usually main.
  • Merge — bringing one line of work's commits into another; a conflict is Git asking a human to choose between two edits to the same lines.
  • Remote / GitHub — a copy of the repo on a server; push sends your commits up, pull brings others' down.
  • Pull request (PR) — a proposal on GitHub to merge one branch into another, with review attached.
  • .gitignore — the list of files Git must never record: data, secrets, environments.

The mental model

Git is a time machine you feed deliberately. Nothing is recorded until you commit; a commit is a labelled snapshot of everything, forever recoverable. The daily loop is four commands: git init once per project, then git add (choose what), git commit -m "what and why" (snapshot it), git log (read the history). Small commits with honest messages — "fix off-by-one in split" not "stuff" — are what make the time machine navigable when you need last Tuesday back.

Branches make experiments free. A branch is a parallel line of history: try the risky refactor on its own branch, and main stays releasable the whole time. Merging brings the experiment home; when both lines edited the same lines of a file, Git stops and shows both versions between conflict markers — resolving is reading, choosing, deleting the markers, committing. It feels alarming once and mechanical ever after.

GitHub is the copy that makes it social: git push publishes your commits, git pull fetches what changed, and the pull-request flow — branch, push, open a PR, merge — is how teams (and this curriculum's projects) actually work. Two files make a repo presentable and safe: a README saying what this is and how to run it, and a .gitignore that keeps out what must never be committed — datasets (too big, not code) and keys or credentials (a secret pushed to a public repo is compromised the moment it lands, and history remembers even after deletion). Rotate any key that ever touches a public repo.

What you should now be able to explain or do

Run the daily four without thinking. Start an experiment on a branch, merge it, and resolve a conflict calmly. Push a project to GitHub with a README and a .gitignore, and explain why data and keys stay out. Recover a file as it was three commits ago.

Check yourself

git add stages chosen changes, git commit snapshots them with a message, git log reads the history, git init starts the whole thing once per project.

Two lines of history edited the same lines of the same file; Git shows both versions between markers and asks a human to choose. Resolve by editing, then commit.

Data is large and regenerable — history bloats permanently. Keys published to a repo are compromised instantly, and deleting them later does not delete them from history — rotation is the only fix.

Free experiments: the risky attempt lives on its own line while main stays working. Keep the experiment if it succeeds, abandon the branch if it fails — either way nothing was endangered.

Sustained real work — what you built, how often, and how your code and messages read. It is evidence rather than assertion.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Git and GitHub for your own work: work through the checklist