Getting Started with Version Control

Every developer eventually creates a folder called project-final-v2-REAL. Version control is how you stop doing that.

Before Git, keeping track of changes meant copying folders and hoping you could remember which copy was the good one. Version control replaces that with a proper history: every change you save gets a timestamp, an author, a description, and a full snapshot you can return to. It works on solo projects and it becomes essential the moment a second person touches the same files.

What Git Actually Does

Git keeps a database of snapshots. When you save a change, called a commit, Git records what every tracked file looked like at that moment along with a message explaining why you made the change. The history is a chain of these snapshots, and you can jump back to any point in it. Nothing is overwritten, which is why Git feels safe once you trust it: undoing a mistake is a matter of moving back to a commit where things worked.

Git runs entirely on your own machine. A service like GitHub, GitLab, or a self-hosted Forgejo instance stores a copy of that history somewhere other people can reach, but the version control itself works fine with no network connection at all. That distinction confuses a lot of beginners, so it's worth internalizing early: Git is the tool, the hosting service is where you push a copy of what the tool produced.

The Four Commands That Cover Most Days

Git has well over a hundred commands. Realistically, four of them handle the overwhelming majority of daily work.

• git status shows what's changed since your last commit and what's staged to be committed next. Run it constantly. It's the cheapest way to know where you stand.
• git add stages the specific changes you want in your next commit. Staging separately from committing is what lets you split a messy afternoon into two or three clean, focused commits.
• git commit records the staged changes with a message. This is the snapshot.
• git push sends your commits to the shared copy so other people, and your other machines, can get them.

Add git pull to bring down other people's work and you have the full loop. Everything else is either a variation on these or a tool for fixing something that went wrong.

Write Commit Messages Someone Can Use

A commit message is a note to the next person who runs git log trying to figure out when a behavior changed and why. "fix" and "updates" tell them nothing. A useful message says what changed and, when it isn't obvious, why: "fix timezone offset in invoice date rendering" beats "fix bug" every time.

The convention most teams settle on is a short summary line under about 70 characters, then a blank line, then any additional detail. Keep the summary in the imperative: "add retry logic," not "added retry logic." It reads oddly at first and stops mattering within a week, but it matches what Git itself generates for merges and reverts, so the history stays consistent.

Branches Are Cheaper Than You Think

A branch is a movable pointer to a commit. Creating one costs almost nothing, which is why the standard workflow is to make a branch for each piece of work rather than committing everything to the main line. You work on your branch, the main branch stays in a known-good state, and when your work is ready you merge it back.

This matters most when something urgent comes up mid-task. If your half-finished feature lives on its own branch, you can switch to main, branch off a fix, ship it, and come back to exactly where you left off. Without branches, that same interruption means either committing broken code or losing your place.

What to Keep Out of the Repository

Not everything in your project folder belongs in version control. A .gitignore file tells Git which paths to skip. The usual candidates:

• Dependency folders such as node_modules or .venv, which get reinstalled from a lockfile.
• Build output and compiled artifacts, which get regenerated.
• Local editor and OS files like .DS_Store or .idea/.
• Anything holding a secret: API keys, tokens, database passwords, .env files.

That last one deserves emphasis. A secret committed to Git stays in the history even after you delete the file in a later commit, and if the repository was pushed anywhere, assume the secret is compromised and rotate it. Set up .gitignore before your first commit rather than after.

Fixing the Two Mistakes Everyone Makes

You committed with a bad message. If you haven't pushed yet, git commit --amend lets you rewrite the most recent message. Once it's pushed and other people have pulled it, leave it alone; rewriting shared history creates more confusion than a bad message ever will.

You committed something you shouldn't have. git revert creates a new commit that undoes the changes from an earlier one. It's safe on shared branches precisely because it adds to the history instead of rewriting it. Reach for git reset only on commits you haven't shared.

A First Week That Builds the Habit

Initialize a repository in a small personal project, even one nobody else will see. Commit after each change that leaves the project in a working state, and write a real message every time. Run git log at the end of the week and read your own history. If you can tell what you did each day from the messages alone, the habit is working.

The reason to practice on something low-stakes is that Git's error messages assume you already understand its model, and the first few times you get confused you want the cost of being confused to be zero. Once the basic loop is automatic, branches and merges stop feeling like separate topics and start feeling like the obvious next step.