Setup and everyday commands

Configure Git once, then most days are a loop of status, add, commit and push. These are the commands you will type most often.

git config

What: Sets options at three levels: system, global (your user, in ~/.gitconfig) and local (one repository). The narrower level wins.
Why: Your name and email are written into every commit, and a few defaults (branch name, pull behaviour, editor) save friction on every project.

Shell

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --list --show-origin

Watch out

Committing with a personal email on a work repository. Set user.email locally where it differs.

git init and git clone

What: git init turns a folder into a new repository. git clone copies an existing repository, its full history and a remote called origin that points back to it.
Why: Clone is how you start on almost any existing project; init is for new ones you will later push to a host.

Shell

git init my-app
git clone git@github.com:acme/api.git
git clone --depth 1 https://github.com/acme/big.git

Watch out

Running git init inside an existing repository, which creates a confusing nested repository.

git status

What: Shows the current branch, how it compares with its upstream, and which files are staged, modified or untracked.
Why: It is the safest command in Git and the first thing to run whenever you are unsure what state you are in.

Shell

git status
git status -sb

git add

What: Stages changes into the index. git add -p walks through each change (hunk) and asks whether to stage it.
Why: Staging deliberately keeps commits focused and stops debug code or unrelated edits from slipping in.

Shell

git add src/cart.ts
git add -p
git add -A

Watch out

Habitually running git add . or git add -A and committing secrets, build output or stray files.

git commit

What: Records the staged snapshot as a new commit on the current branch. --amend replaces the last commit with the index plus a new message.
Why: Small, frequent commits give you save points to return to and a history reviewers can follow.

Shell

git commit -m "Fix rounding in cart totals"
git commit
git commit --amend --no-edit

Watch out

Amending a commit that is already pushed and shared: it rewrites history under other people.

git diff

What: Shows line changes. With no arguments it compares the working tree with the index; --staged compares the index with the last commit.
Why: Reading the staged diff before committing is the cheapest review you will ever do.

Shell

git diff
git diff --staged
git diff --stat
git diff --word-diff

Watch out

Running plain git diff, seeing nothing, and assuming there are no changes when everything is already staged.

git rm and git mv

What: git rm deletes a file and stages the deletion; git rm --cached stops tracking it but keeps it on disk. git mv renames and stages in one step.
Why: --cached is how you untrack a file that should have been ignored, such as a .env file committed by mistake.

Shell

git rm --cached .env
git mv utils.js helpers.js

Watch out

Untracking a secret with git rm --cached and thinking it is gone: it is still in history, so rotate the secret.

Go deeper