Git for Beginners: Version Control Explained

Git is installed on virtually every developer’s computer. It’s required for contributing to open source, working on a team, and deploying most applications. And yet most beginners either avoid it, use it by muscle memory without understanding it, or treat it like a magic incantation that either works or doesn’t.

Understanding how Git actually works — what it’s doing and why — makes the commands obvious rather than arbitrary.

The Problem Git Solves

Before version control, developers managed code changes manually. Duplicate folders named project-final, project-final-v2, project-ACTUALLY-final. Emailing zip files between collaborators. Manually merging changes and hoping nothing got overwritten.

Git solves this by tracking every change to every file over time, enabling multiple people to work on the same codebase simultaneously, and providing a complete history you can navigate, compare, and revert.

Think of Git as a time machine for your code. Every time you make a significant change, you save a snapshot. You can always go back to any previous snapshot. Multiple people can make changes in parallel and merge their work together.

How Git Thinks About Files

Git tracks three states your files can be in:

Working directory: The actual files on your computer that you edit.

Staging area (index): A preparation zone where you assemble changes before saving them. You explicitly choose which changes to include in the next snapshot.

Repository: The database of snapshots (called commits) Git maintains. Once something is committed, it’s in the permanent record.

The workflow is: edit files in the working directory → stage the changes you want to save → commit them to the repository.

Commits: Git’s Unit of History

A commit is a snapshot of your staged changes, stored permanently in the repository with:

• The changes themselves
• A message you write describing what changed and why
• The author and timestamp
• A unique ID (a 40-character hash like a3f8c2d...)
• A pointer to the previous commit

These linked commits form a chain — the complete history of your project. You can always go back to any commit, compare any two commits, or understand exactly who changed what and when.

Good commit messages are short summaries of what changed and why: "Add password validation to signup form" rather than "fixed stuff" or "update".

The Core Commands

Starting Out

git init

Initialize a new Git repository in the current directory. Creates a hidden .git folder that stores everything.

git clone https://github.com/user/repo.git

Copy an existing repository from a remote location to your computer. This is how you get a copy of someone else’s project.

The Daily Workflow

git status

See which files have been modified, which are staged, and which are untracked. Run this constantly — it’s your orientation.

git add filename.js
git add .

Stage changes. git add filename.js stages one file. git add . stages all changes in the current directory. Be intentional — review git status before staging everything.

git commit -m "Describe what changed and why"

Save staged changes as a new commit. The -m flag lets you write the message inline.

git log

See the commit history. Shows commit IDs, authors, dates, and messages. Press q to exit.

Working with Remotes

A remote is a copy of the repository hosted elsewhere — usually GitHub, GitLab, or Bitbucket.

git push origin main

Upload your local commits to the remote repository. origin is the default name for the remote; main is the branch name.

git pull

Download and merge changes from the remote into your current branch. Run this before starting work to make sure you have the latest changes.

Undoing Things

git diff

See exactly what changed in your working directory — line by line, before you stage anything.

git restore filename.js

Discard changes to a file in the working directory, reverting it to the last committed version. Destructive — changes are lost.

git revert abc123

Create a new commit that undoes the changes from a specific commit. Safe because it doesn’t rewrite history — it just adds a reversal commit.

Branches: Working in Parallel

A branch is an independent line of development. The default branch is called main (or master in older repositories).

Branches let you work on a feature or fix without affecting the main codebase. When the work is done and tested, you merge the branch back into main.

git branch feature/user-auth

Create a new branch.

git checkout feature/user-auth
# or the modern equivalent:
git switch feature/user-auth

Switch to a branch. Your working directory updates to reflect that branch’s state.

git checkout -b feature/user-auth

Create and switch to a new branch in one command.

git merge feature/user-auth

Merge a branch into your current branch. Run this while on main to merge your feature branch.

git branch -d feature/user-auth

Delete a branch after merging. Keeps things tidy.

Merge Conflicts

A merge conflict happens when two branches modify the same part of the same file. Git doesn’t know which version is correct, so it asks you to decide.

Conflict markers look like this in the affected file:

<<<<<<< HEAD
The version from your current branch
=======
The version from the branch being merged
>>>>>>> feature/user-auth

Resolve by editing the file to keep what you want (removing the markers), then staging the resolved file and committing.

Most code editors (VS Code especially) have visual merge conflict tools that make this much easier than editing raw text.

GitHub: Git in the Cloud

Git is the tool. GitHub is a hosting service for Git repositories, with added collaboration features:

Pull Requests (PRs): A formal way to propose merging a branch. Others can review your code, leave comments, and approve or request changes before the merge happens.

Issues: Bug reports and feature requests, linked to code and PRs.

Actions: Automated workflows that run when you push code — running tests, building the project, deploying.

GitHub is where most open source projects live and where most professional teams collaborate. Understanding Git is the prerequisite; GitHub is where you use it.

A Typical Feature Development Flow

# Start from up-to-date main
git checkout main
git pull

# Create a feature branch
git checkout -b feature/add-search

# Make changes, check status often
git status
git diff

# Stage and commit as you go
git add src/components/Search.svelte
git commit -m "Add search component with debounced input"

git add src/routes/+page.svelte
git commit -m "Wire search component to homepage"

# Push branch to remote
git push origin feature/add-search

# Open a Pull Request on GitHub, get it reviewed, merge it

Common Beginner Mistakes

Committing too infrequently. A commit should represent one logical unit of change. Commit often — it’s easier to combine small commits than split a large one.

Committing directly to main. Use branches. Direct commits to main make collaboration messy and mistakes harder to isolate.

Not writing meaningful commit messages. Your future self will read these. Write them for a person who needs to understand what happened without reading the code.

Using git add . without checking git status first. You might accidentally commit files you didn’t intend to — API keys, build artifacts, large files. Review before staging.

Panic-pushing when conflicts arise. Merge conflicts look scary but are almost always straightforward. Read the conflict markers carefully, keep the right version, remove the markers, save, and commit.

---

Git has a learning curve, but it’s front-loaded. The daily workflow — status, add, commit, push, pull — becomes muscle memory quickly. Branches and merging take a bit longer to internalize. Put in the time early: every hour spent learning Git properly saves dozens of hours of chaos later.