Git for Non-Developers: A Human Guide to Version Control

Git is a version control system that tracks file changes over time. Unlike normal file saving, git takes permanent snapshots called commits that can always be revisited. Branches create parallel versions of a project that can be worked on independently and merged later. Git works on any text file, making it useful for essays, notes, and project plans in addition to code. The mental model is parallel universes: each branch is a separate timeline where changes stay contained.

You made a branch. Made some changes. Committed them. Switched back to where you started.

The changes were gone.

You stare at the terminal like it personally betrayed you. “I committed them. I watched the commit happen. Where did they go?”

Here’s the thing nobody tells you: the changes didn’t go anywhere. They’re still there, sitting on their branch, exactly where you left them. You just aren’t on that branch anymore. You’re on a different branch. A different version of reality.

That’s the mental model that makes Git click.

What Git actually is

Git is a version control system. It tracks changes to files over time, so you can see what changed, when, and why. And if something breaks, you can go back.

Most explanations stop there and call it a “save history.” That’s not wrong, but it’s missing the spatial part. Git isn’t a stack of saves. It’s more like parallel universes.

A repository (or “repo”) is just a folder that Git is watching. You have a project folder. You run git init inside it. Now Git knows about every file in that folder. That’s a repository.

Commits: snapshots, not saves

When you save a file in a normal app, you overwrite what was there before. Git works differently.

A commit is a snapshot. When you commit, Git takes a picture of every tracked file at that exact moment and stores it permanently. The old snapshot doesn’t disappear. It’s still there.

This means you can always go back. Every commit is a point in time you can return to. This permanence also means that if you accidentally commit something sensitive, deleting it later isn’t enough. How to Remove Sensitive Files from a Public Repo covers how to actually scrub history.

To commit in Git, you do it in two steps. First you “stage” what you want to include, then you commit it with a message describing what you did:

git add filename.txt       # stage a specific file
git add .                  # stage everything that changed
git commit -m "Add intro section to essay"

The message matters. Future you will thank present you for writing something specific instead of “updates.”

To see your commit history:

git log

This shows every commit with its ID (a long hash like a3f8c2d), who made it, when, and the message.

Branches: the parallel universes part

A branch is where Git gets interesting. Think of your project as having a main timeline. The default branch is usually called main (or master in older repos). That’s your main universe.

When you create a branch, you’re spinning up a parallel universe. It starts as an exact copy of wherever you are. But from that point forward, anything you commit in that branch stays in that branch. Main doesn’t know it happened. It’s in a different dimension.

git branch new-intro       # create a branch called new-intro
git checkout new-intro     # switch to it

Or the shorter version that does both at once:

git checkout -b new-intro

(Newer versions of Git use git switch instead of git checkout for this, but checkout still works everywhere.)

Now you’re on new-intro. Make changes, commit them. Try a completely different direction. Break things. It doesn’t matter. You’re in your own universe.

To see what branches exist:

git branch

The one with an asterisk is the branch you’re currently on.

To switch back to main:

git checkout main

And now your files look exactly like they did before you created the branch. The changes you made are still there. They’re just on a different branch. A different universe. You can go back anytime.

This is what trips people up the first time. The changes aren’t gone. They’re just not where you’re standing right now.

HEAD: where you are right now

HEAD is Git’s way of saying “the current commit you’re looking at.” It usually points to the tip of whatever branch you’re on. When you switch branches, HEAD moves. When you commit, HEAD advances.

You’ll see HEAD in error messages and log outputs. It just means “here.”

Merging: when universes collide

At some point you’ll want to bring your branch’s changes back into main. That’s a merge.

You switch to the branch you want to merge into (usually main), then tell Git which branch to bring in:

git checkout main
git merge new-intro

Git takes both timelines and combines them. If you changed different parts of different files, it handles this automatically. If you changed the same part of the same file in both branches, you get a merge conflict and Git asks you to resolve it manually. (It looks scarier than it is. Git shows you both versions and you pick which one to keep.)

After a successful merge, your changes from new-intro are now part of main. Both universes are one.

The terminal: less scary than it looks

The terminal is the text-based interface where you type Git commands. On a Mac it’s called Terminal (or you might use iTerm). On Windows it’s Command Prompt, PowerShell, or Git Bash.

You type a command, hit Enter, and something happens. That’s it.

If you’re using GitHub Desktop or the Source Control panel in VS Code, there’s a GUI layer on top of all of this. Under the hood it’s running the same commands. Understanding what the commands actually do makes the GUI make more sense.

Try this yourself

The fastest way to build intuition for Git branches is to run through this once:

# Create a folder and initialize a repo
mkdir git-test
cd git-test
git init

# Create a file and make your first commit
echo "Hello, this is my file." > notes.txt
git add notes.txt
git commit -m "First commit"

# Create a branch and make a change
git checkout -b experiment
echo "Trying something different." >> notes.txt
git add notes.txt
git commit -m "Add experimental line"

# Switch back to main - notice the file changes
git checkout main
cat notes.txt   # the experimental line is gone

# Switch back to the branch - it's still there
git checkout experiment
cat notes.txt   # the experimental line is back

# Merge it into main
git checkout main
git merge experiment
cat notes.txt   # now both lines are in main

Run through that once and the mental model snaps into place. The file actually changes when you switch branches. You can see it happen.

Why this matters for non-code work

Git works on any text file. Essays. Notes. Project plans. Scripts. If it’s text, Git can track it.

You could branch your essay, try a completely different intro, hate it, and switch back to the original without ever touching it. The bad version still exists, on its own branch, in its own universe. You’re back to the original like nothing happened.

That’s the thing nobody tells you when they explain Git as a “developer tool.” It’s actually a writing tool. A thinking tool. Anything where you want to try something without committing to it.

You could delete everything, set fire to the whole branch, completely wreck it. Your main branch doesn’t care. It’s in a different dimension.

Further reading

• The Git Handbook from GitHub, a clear overview of the core concepts
• Atlassian’s Git tutorials go deep on every topic (branches, merging, rebasing, remotes)
• Official Git documentation including the free Pro Git book, which is the most thorough resource available
• GitHub Desktop if you want a GUI that handles the commands for you while you’re learning
• Oh My Git! a free, open-source game that teaches Git by making you play through branching scenarios

Common Questions

What is git in simple terms?

Git is a version control system that takes permanent snapshots of your files called commits. Instead of overwriting saves, every commit is a point in time you can return to. Branches let you try different approaches without affecting the main version.

What is a git branch?

A branch is a parallel version of your project. It starts as a copy of wherever you are, and from that point, any changes stay isolated in the branch. The main branch is unaffected. You can merge changes back when ready or discard the branch entirely.

Why do my changes disappear when I switch git branches?

They haven’t disappeared. Your changes are on the branch where you committed them. Switching to a different branch shows that branch’s version of the files. Switch back to see your changes again. This is git working exactly as designed.

Can non-developers use git?

Yes. Git works on any text file: essays, notes, scripts, project plans. You can branch an essay, try a different intro, decide you hate it, and switch back to the original. The main version stays untouched regardless of what you do on other branches.

What is a git commit?

A commit is a snapshot of every tracked file at a specific moment. Unlike a normal save that overwrites the previous version, a commit is permanent and stored in the project history. You create one with git add (stage files) then git commit -m "description".