Git for beginners: the 12 commands you'll actually use

Git has more than a hundred commands. You need about twelve. This guide covers those twelve, in the order you'll meet them, with what each one does and the mistakes beginners make with it.

All examples work the same on Windows (Git Bash or PowerShell), macOS and Linux.

First, tell Git who you are (once per computer)

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

Use the same email as your GitHub account, so your commits are linked to your profile.

1. git init: start tracking a folder

mkdir expense-tracker
cd expense-tracker
git init

This creates a hidden .git folder where Git stores the history. Run it once per project.

2. git clone: copy an existing project

git clone https://github.com/username/project.git

You get the code and its full history. Use clone instead of init when the project already exists on GitHub.

3. git status: what's going on?

git status

Shows which files changed, which are staged and which branch you're on. Run it constantly. Most beginner mistakes happen because someone didn't check git status first.

4. git add: choose what goes into the next commit

git add app.py
git add .        # everything in this folder

Adding is like putting things in a box before you seal it. Prefer adding specific files when you can, so unrelated changes don't sneak into the commit.

5. git commit: save a snapshot

git commit -m "Add monthly total to the expense report"

A commit is a permanent snapshot with a message. Good messages say what changed, in the imperative ("Add", "Fix", "Remove"). "final", "changes" or "asdf" tell your future self, and any reviewer, nothing.

Commit small and often. One commit per logical change is a good rule.

6. git log: read the history

git log --oneline --graph

One line per commit, with a little graph of branches. Press q to quit.

7. git diff: see exactly what changed

git diff           # changes you haven't staged yet
git diff --staged  # changes you're about to commit

Read the diff before every commit. You'll catch debug prints and accidental edits.

8. git switch: work on a branch

git switch -c add-login   # create a branch and move to it
git switch main           # go back to main

Branches let you try something without breaking the working version. In teams, every feature usually gets its own branch.

9. git merge: bring a branch back

git switch main
git merge add-login

If Git can't combine the changes automatically, you get a merge conflict. Git marks the conflicting lines in the file. Edit the file to keep what you want, remove the markers (<<<<<<<, =======, >>>>>>>), then git add and git commit. Conflicts look scary the first time; after two or three, they're routine.

10. git push: send commits to GitHub

git remote add origin https://github.com/username/expense-tracker.git   # once
git push -u origin main                                                 # first push
git push                                                                # after that

-u remembers where to push, so later you can just type git push.

11. git pull: get the latest changes

git pull

Downloads new commits from GitHub and merges them into your branch. Pull before you start working each day, especially in a team.

12. git restore and git revert: undo safely

git restore app.py            # throw away uncommitted changes to a file
git restore --staged app.py   # un-stage a file, keep the changes
git revert a1b2c3d            # undo a commit by adding a new "opposite" commit

revert is the safe way to undo something that's already on GitHub, because it doesn't rewrite history that others may have pulled.

Three mistakes to avoid

1. Committing secrets. Never commit .env files, passwords or API keys. Add them to .gitignore before your first commit. If a key does get pushed, change the key at once: deleting the file later doesn't remove it from the history.
2. Committing node_modules, virtual environments or build output. They're huge and anyone can regenerate them. GitHub's .gitignore templates cover each language.
3. One giant commit at the end. Your commit history is part of your portfolio. Small, clear commits show how you think.

Practise it, don't just read it

Reading commands is easy. Remembering them comes from using them on a real project for a couple of weeks. Pick any small project, put it under Git today, and use these twelve commands until they're boring.