Your First Git Commands
The 10 Git commands every developer uses 95% of the time — with Excel analogies, exact syntax, and hands-on practice.
There are hundreds of Git commands. You will use about 10 of them for 95% of everything you do. This page covers exactly those 10.
Work through each one by typing it yourself — not copy-pasting. The muscle memory matters more than you think. Typing git status instinctively, the moment you sit down, becomes a habit that saves you from mistakes constantly.
The Mental Model First
Before the commands: one idea to hold in your head while you learn them.
You are not backing up files. You are taking intentional snapshots.
Backups are defensive — you make them in case something goes wrong. Snapshots are intentional — you make them to mark a meaningful moment.
Every time you run git commit, you are creating a permanent record that says: "At this moment in time, this is what my project looked like. Here's why I was at this point."
That record:
- Has a message you wrote explaining what changed
- Has a precise timestamp
- Has your name as the author
- Can be returned to, compared against, or built from at any point in the future
When you work with Git, you think in these questions:
- Am I ready to take a snapshot?
- What message would describe this snapshot in 6 months?
- Is there anything I want to check before I commit?
Everything below is the mechanics of taking and navigating those snapshots.
Practice Setup
Before running any commands, set up a practice folder.
mkdir ~/Desktop/git-practice && cd ~/Desktop/git-practiceYou are now inside a new empty folder called git-practice on your Desktop. All practice commands run here.
The 10 Commands
1. git init — Start Tracking a Project
What it does: Tells Git to start tracking everything inside the current folder. Creates the hidden .git folder where all history will be stored.
Excel analogy: Like enabling "Track Changes" for an entire Excel workbook — from this moment forward, every change is recorded.
Syntax:
Expected output:
When to use it: Once, at the very beginning of any new project. You only ever run this once per project. Every project you create will start with git init.
Practice: run git init inside your git-practice folder.
Check that it worked — you should see a confirmation message like Initialized empty Git repository in .../git-practice/.git/. On Windows, the .git folder is hidden by default. You can verify it exists by running ls -la in Git Bash (which shows hidden files).
Initialized empty Git repository in the output. If you see an error instead, confirm you are inside the git-practice folder (run pwd to check your location).2. git status — See What's Changed
What it does: Shows you the current state of your project. What files have changed since the last snapshot. What's ready to be committed. What's untracked (new files Git doesn't know about yet).
Excel analogy: Like looking at the Track Changes sidebar to see what's been modified since the last accepted version — except it shows you the entire working directory at once.
Syntax:
Expected output (on a fresh repository):
When to use it: Constantly. Before and after every command. Anytime you sit down to work. Anytime you're unsure what state your project is in. Experienced developers run git status compulsively — it tells you the truth about where you are.
Practice: run git status now — you should see On branch main and No commits yet.
Now create a file and run it again: touch hello.txt && git status
You'll now see hello.txt listed as an "untracked file" in red. Git sees it but isn't tracking it yet.
3. git add — Stage Changes for a Snapshot
What it does: Marks specific files (or all changed files) as "ready to be committed." Think of it as choosing which changes go into the next snapshot.
Excel analogy: Like selecting which cell changes to "Accept" in Track Changes before finalizing. You might have 10 changes, but only want to snapshot 5 of them together in one logical group.
Syntax (add a specific file):
Syntax (add all changed files):
The . means "everything in the current folder and below." Use this when you want all changes in the next commit.
Expected output: No output on success. Run git status after to see what changed.
When to use it: After you've made changes and want to include them in the next commit. The sequence is always: make changes → git add → git commit.
Why is there a separate "add" step? Couldn't Git just commit everything automatically?
Yes — but you often don't want that. Imagine you've been working for an hour and changed 15 files. Some changes are for Feature A, some for Feature B, some are a bug fix. You want three separate commits — one per change — so the history is readable. git add lets you select exactly which files go into which commit.
In practice, during this program you'll often git add . to stage everything at once. But the staging step exists for this reason.
Practice: run git add hello.txt, then git status.
hello.txt should now appear in green under "Changes to be committed." It has moved from "untracked" to "staged."
git add hello.txt and check for a typo.4. git commit — Take the Snapshot
What it does: Creates a permanent snapshot of everything you've staged with git add. The snapshot includes a message you write, a timestamp, and your identity.
Excel analogy: Like accepting all tracked changes and saving a named version of the file — except Git's version is permanent, signed, and instantly accessible forever.
Syntax:
The -m flag means "message." Write the message between quotation marks.
Writing good commit messages:
| Bad | Good |
|---|---|
git commit -m "stuff" | git commit -m "add hello.txt with welcome text" |
git commit -m "fix" | git commit -m "fix calculation in monthly summary" |
git commit -m "wip" | git commit -m "add user login form — validation still in progress" |
git commit -m "changes" | git commit -m "update README with setup instructions" |
A good commit message answers: "What did this change, and why?" — in one sentence, past or present tense.
When to use it: After git add, when you're ready to record a snapshot. Commit after every meaningful unit of work — a feature complete, a bug fixed, a configuration change made.
Practice: run git commit -m "add hello.txt with welcome text"
Expected output: [main (root-commit) a3f2c1d] add hello.txt with welcome text
The string a3f2c1d is the commit's unique ID (called a "hash"). Every commit gets one. It's how Git refers to specific snapshots.
1 file changed, 0 insertions(+) (or similar) in the output. If you see nothing to commit, you may have forgotten git add — go back and stage the file first.5. git log — Read the History
What it does: Shows the complete list of commits in the current branch — most recent first. Each entry shows the commit hash, author, date, and message.
Excel analogy: Like reading the full Track Changes history from newest to oldest — who changed what, when, and the note they left.
Syntax:
Expected output:
Useful variations:
Shows a condensed view — one line per commit. Much easier to scan when the history is long:
Shows a visual branch diagram alongside the history. Useful when multiple branches are involved.
When to use it: When you want to see what was done and when. When you need to find a specific commit to return to. When you want to understand what a project's history looks like before working on it.
Press q to exit the log view when you're done reading.
6. git diff — See Exactly What Changed
What it does: Shows the precise line-by-line differences between the current state of your files and the last commit. Lines added appear with a + prefix, lines removed with a - prefix.
Excel analogy: Like comparing two versions of the same sheet cell by cell — except Git shows you the exact characters that were added or removed in each file.
Syntax:
When to use it: Before committing, to review exactly what you changed since the last snapshot. A good habit: git diff then git add . then git commit. Never commit something you haven't reviewed.
Practice:
You'll see something like:
The + line is new. The unmarked line is unchanged context.
7. git restore — Undo Uncommitted Changes
What it does: Discards changes to a file and returns it to the state of the last commit. This is how you undo edits you haven't committed yet.
Excel analogy: Like pressing Ctrl+Z to undo changes — except it undoes everything back to the last saved version, not just one step.
Syntax:
Syntax (restore all changed files):
When to use it: When you've made changes to a file and decide you want to throw them away and start fresh from the last commit.
git restore cannot be undone. If you restore a file, the changes you discarded are gone — Git has no record of them because they were never committed. Only use this when you are certain you don't want those changes. If you're unsure, commit first (with a message like "work in progress") and then experiment.
Practice: edit hello.txt (add any text), then run git restore hello.txt.
8. git branch — Create and List Branches
What it does: Lists all branches in the current repository, or creates a new branch.
Excel analogy: Like creating a copy of your entire Excel workbook with a different name — so you can make experimental changes on the copy without affecting the original. Except in Git, branches are instant and take no extra disk space.
Syntax (list branches):
Syntax (create a new branch):
Expected output (listing branches):
The * shows your current branch.
When to use it: When you're about to work on a new feature or experiment that you don't want to affect the main codebase yet. Create a branch, do your work, and merge it back in when it's ready.
Practice: run git branch try-something-new, then git branch.
You'll see both main and try-something-new listed. The * is still on main — creating a branch doesn't switch you to it.
9. git checkout — Switch Between Branches
What it does: Switches your working directory to a different branch. All the files in your project folder update to match the state of that branch.
Excel analogy: Like switching between different named versions of a workbook — each with their own state, none affecting the others.
Syntax:
Combined (create and switch in one step):
The -b flag means "create this branch and switch to it." You'll use this constantly — it's the most common way to start new work.
When to use it: Every time you start working on a new feature, bug fix, or experiment. Create a branch, switch to it, do the work, then merge it back to main.
Practice: run git checkout try-something-new. The * should now be on try-something-new.
Now make a change and commit it: touch branch-file.txt && git add . && git commit -m "add branch file"
Switch back to main: git checkout main
Look at your folder — branch-file.txt has disappeared. It exists on the try-something-new branch, not on main. This is how branches work — each one has its own state.
main, run ls in Git Bash. You should NOT see branch-file.txt. This confirms branches are truly separate.10. git merge — Bring Branches Together
What it does: Takes the commits from one branch and adds them into another. This is how finished work gets incorporated back into the main codebase.
Excel analogy: Like "accepting all changes" from a colleague's version of the workbook — their additions are merged into your current version. If you both changed the same cell, Git asks you to manually decide which version to keep (this is called a merge conflict).
Syntax:
From the branch you want to merge into (usually main):
When to use it: After you've finished working on a branch and want to bring that work into main. You switch to main first, then merge.
Practice: from main, run git merge try-something-new
Expected output: Fast-forward — and branch-file.txt now appears in main. The work from try-something-new is merged in.
ls after the merge. You should now see branch-file.txt in the main branch. The merge worked correctly if the file is present."Fast-forward" merge: When the branch you're merging has no conflicts with main (because main hasn't changed since you branched off), Git does a fast-forward — it simply moves main forward to include the new commits. No conflict resolution needed.
Merge conflicts happen when two branches change the same part of the same file. Git marks the conflict in the file and asks you to resolve it manually. You'll learn this in the project sessions when it first happens in practice.
The Complete Daily Workflow
Here is how these commands work together on a typical workday:
Quick Reference Card
| Command | What it does | Excel analogy |
|---|---|---|
git init | Start tracking a project | Enable Track Changes on a workbook |
git status | See what's changed | Check the Track Changes sidebar |
git add . | Stage all changes | Select changes to accept |
git commit -m "..." | Take a snapshot | Accept and save a named version |
git log --oneline | View history | Read the change history |
git diff | See exact changes | Compare two cell-by-cell versions |
git restore [file] | Undo uncommitted changes | Ctrl+Z back to last save |
git branch [name] | Create a branch | Copy workbook to new named version |
git checkout [branch] | Switch branches | Open a different named version |
git merge [branch] | Combine branches | Accept all changes from another version |
What You've Accomplished
You have set up a complete Git repository from scratch, made multiple commits, worked on a branch, and merged it back. This is the complete cycle that professional developers repeat every single day — on projects with thousands of files and dozens of team members.
The scale changes. The commands do not.
Run the verification checklist next to confirm everything is working correctly before your first session.
Interactive: Git as a Time Machine
Every commit is a save point. Click any commit below to see what the file looked like at that moment in time.