Git Crash Course for Beginners: From Zero to Hero — The Basics (Part 1)

What Exactly Is Git, and Why Should You Care?

Before you touch a single command, you need to understand what problem Git was built to solve — because knowing the "why" makes every command make sense.

In 2005, Linus Torvalds — the same person who wrote the Linux kernel — needed a version control system for the Linux project. Existing tools were too slow, too centralized, or required paid licenses. So he built Git in about 10 days.

The core insight: your code's history is as valuable as the code itself.

Think about what happens without version control:

• You refactor a function, break something, and can't remember what you changed
• Two teammates edit the same file — the last person to save "wins," and the other person's work is gone
• You ship a bug to production and have no idea what changed between yesterday and today

Git solves all three. It's a distributed version control system — meaning every developer has a full copy of the entire project history on their machine. Not just the latest version. Every commit, every branch, every change, going back to day one.

That distribution is what makes Git different from older centralized tools like SVN. If the server goes down, you're not blocked. Your local history is complete and authoritative.

The Mental Model You Need Before Writing Any Commands

Most Git tutorials throw commands at you immediately. That's backwards. Git has a specific mental model, and if you understand it, the commands become obvious.

The Three States of Your Code

Git tracks your files across three distinct zones:

Working Directory: This is just your normal folder. You edit files here. Git is watching, but hasn't recorded anything yet.

Staging Area (also called the Index): This is Git's "draft" area. Before you commit, you explicitly choose which changes to include. This gives you surgical precision — you can commit changes to auth.js without committing your half-finished changes to dashboard.js.

Repository: The permanent, immutable record. Once you commit, that snapshot is stored in Git's history forever (unless you explicitly rewrite history, which is a Part 3 topic).

This three-stage design is what confuses beginners the most. "Why do I need to git add before git commit?" — because staging is deliberate. It forces you to think about what you're committing, not just that you're committing.

Commits Are Snapshots, Not Diffs

Another critical mental model: a Git commit is a snapshot of your entire project at a moment in time — not a list of changes. Under the hood, Git is efficient about storage (it uses content-addressed hashing and only stores what changed), but conceptually, think snapshot.

Each commit has:

• A unique SHA-1 hash (a 40-character ID like a3f9c12...) — its fingerprint
• A parent commit it points back to (forming a chain — the history)
• A commit message — written by you, for future you
• A tree — the actual snapshot of files

That chain of commits is your project history.

Installing Git and First-Time Setup

Install Git

macOS:

1# Option 1: Xcode Command Line Tools (simplest)
2xcode-select --install
3
4# Option 2: Homebrew (recommended if you already use it)
5brew install git

Windows: Download the installer from git-scm.com. During setup, keep the defaults — especially "Git from the command line and also from 3rd-party software." This adds Git to your system PATH.

Linux (Debian/Ubuntu):

1sudo apt update && sudo apt install git

Linux (Fedora/RHEL):

1sudo dnf install git

Verify the install:

1git --version
2# git version 2.44.0

Configure Git — Do This Before Anything Else

Git attaches your name and email to every commit you make. This is how collaborators (and GitHub) know who did what. Set it once, globally:

1git config --global user.name "Your Name"
2git config --global user.email "you@example.com"

Set your default branch name to main (the modern convention, replacing the old master):

1git config --global init.defaultBranch main

Set your preferred editor for commit messages (optional but useful):

1# VS Code
2git config --global core.editor "code --wait"
3
4# Vim (if you know it)
5git config --global core.editor "vim"
6
7# Nano (beginner-friendly)
8git config --global core.editor "nano"

Check your configuration:

1git config --list

These settings are stored in ~/.gitconfig — a plain text file you can edit directly anytime.

Your First Repository: git init and git clone

There are exactly two ways to get a Git repository: create one from scratch or copy an existing one.

Creating a Repository from Scratch

1mkdir my-project
2cd my-project
3git init

git init creates a hidden .git/ folder inside your project directory. That folder is Git — it contains your entire history, configuration, and metadata. Never delete it manually unless you want to nuke your history.

You'll see:

That's it. You now have a Git repo. It has no commits yet — it's a blank slate.

Cloning an Existing Repository

If you're joining a project that already exists (on GitHub, GitLab, Bitbucket, or any remote), you clone it:

1git clone https://github.com/username/repo-name.git

This does three things:

1. Downloads the entire repository (all history, all branches)
2. Creates a local folder named after the repo
3. Sets up a remote called origin pointing to the URL you cloned from

You can also clone into a specific folder name:

1git clone https://github.com/username/repo-name.git my-custom-folder

The Core Daily Workflow: status, add, commit

This is the loop you'll run hundreds of times a day. Internalize it.

git status — Your Constant Companion

Before doing anything, run git status. It tells you:

• Which files you've modified
• Which changes are staged (ready to commit)
• Which files Git doesn't know about yet (untracked)

1git status

Example output:

1On branch main
2Changes not staged for commit:
3  (use "git add <file>..." to update what will be committed)
4        modified:   src/app.js
5
6Untracked files:
7  (use "git add <file>..." to include in what will be committed)
8        src/utils.js
9
10no changes added to commit (use "git add" and/or "git commit -a")

Read this output carefully. It's Git telling you exactly what's happening and what to do next.

git add — Staging Your Changes

Move changes from the Working Directory to the Staging Area:

1# Stage a specific file
2git add src/app.js
3
4# Stage multiple files
5git add src/app.js src/utils.js
6
7# Stage all changes in the current directory (use carefully)
8git add .
9
10# Stage parts of a file interactively (advanced — covered in Part 2)
11git add -p src/app.js

