Reference · 12 min read · 2026-04-15

Every git command you need, on one page

Git ships with 160+ commands. You will use about 20 of them. Here they are, grouped by what you're actually trying to accomplish, with runnable examples you can try in LinuxSim's git sandbox — no install, no account, no risk.

Setup (once per machine)

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

You only need to do this once per computer. Without it, every commit will have "unknown" as the author.

Starting a project

git init                         # turn the current folder into a git repo
git clone https://github.com/x/y # download a remote repo to your machine

init creates a hidden .git/ directory in the current folder. That directory is where git stores every version of every file, ever. Don't touch it by hand.

The everyday loop (you will do this 50 times a day)

git status                       # "what's changed since the last commit?"
git add <file>                   # stage a file for the next commit
git add .                        # stage everything
git commit -m "describe the change"  # snapshot the staged changes
git log                          # show commit history
git log --oneline                # compact version

This is the rhythm: edit → status → add → commit. Then repeat forever. git status is the command you'll run most often by a large margin — it's how you orient yourself in a messy working directory.

Understanding the three zones

Git has three "places" a file can live:

Working directory — the files on disk you're editing right now
Staging area (index) — files queued for the next commit
Repository — committed history (the .git/ folder)

git add moves a change from working directory to staging area. git commit moves staged changes from staging area to repository. The reason for two steps is that you can work on ten files but commit just two of them — git add lets you pick what goes into the next commit.

Branching (where git actually earns its keep)

git branch                       # list branches
git branch feature               # create a branch named "feature"
git checkout feature             # switch to it
git checkout -b feature          # create AND switch (shortcut)
git checkout main                # go back to main
git merge feature                # merge feature into the current branch

Branches are how you work on two things at once without the code mixing. Starting a new feature? Make a branch. Experimenting? Make a branch. Fixing a bug in parallel to your feature work? Make two branches. Branches are free — use them aggressively.

Fixing mistakes

git restore <file>               # throw away uncommitted changes to a file
git restore --staged <file>      # unstage a file (keep the changes, just remove from index)
git reset --soft HEAD~1          # undo the last commit, keep changes staged
git reset --hard HEAD~1          # undo the last commit AND throw away the changes (dangerous!)
git commit --amend -m "new msg"  # edit the most recent commit's message

Golden rule: never run git reset --hard or git commit --amend on a commit you've already pushed to a shared remote. Rewriting history that other people have pulled causes chaos. On your own machine, before pushing, it's fine.

Remotes (working with GitHub / GitLab / etc.)

git remote -v                    # show configured remotes
git remote add origin https://github.com/you/repo.git
git push origin main             # upload your commits
git push -u origin main          # upload + remember so future `git push` is enough
git pull                         # download remote commits into your current branch
git fetch                        # download commits but don't merge them yet

In practice you'll spend 90% of your time typing git push and git pull. git fetch is for when you want to peek at what's on the remote without touching your local work.

Inspecting the past

git log --oneline --graph --all  # pretty branch graph of everything
git diff                         # unstaged changes vs working dir
git diff --staged                # what's queued in the staging area
git show <commit-sha>            # what changed in a specific commit
git blame <file>                 # who last touched each line (and when)

git blame sounds mean but it's actually a great tool: when you're reading mystery code, git blame tells you which commit introduced each line and why (via the commit message).

The .gitignore file

Create a file named .gitignore at the root of your repo to tell git which files to never track. A minimal one for a Node project:

node_modules/
.env
.DS_Store
dist/
*.log

Each line is either a literal path, a glob pattern (*.log), or a directory (node_modules/). Git matches recursively. Without a .gitignore, you'll accidentally commit secrets, build output, and 300 MB of node_modules. Don't skip this file.

The seven commands that actually matter

If you only memorize seven, make them these:

git status — always safe, always useful, always first
git add . — stage everything
git commit -m "msg" — snapshot
git push — upload
git pull — download
git checkout -b feature — new branch
git log --oneline — see history

These seven will carry you through 80% of real-world git usage. The other 13 are for debugging, fixing mistakes, and advanced workflows.

Try it — free, in your browser

LinuxSim ships with a Git Basics app that runs a real (small) git state machine entirely in your browser. You can init, create branches, commit, merge, and see the history diverge and converge — all without installing anything. There are 6 guided challenges that walk you from "never used git" to "confidently branching and merging."

🚀 Launch LinuxSim and try Git Basics →