Git Command Cheat Sheet

A Git command list is most useful when tied to Git's three main states: the working tree, the staging area, and the commit history. Most confusion comes from not knowing which state a command changes. Once that mental model is clear, the commands are much easier to remember.

Start or copy a repository

• git init creates a new repository in the current directory.
• git clone <url> copies an existing repository, including its history and default remote.

Use git init when you are starting local history from scratch. Use git clone when collaboration or existing history already matters.

Inspect what changed

• git status shows untracked files, modified files, staged changes, and branch state.
• git diff shows unstaged content changes.
• git diff --staged shows what will go into the next commit.
• git log --oneline --graph --decorate gives a compact picture of recent history.

This group should be used constantly. Many Git mistakes happen because people commit, pull, or reset without first checking status and diff.

Stage and commit deliberately

• git add <file> stages a file.
• git add -p stages selected hunks instead of the whole file.
• git commit -m "message" records the staged snapshot.
• git commit --amend rewrites the latest commit, usually to fix the message or add a forgotten change.

The staging area is one of Git's most useful features because it lets you shape a commit around one idea. If a file contains both a bug fix and a refactor, git add -p helps keep the history reviewable.

Work with branches

• git branch lists local branches.
• git branch <name> creates a branch.
• git switch <name> moves to an existing branch.
• git switch -c <name> creates and switches in one step.
• git merge <branch> brings another branch into the current one.
• git branch -d <name> deletes a fully merged branch.

Modern Git prefers git switch for branch movement because it is clearer than the older git checkout form. Branches are cheap, so use them freely for isolated work.

Sync with a remote

• git remote -v lists configured remotes.
• git fetch downloads remote commits without changing your branch.
• git pull usually means fetch followed by merge or rebase, depending on configuration.
• git push origin <branch> publishes your local branch.

fetch is safer than pull when you want to inspect incoming changes before integrating them. Many teams prefer this sequence: git fetch, review the remote branch, then merge or rebase intentionally.

Undo without making things worse

• git restore <file> discards unstaged changes in a file.
• git restore --staged <file> removes a file from the staging area without deleting working changes.
• git revert <commit> creates a new commit that undoes an earlier one.
• git reset --soft HEAD~1 moves the branch pointer back one commit but keeps changes staged.
• git reset --hard <commit> resets history and the working tree to a specific commit.

The important distinction is safety. revert adds history and is usually the right tool for shared branches. reset --hard destroys uncommitted work and rewrites local state, so it should be used only when you are certain those changes are disposable.

One practical workflow

A typical feature cycle looks like this:

git switch -c add-payment-timeout
git status
git add -p
git commit -m "Add timeout handling for payment gateway"
git fetch
git rebase origin/main
git push origin add-payment-timeout

That sequence reflects the larger point: Git commands are not just vocabulary. They express intent. Inspect first, stage carefully, publish deliberately, and reserve destructive commands for moments when you fully understand the state you are about to change.