Deadheads tape every show, because the version of a song that happened tonight will never happen again. Git is the taper’s rig for your codebase: every change recorded, every version recoverable, nothing lost to “wait, what did I change last Tuesday?” This lesson puts an existing site’s code under version control from zero. You’ll need a terminal and the site’s code on your computer — and note that Git tracks code, not your database, so it complements rather than replaces a backup that actually restores.

Install Git and introduce yourself

Check whether you already have it — macOS and most Linux distributions do:

git --version

If not: macOS offers to install it the first time you run that command, Debian/Ubuntu wants sudo apt install git, Windows gets it from git-scm.com. Then tell Git who you are (this labels your changes, nothing more) and set the modern default branch name:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Initialize the repository

From the root folder of your site’s code:

cd ~/Sites/my-site
git init

That creates a hidden .git folder where all history will live. Nothing about your site changed; Git is just watching now.

Tell Git what to ignore

Some files must never enter history: anything holding passwords, plus bulky stuff that doesn’t belong there. Create a file named .gitignore in the same folder:

# Secrets — never commit credentials
.env
*.sql
*.sql.gz

# Generated or bulky — rebuildable, not history
node_modules/
.DS_Store

Every stack has its own additions — WordPress folks ignore wp-config.php and wp-content/uploads/, Drupal folks ignore settings.local.php and sites/default/files/. The test for any file is: does it contain a secret, or can it be regenerated? Either way, it stays out.

Make the first commit

A commit is a snapshot with a message. Stage everything, look at what you’re about to record, then record it:

git add .
git status
git commit -m "First commit: the site as it stands today"

Read the git status output before committing — if a password file shows up in green, fix the .gitignore first. Better a minute now than a secret in history forever.

Adopt the small-commits habit

From here on, commit every distinct change by itself: one plugin update, one commit; one CSS fix, one commit. The message says why, because the diff already says what:

git add path/to/changed-file
git commit -m "Raise upload limit for the events team's PDFs"

Small commits are what make history useful. When something breaks, “which of these five one-line changes did it” is an easy question; “what’s in this one commit called misc fixes” is not.

Push a copy somewhere off your machine

History on one laptop is history one spilled coffee from gone. Create a free private repository on GitHub or GitLab, then connect and push:

git remote add origin git@github.com:YOUR-USERNAME/my-site.git
git push -u origin main

After this, plain git push sends new commits up. Off-site history, same principle as any good backup.

Verify by undoing something on purpose

The whole point of Git is the undo, so prove it works. Open any file, delete a paragraph, save. Then:

git diff
git restore path/to/that-file

git diff shows exactly what you broke, in red; git restore puts it back like it never happened. Open the file and confirm the paragraph returned. That round trip — break, see, restore — is the verification, and it’s also the muscle memory you’ll be glad for the day the change you need to undo wasn’t on purpose.