Git for Beginners: Pull, Commit, Push, and Where the Rest of Your Files Actually Belong
TL;DR
Git and GitHub exist so your work never lives in exactly one place. The whole job, every session, is pull, edit, commit, push, and the one rule that actually matters is this: push before you walk away from a computer, pull before you sit down at one. Get that habit wrong across two machines and you can quietly lose a day's work without a single error message. We have turned the full version of this into a free PDF, built for someone who has never touched Git, and it covers the part almost nobody explains: where your documents and your passwords should live instead.
Download the free Git for Beginners guide, pull, commit, push, and the file-storage rules, →
The night's work that vanished
A client called me in a panic last month.
She had rewritten her homepage the night before, on her laptop, at home. Proud of it. Sent nobody a message about it because she was going to show the team in the morning.
She got to the shop, opened the desktop, and it was gone.
Not deleted. Worse. It had simply never arrived.
Here's the thing. Nothing was actually wrong. Git had done exactly what it was built to do. She had made her changes and closed the laptop lid without pushing them anywhere, so those changes existed in precisely one place: that laptop, switched off, at home. The desktop at the shop had no way of knowing they existed, because nothing was ever sent to GitHub.
That is the entire lesson in one sentence. A computer you are not sitting at right now is not a backup. GitHub is.
The three words behind everything
Git tracks every change you make to a set of files, on your computer, one labelled point at a time. GitHub stores the one master copy of that history, in the cloud, that everyone works from.
Three words carry the whole system:
- pull, bring the latest version down onto whichever computer you are sitting at
- commit, save your changes as a labelled point in your own history
- push, send those saved changes up to GitHub, where they become the new truth
The loop, every session, on any computer: pull, edit, commit, push. Four steps. That is the whole job when you are on one machine.
Where it actually breaks: the second computer
The four-step loop above has a hidden assumption baked into it. It assumes you are always sitting at the same computer.
Add a second laptop, a home desktop, or a second person on the same project, and that assumption breaks quietly, not loudly. Each computer holds its own private copy of the history until you push or pull. Nothing announces that your laptop and your desktop have drifted apart. They just have, until you look.
So the rule, the one that would have saved my client's evening:
Pull before you start working on any machine. Push before you walk away from it.
Not complicated. Just easy to skip, because nothing punishes you for skipping it until the moment it matters.
Sound familiar? It's the same trap as the untitled document you swore you saved, except Git actually gives you a way to check. Run git log -1 on any machine and it tells you, in plain text, exactly what the last saved change was and when. Compare that between two computers and you know instantly which one is behind.
See where AI fits in your business. Free.
A 45-minute audit. We map the highest-value automations and what they're worth in time and money. No pitch, no pressure.
The part almost nobody explains: where the rest of your files go
Here's the bit that catches even people who have used Git for years, because nobody tells them outright: Git is not where the rest of your business lives.
Three jobs, three homes:
- Code and website source, Git and GitHub. Every change tracked, everyone working from one shared version.
- Documents, spreadsheets, client deliverables, marketing assets, Google Drive, SharePoint, OneDrive, or Dropbox. Built for people who will never touch Git and do not need to.
- Passwords, API keys, login tokens, the local machine only. Not Git. Not a shared drive. Nowhere that syncs.
Git tracks changes line by line inside text files. That is exactly what code is, and exactly what a Word document, a spreadsheet, or a photo is not. Feed Git a folder of documents and every save looks like "the whole file changed again", because Git cannot see inside a binary file the way it sees inside code. Drive and SharePoint solve a different problem entirely: real-time editing by people who have never written a commit message in their life and never will.
The rule of thumb: if a client or a non-technical colleague needs to open and edit something directly, it belongs in Drive or SharePoint, not Git.
Credentials get their own rule, and it's stricter
Passwords and API keys usually live in a single file called .env, sitting quietly in a project folder, deliberately left out of Git by a line in a file called .gitignore. That is why cloning a project onto a new laptop never brings your logins with it. git clone only ever fetches what is in GitHub, and .env was never there.
Do not put it on a cloud drive to work around that either. A shared drive syncs to every device signed into the account, plus everyone that folder has ever been shared with. A password uploaded there, even for ten minutes, is effectively out of your control.
If a new computer genuinely needs the same credentials, move the file physically. A USB drive, not an inbox. Copy it across, then delete it from the USB drive straight away, before it sits in a drawer somewhere. Email and chat apps keep their own copies in sent folders and backups for years after you have forgotten you ever sent anything.
And if a secret ever does end up committed to Git by accident? Do not just delete the file and commit again. The old value is still sitting in the history. Tell whoever owns the project immediately so the key can be changed. Same principle as a lost house key: you change the lock, you don't just hide the old key harder.
Where AI earns its keep here
The mechanical part of this, the pulling and pushing, was always going to get automated eventually. That's not the interesting bit.
The interesting bit is the moment it goes wrong. A merge conflict used to mean opening a file full of <<<<<<< markers and hoping you understood which half to keep. Now you open the file in an AI coding assistant and say "resolve the conflict here, keep both changes where that makes sense", and it does the reading for you.
That's the whole philosophy behind an AIOS in one small example. AI augments. It doesn't replace. The judgement calls, what to build, what a client actually needs, still belong to a person. The mechanical parts, the four-step loop, the conflict markers, the "which file changed last", those are exactly what should never eat another minute of your day.
Pin this above the desk
We built the whole thing properly: the four-step loop, the multiple-computer habit, where documents belong, where credentials belong, and the .env file explained without jargon. The last page is a one-page cheat sheet, made to be printed and pinned above the desk.
Download the free Git for Beginners guide, pull, commit, push, and the file-storage rules, →
Hand it to the next person on your team who says "I don't really get GitHub." Then ask one question: does everyone on your team know which computer holds the truth right now?
If the answer is "not sure, " that's your worst task. Start there.
Live with passion & AI,
Brett
Host a podcast? Have Brett on as a guest.
Straight talk on implementing AI in real SMEs, no jargon, plenty of receipts from the businesses we run.
Frequently asked questions
What is the difference between Git and GitHub?
+
Git is the program on your computer that tracks every change you make. GitHub is the website that stores the master copy of that history in the cloud. Git does the tracking, GitHub is the shared place everyone's changes end up.
Do I need to know how to code to use Git?
+
No. The everyday routine is four commands: pull, add, commit, push. Most people who edit a site through an AI coding assistant never type anything more complicated than that, and the assistant can run the commands for you if you ask it to.
What happens if I forget to push before switching to another computer?
+
Your changes stay trapped on the machine you made them on. The other computer has no way to know they exist until you push them, because nothing was ever sent to GitHub. Sit at the second machine, pull, and you will see the version from before you made those changes.
Should I store passwords and API keys in Git or Google Drive?
+
Neither. Credentials live only on the local machine that needs them, usually in a file called .env that is deliberately excluded from Git. Cloud drives sync to every device on the account, which is exactly what you do not want for a password. If a credential has to move computers, copy it by hand on a USB drive and delete it from the drive afterwards, never by email.
What is a merge conflict, and is it dangerous?
+
It is Git flagging that two people, or two sessions on different computers, edited the exact same lines of the same file. It looks alarming the first time but it is not dangerous, nothing is lost. The simplest fix for a beginner is to open the file in an AI coding assistant and ask it to resolve the conflict, keeping both changes where that makes sense, then commit the result.
Brett is a four-time founder (Darra Tyres, Gladfish, EzyTrac, Anaboo) and the operator behind AIOS, Anaboo's AI Operating System. He writes from inside the build, installing AI in his own businesses first and reporting back what actually moves the numbers. Based between Singapore, the UK and Australia.
