You do not need fifty Git commands to work effectively. Most daily tasks boil down to six jobs: inspect changes, stage the right lines, commit clearly, switch branches safely, sync with the remote, and undo mistakes without making them worse. Modern Git also splits old checkout behavior into switch and restore, which makes intent easier to read.

Outcome and prerequisites

This guide is for developers who want a reliable day-to-day command set, not a maximal cheat sheet.

You should already have:

  • Git installed,
  • a repository to work in, and
  • a basic understanding that Git tracks a working tree, an index (staging area), and commits.

Short answer

If you learn only these commands well, you can handle most daily work:

  • git status
  • git diff
  • git add and git add -p
  • git commit
  • git switch
  • git restore
  • git fetch and git pull
  • git reset and git revert
  • git stash

Step-by-step process

1. Inspect before you act

git status
git diff
git diff --staged

Start here. status tells you what changed. diff shows unstaged changes. diff --staged shows what will actually land in the next commit.

2. Stage carefully, not blindly

git add path/to/file
git add -p

Use plain git add when the whole file belongs in the commit. Use git add -p when you need to split one file into smaller logical changes.

3. Commit with one clear idea per commit

git commit -m "Explain what changed"

A useful commit message explains the outcome, not just that “stuff changed.” If you staged the wrong thing, fix the index before committing.

4. Create and switch branches with the modern command

git switch -c feature/name
git switch main

git switch is the clearer branch-navigation command. Use -c to create and switch in one step.

5. Restore files without overloading checkout

git restore path/to/file
git restore --staged path/to/file

Use git restore for file-level undo:

  • without --staged, it restores the working tree copy,
  • with --staged, it removes the file from the index.

This is easier to reason about than memorizing older checkout -- <file> patterns.

6. Sync safely with the remote

git fetch origin
git pull --rebase

fetch downloads remote updates without changing your current branch. pull downloads and integrates. Many teams prefer pull --rebase to keep local history linear, but use the workflow your project expects.

7. Undo the right way

git reset --soft HEAD~1
git reset --mixed HEAD~1
git revert <commit>

Use these for different problems:

  • reset --soft moves HEAD back but keeps changes staged.
  • reset --mixed moves HEAD back and returns changes to the working tree.
  • revert creates a new commit that undoes an older one and is the safer choice on shared branches.

Use git reset --hard only when you are certain the local work is disposable.

8. Stash temporary work when context switches are short

git stash push -m "wip"
git stash list
git stash apply

A stash is a temporary shelf, not a long-term archive. It is useful when you need to switch tasks quickly without making a half-finished commit.

Common failure cases and safer alternatives

I used pull without understanding what changed

Safer alternative: run git fetch first, inspect incoming commits, then integrate.

I want to discard one file, not rewrite history

Use git restore instead of a broad reset.

I need to undo something already pushed

Prefer git revert instead of rewriting shared history with reset.

I mixed unrelated edits into one file

Use git add -p so your commit stays focused.

I keep using checkout for everything

Modern Git supports switch and restore precisely so you can separate branch movement from file restoration.

Checklist

  • I check git status before and after important commands.
  • I inspect diffs instead of staging everything by habit.
  • I use switch for branches and restore for file undo.
  • I prefer revert on shared history.
  • I use stash only for short-lived task switching.

Sources and update date

Command behavior and examples were reviewed against the official Git documentation on July 31, 2026. Git evolves, but the command references above remain the authoritative source when a team workflow or version-specific edge case matters.