Version Control with Git

Imagine you spend an afternoon improving a script that generates a room schedule, and in the process you break something that worked yesterday. Without version control your options are grim: undo frantically and hope, or dig through script_old.py copies you may or may not have made. With version control, yesterday's working version is one command away, because git kept a snapshot every time you told it to.

That is the core idea: instead of hoarding whole copies of files with cryptic names, you keep one set of files and let git remember every committed state along the way. Each snapshot - called a commit - records the entire project plus a short message you write ('add CSV export', 'fix area bug'). Together they form a history you can read like a logbook and travel back through. Version control gives you four superpowers at once: a safe undo to any past point; a readable record of what changed and why; a backup that survives a dead laptop; and a way to share and collaborate without emailing zip files. Even for a solo designer with a folder of personal scripts, the first three alone are worth the small learning cost. You are not adopting a heavyweight process - you are buying insurance against ever losing work, and a memory of your own decisions. Think of the everyday alternative: a shared drive full of plan_final.dwg, plan_final_v2.dwg and plan_FINAL_actually.dwg, where nobody can say which is current, what changed between them, or why. That is version control done badly, by hand, and every designer has suffered it. Git is simply that same instinct - keep the old versions, know what changed - done properly, automatically, and without the sprawl of duplicate files. The small cost of learning it is repaid the very first time you need yesterday's working code back.

Git has a fearsome reputation, but the daily reality is a short loop of a few commands. You run these in a terminal, inside your project folder. First, once per project, you turn the folder into a git repository:

cd my-scripts
git init

That creates a hidden .git folder where git keeps its history - you never touch it directly. Now you work as normal, editing your Python files. When you reach a point worth saving, you do the two-step that trips up every beginner until it clicks. First you stage the changes you want in this snapshot with git add, then you commit them with a message:

git add schedule.py
git commit -m "Add habitable-area total"

Why two steps? Because staging lets you choose exactly what goes into a commit - you might have changed three files but only want two in this snapshot. Think of git add as putting things in the box, and git commit as sealing and labelling it. Write commit messages for your future self: "Fix off-by-one in room loop" tells you something in six months; "stuff" and "asdf" tell you nothing. A good rhythm is to commit each time you get one small thing working - little and often beats one giant commit at the end of the day. To see where you are at any moment, git status shows what has changed and what is staged, and git log prints the history of commits.

So far everything lives on your machine, which means a dead laptop still loses everything. The fix is a remote - a copy of your repository hosted elsewhere - and by far the most popular host is GitHub. You create an empty repository on GitHub, connect your local project to it once, and from then on you push your commits up:

git remote add origin https://github.com/you/my-scripts.git
git push -u origin main

After that first setup, sharing new work is a single git push. Your commits are now backed up off your machine, visible from anywhere, and - if you choose - shareable with others. On another computer you git clone the repository to get the whole project and its full history. This is also how you use other people's tools: you clone their repository, read their code, and run it.

GitHub is more than storage. It renders your README (a plain-text description of what the tool does and how to run it), tracks issues, and shows your work to the world - which matters enormously for a computational designer's portfolio, the subject of Lesson 10.4. For a designer, the honest starting point is simple: push your useful scripts to GitHub so they are safe and findable. You do not need branches, pull requests or the collaborative machinery on day one - those are worth learning when you actually work with others, and they build naturally on the same commit-and-push loop you already know.

Not everything in your project folder belongs in git. Big data files, exported images and PDFs, secret keys, and the noise your tools generate (like Python's __pycache__ folder or a virtual environment) should be left out - they bloat the history, and secrets committed to a public repo are a genuine security incident. Git handles this with a plain-text file called `.gitignore`: you list patterns of files to ignore, and git pretends they are not there.

A sensible starting .gitignore for a Python project reads:

__pycache__/
*.pyc
.venv/
*.csv
*.pdf
exports/
secrets.txt
.env

Each line is a pattern - *.csv ignores every CSV, exports/ ignores that whole folder. Commit the .gitignore itself (it is small and useful), and from then on git quietly skips those files. The rule of thumb: commit the source - your `.py` scripts, your README, small sample inputs - and ignore the derived, the huge, and the secret. A repository should be the recipe, not the meal. Getting this right early keeps your history clean and, more importantly, keeps you from ever pushing a password or an API key to a public place where it cannot be truly taken back. If you ever do commit a secret by accident, treat it as compromised and rotate it - deleting it in a later commit does not remove it from history. A good habit is to write the .gitignore before your first commit, not after, so the junk never enters the history in the first place; cleaning it out later is far more work than keeping it out from the start. Most editors and GitHub also offer ready-made Python .gitignore templates you can copy as a sensible baseline and then adjust.

The payoff of committing regularly is that your history becomes a tool, not just a record. Three everyday commands turn it into a safety net. git log prints your commits newest-first, each with its message and a short hash (an id like a1b2c3d) you can refer to. git diff shows exactly what has changed since your last commit - line by line, additions and deletions - which is invaluable for answering 'what did I actually change?' before you commit. And git status, run constantly, tells you what is modified and what is staged.

git status          # what has changed?
git diff            # show the exact line changes
git log --oneline   # compact history, one commit per line

The genuine relief comes when something breaks and you want to go back. If you have edited a file into a mess but not committed, git restore <file> throws away your uncommitted changes and returns it to the last committed state - the safe undo that makes experimenting fearless, because you know a working version is one command away. If you need to inspect an older commit, you can check it out by its hash and look around. Because every commit is a complete snapshot, none of this is risky in the way overwriting files by hand is.

There is more to git - branches let you develop a new feature in isolation without disturbing your working version, and pull requests on GitHub let a team review changes before merging - but you do not need them on day one. They build naturally on the same add/commit/push loop once you collaborate or want to try a big change safely. For a solo designer, the honest minimum is powerful enough: commit often with clear messages, push to back up, and lean on log, diff and restore when you need to understand or undo. That alone means you never truly lose work or wonder what changed again.