Which git commands do data people actually need?

Every portfolio project lands in a repo, and recruiters read them. Here is git cut down to the part data work actually uses, plus the hygiene rules that keep CSVs and keys out of public history. The print-ready A4 PDF is at the bottom.

The daily loop

• git status: what changed.
• git add -p: stage chunk by chunk.
• git commit -m "…": say why, not what. "fix tz bug", not "edits".
• git push: ship it.

Branches

• git switch -c fix-x: new branch, experiments live here.
• git switch main: go back.
• git merge fix-x: bring it in.

Undo

• git restore f.sql: discard a local edit.
• git revert <sha>: undo a commit, keep history.
• git stash: park it, come back later.

Reading history

• git log --oneline: the story so far.
• git diff main: what would merge.
• git blame f.py: who touched this line, and when.

Data hygiene

• .gitignore first: before commit number one.
• *.csv, data/, .env: never in a repo.
• Commit the schema, not the rows.

The loop, in one block

git status              -- what changed
git add -p              -- stage hunk by hunk
git commit -m <why>     -- "fix tz bug", not "edits"
git push                -- ship it

git switch -c <branch>  -- experiments live here

add -p shows every change before staging it. It is also how you catch the file that should never be committed.

The trap: the repo is public

A portfolio repo gets read by recruiters. And by scrapers. Deleting a file in a new commit does not remove it from history: assume any pushed secret is burned, and git push --force rewrites history other people share.