After staging, run git status again. Staged files now appear under "Changes to be committed" — they're green in most terminal setups.

A common beginner trap: git add . stages everything, including files you didn't mean to commit. Be deliberate. Stage specifically what belongs in this commit.

git commit — Sealing the Snapshot

Once your staging area contains exactly what you want, commit it:

1git commit -m "Add user authentication endpoint"

The -m flag lets you write the commit message inline. Without it, Git opens your configured editor for a longer message.

Write good commit messages. This is not optional. A year from now, you'll thank yourself. The convention:

• First line: imperative mood, under 72 characters ("Add", "Fix", "Remove", not "Added", "Fixes", "Removed")
• Blank line
• Optional body: explain why, not what (the diff already shows what)

Good:

Bad:

Your commit message is documentation. Treat it that way.

Understanding Branches

A branch is just a lightweight pointer to a specific commit. That's it. No copying of files, no duplication of the codebase — just a named pointer.

When you create a repo, Git automatically creates a default branch called main. As you commit, main moves forward with you.

When you create a new branch, you're creating a new pointer at the current commit. Both branches share all prior history:

Now they diverge independently. You can switch between them instantly.

Branch Commands

1# Create a new branch
2git branch feature/user-auth
3
4# Switch to it
5git checkout feature/user-auth
6
7# Or do both in one command (modern, preferred)
8git switch -c feature/user-auth
9
10# List all branches (* marks the active one)
11git branch
12
13# Switch back to main
14git switch main
15
16# Delete a branch (after merging)
17git branch -d feature/user-auth

The git switch command is newer (Git 2.23+) and cleaner than git checkout for branch operations. You'll still see git checkout everywhere in tutorials and Stack Overflow — it works, it's just older.

Viewing History: git log

1git log

This shows your commit history: SHA hash, author, date, and message. It can get verbose. More useful variants:

1# Compact one-line per commit
2git log --oneline
3
4# Visual branch graph (incredibly useful)
5git log --oneline --graph --all
6
7# See what changed in each commit
8git log -p
9
10# Last 5 commits only
11git log -5

The --oneline --graph --all combo is the one I use most. It gives you a visual ASCII representation of your branch structure. Alias it:

1git config --global alias.lg "log --oneline --graph --all --decorate"
2# Now just run:
3git lg

Undoing Mistakes — The Beginner-Safe Commands

You will make mistakes. Git's entire purpose is to make mistakes recoverable. Here are the safe, beginner-friendly undo operations:

Unstage a file (before committing)

You staged something by accident. Unstage it:

1# Modern Git (2.23+)
2git restore --staged src/app.js
3
4# Older syntax (still works)
5git reset HEAD src/app.js

This moves the file back to "modified but unstaged." Your actual file content is untouched.

Discard changes in a file (undo edits)

You made changes to a file and want to throw them away entirely, going back to the last committed version:

1# Modern Git
2git restore src/app.js
3
4# Older syntax
5git checkout -- src/app.js

Fix the last commit message

You committed but the message has a typo:

1git commit --amend -m "Correct message here"

Only do this if you haven't pushed yet. Amending rewrites history — if others have already pulled that commit, you'll create conflicts.

The .gitignore File — What Git Shouldn't Track

Not everything in your project belongs in version control. Node modules, build artifacts, environment variables, IDE config files — these are either auto-generated, environment-specific, or sensitive.

Create a .gitignore file in your repo root:

1# Dependencies
2node_modules/
3vendor/
4
5# Build output
6dist/
7build/
8.next/
9
10# Environment variables (never commit secrets)
11.env
12.env.local
13.env.production
14
15# OS files
16.DS_Store
17Thumbs.db
18
19# IDE config
20.vscode/
21.idea/
22
23# Logs
24*.log
25npm-debug.log*

Any file or folder matching these patterns will be completely ignored by Git — it won't show up in git status, and you can't accidentally commit it.

Critical rule: Never commit .env files containing passwords, API keys, or secrets. Add .env to .gitignore on day one, every project, no exceptions.

GitHub maintains a comprehensive collection of .gitignore templates for every language and framework at github.com/github/gitignore. Use them.

The 10 Commands That Run Your Daily Git Life

If you memorize nothing else from Part 1, memorize this:

1git init                    # Start a new repo
2git clone <url>             # Copy an existing repo
3
4git status                  # What's happening right now
5git add <file>              # Stage a file for commit
6git add .                   # Stage everything (use carefully)
7git commit -m "message"     # Seal the snapshot
8
9git branch <name>           # Create a branch
10git switch <name>           # Switch to a branch
11git switch -c <name>        # Create + switch in one command
12
13git log --oneline           # View compact history

That's your entire beginner toolkit. These 10 commands handle the overwhelming majority of day-to-day Git work. Everything else builds on top of them.

What's Coming in Part 2

Part 1 gave you the foundation: the mental model, the setup, the core loop, and the basics of branching. You can now track your own projects, write clean history, and not lose work.

Part 2 goes deeper — into the operations that matter in a team setting:

• Merging branches (and the difference between merge and rebase)
• Resolving merge conflicts without panicking
• Working with remotes: git push, git pull, git fetch
• Stashing work in progress
• Reading diffs with git diff
• Branch naming conventions and workflows teams actually use

Git isn't just a file backup tool. It's the connective tissue of collaborative software development. The more fluent you get with it, the faster you move — and the less you fear breaking things.

That fearlessness is the point.