Read the project before changing it
git log and git diff are how you read a project. Most beginners use them to confirm they did something. Most professionals use them before they do anything: to find when a function changed last, to discover whose code they are about to touch, to scope a change, to verify a hypothesis before pushing.
git log alone is verbose. The shapes worth memorizing: git log --oneline for compact subjects, git log --oneline --graph --decorate --all for the full DAG (alias this — you will use it dozens of times a day), git log -p to see the patches inline, git log --stat for files-changed summary. Filtering: --author, --since/--until, --grep on messages, -S on diff content (pickaxe — finds commits that introduced or removed a string), -G for regex pickaxe.
git diff has more flavors than people realize. git diff alone shows working tree vs index. git diff --staged shows index vs HEAD. git diff abc..def shows commit-to-commit changes. git diff main..feature shows what feature has that main does not (and only that direction). git diff --stat shows a per-file summary. git diff --word-diff highlights changes by word, useful for prose and for diffs in long lines like minified CSS.
Two power moves that pay back forever: git log -p -- path/to/file shows every commit that touched that file with its diff, perfect for tracking down a regression. git log -L :functionName:path/to/file shows the history of just one function across the whole project. The first time you use that on a real bug, you will feel like you found a cheat code.