Introduction

Most people learn Git the hard way, through small disasters. This page collects the most frequent beginner mistakes and how to avoid (or recover from) them. Read it once now and again after a month of use; the second pass will make more sense.

Committing as the wrong identity

Forgetting to set user.email per repository leaks personal addresses into work commits. Always set a per-repo identity in work clones:

git config user.email "[email protected]"
git log -1 --pretty=format:"%an <%ae>"

Committing secrets

API keys and .env files in commits live forever, even after a follow-up "delete". Add a .gitignore entry before the first commit, and rotate any leaked credential immediately. Tools like git-secrets and gitleaks can run as pre-commit hooks.

Force-pushing over teammates

git push --force rewrites history on the remote, deleting other people's commits. Prefer --force-with-lease, which refuses to overwrite if the remote has moved:

git push --force-with-lease

Misunderstanding pull

git pull is fetch + merge (or rebase). Running it with uncommitted changes can produce surprising merge commits. Either commit, stash, or set a sensible default:

git config --global pull.rebase true
git config --global pull.ff only

Editing detached HEAD without realizing it

Checking out a tag or commit hash leaves you in detached HEAD. New commits there are unreachable once you switch away. Always create a branch first:

git switch -c hotfix v1.2.3

Confusing reset, revert, and restore

• git restore changes the working tree or index; safe.
• git revert creates a new commit that undoes another; safe and shareable.
• git reset --hard moves the branch and discards work; destructive.

Committing huge files

A 500 MB video in a commit is permanent. Use Git LFS for binaries above a few megabytes, and keep build artifacts out of the repository entirely.

Recovery toolkit

git reflog
git fsck --lost-found
git stash list

The reflog records every move of HEAD for 90 days by default; almost any "lost" commit can be recovered from it.

Misreading status

git status's output has subtle layers. "Changes not staged for commit" means tracked files modified in the working tree. "Changes to be committed" means staged. "Untracked files" means Git has never seen them. A common confusion: editing a file after staging it shows it under both lists with different content; only what is staged goes into the commit. Run git diff (working vs index) and git diff --staged (index vs HEAD) until the three areas click.

git status -sb
git diff --staged --stat

Common mistakes

Panicking and running rm -rf .git when something looks wrong. Stop. Take a backup of the directory first. Almost every Git mistake is recoverable through the reflog or stash. The single most important habit for beginners: run git status before and after every state-changing command, and run git log --oneline --all --graph when something feels weird.