Git and GitHub the Safe Way, Ch. 1: Snapshots, Not Sync
Part of Git and GitHub the Safe Way, a short book on git, GitHub, and the habits that keep a repository from hurting you.
People get into trouble with git because they think it is something it is not. Three wrong pictures account for most of the pain, and it is worth naming them before learning a single command.
Three things git is not
It is not a sync folder. Dropbox and iCloud copy whatever is in a folder, continuously, whether you meant it or not. git copies nothing until you ask, and it copies exactly what you asked for. That is the whole point: a secret that is in your folder is not in git until you put it there, and a change you did not mean to make is not in the history until you commit it. Everything in chapters 3 and 4 depends on that gap.
It is not a backup. A repository on your laptop dies with the laptop. Only a copy somewhere else, GitHub or another machine, is a backup, and only the commits you have pushed are in it. “I committed it” and “it is safe” are different sentences.
It is not a server. git works entirely on your machine. GitHub is a website that happens to host repositories and adds the things git does not have: accounts, permissions, pull requests, reviews, and a place for strangers to meet. You can use git for years without GitHub. You cannot use GitHub without understanding git.
What git is
git keeps the history of a folder as a chain of snapshots. Each snapshot records every file as it was at one moment, plus a message, plus who made it and when. The snapshots are called commits, and once a commit exists it never changes: it has a fingerprint (that a743d22 you will see in git log) computed from its contents, and changing a single byte would give it a different fingerprint. That immutability is a feature. History you cannot quietly rewrite is history you can trust.
The folder git is watching is a repository. The current line of snapshots is a branch, and there can be several; the one everyone agrees is the real one is almost always called main. A copy of the repository on another machine or on GitHub is a remote, usually named origin. Getting a copy is cloning; sending your new commits to the remote is pushing; fetching other people’s is pulling.
GitHub adds two words. A fork is your own copy of someone else’s repository on GitHub, where you have permission to push. A pull request is a proposal that the owner take some commits from your branch or fork into theirs; it is where the reading, the arguing and the merging happen.
That is the whole vocabulary. Nine words: repository, commit, branch, remote, clone, push, pull, fork, pull request. Everything else is detail.
The four places a change can live
This is the model that makes the rest of the book make sense. A change to a file passes through up to four places, and git has a different command for moving between each pair:
- The working tree. Your folder, the files as your editor sees them. You change something here by saving.
- The staging area. The list of exactly what will go into the next commit.
git addputs a change here; nothing is on the list until you add it. The list is why a commit can be smaller than “everything I touched today.” - History. The commits.
git committurns the staged list into a snapshot. From here on, it is permanent, and so is anything you put in it by mistake. - The remote. GitHub’s copy.
git pushsends commits there. From here on, other people can see it, and so can their caches, their forks and their CI logs.
Each boundary is a chance to check. Safety in git is mostly a matter of looking before crossing each one: git status before you add, git diff --staged before you commit, git log before you push. The chapters ahead turn those three looks into habits.
The further right a mistake travels, the more it costs to undo. A wrong edit in the working tree costs one command. A wrong commit costs a slightly different command. A wrong push costs a new commit and an explanation, because other people may already have it. A pushed secret costs a new secret, because undoing the push does not un-see it. Chapter 8 is the undo at each stage; chapter 4 is why you want to catch the worst case at stage one.
What “safe” means, in practice
The four promises from the introduction map onto this model:
- No secret lands in a repository is a stage-one and stage-two habit: look at what you are adding, keep the files that hold secrets out of the folder git watches, and let a scanner check the staging area before every commit.
- No work is lost is a stage-three property: commits are permanent, and git keeps a log of where you have been even when you move away from a commit, so nearly everything is recoverable if you know where to look.
- Nothing changes on main by surprise is a stage-four setting: GitHub can refuse pushes straight to
mainand insist on a pull request with a review and a passing check, for everyone, including you on a bad day. - Nobody acts as you is about the keys and tokens that let a machine push as your account, and about turning on the second factor that makes a stolen password useless.
None of this needs discipline, which is good, because discipline fails at 6 p.m. on a Friday. It needs a setup done once (chapter 2), a loop that includes three glances (chapter 3), a scanner that runs itself (chapter 4), and a few GitHub switches set to the safe position (chapters 6 and 9).
Conclusion
git is a chain of permanent snapshots you choose to take, not a sync folder and not a backup. A change moves from your folder to the staging list to history to GitHub, and each step is a place to look. Next: setting up git and GitHub once, properly, so that everything after is easier.