Git Basics: Commits, Branches, and Why You Need Them

Welcome back!

Let me guess: somewhere on your computer there's a folder that looks like this — project_final.zip, project_final_v2.zip, final_v2_REALLY_final.zip. We've all been there. You wanted to try something risky without losing the working version, so you made a copy. Then a copy of the copy. Then you changed something in the wrong one.

Git exists to end that chaos. It's a version control system — think of it as a time machine plus save points for your code. Save your progress at any moment, rewind to any earlier save, and try wild experiments knowing you can always get back to a working state. Today you'll learn the handful of commands you'll use every day, and the mental model that makes them click.

The mental model: four words

• Repository (repo): the project's entire history, stored in a hidden .git folder inside your project. This is the time machine itself.
• Working copy: the normal files you see and edit. Business as usual — Git just watches quietly.
• Staging area: a waiting room. Before saving, you choose which changes belong in the next save. This is what lets you save related changes together instead of everything at once.
• Commit: a save point — a snapshot of your staged files, with a message describing what changed and a permanent place in history.

So the rhythm of Git is simply: edit files, stage the ones you want, commit with a message. Repeat forever.

The everyday flow

# once, to start tracking a project
git init

# see what's changed since your last commit
git status

# stage the changes you want to save
git add Program.cs
git add .          # or stage everything

# save a snapshot with a message
git commit -m "Add welcome message to home page"

That's it — status, add, commit covers the vast majority of your Git life. Run git status constantly; it always tells you where you are and usually hints at what to do next.

Branches: parallel timelines

Here's where Git gets genuinely powerful. A branch is a parallel timeline for your code. Want to try a redesign, a risky refactor, a weird idea? Create a branch, experiment freely, and your main timeline stays untouched. Love the result? Merge it back in. Hate it? Delete the branch and pretend it never happened.

# create a new branch and switch to it
git switch -c new-idea

# ...edit files, commit as usual...

# happy with it? bring it back to main
git switch main
git merge new-idea

Branches are cheap and instant, so use them generously. One idea, one branch — no more being afraid to touch working code.

The file that saves you embarrassment: .gitignore

Not everything belongs in history. Build outputs, temporary files, and — most importantly — secrets like API keys should never be committed. A plain text file named .gitignore in your project lists patterns Git should pretend not to see (like bin/ or *.log). Add one early; starter templates for every language are easy to find.

Git vs GitHub: the tool vs the hosting

Beginners often blur these together, so let's separate them. Git is the tool on your computer — everything above works offline, no account needed. GitHub (like its cousins GitLab and Bitbucket) is a website that hosts a copy of your repository online, so you can back it up, share it, and collaborate.

Two commands connect the worlds: git push uploads your commits to the hosted copy, and git pull downloads commits others have added. Same time machine, now with an off-site backup.

Habits that pay off immediately

• Commit small and often. A commit that changes one thing is easy to understand, easy to review, and easy to undo. "Fixed everything" is none of those.
• Write messages that say why. The diff already shows what changed. "Increase timeout to stop login failures on slow networks" will thank you in six months; "changed stuff" will not. (This is the same care we bring to naming things well — writing for the humans who come after you.)
• Commit before you experiment. A clean commit is a free save point. Take it before anything risky.

Here's the encouraging truth: you now know more Git than many people use in their entire careers. Install it, run git init in any project, and make your first commit today — future you will be grateful. For a natural next step, read Clean Code: Naming Things Well to make those commits shine, or jump to Docker Explained to see the next tool in a developer's everyday kit.