Git, and what a reviewer sees before your code

The first thing opened, and what is looked for

A hiring manager clicks your GitHub link before they read your CV properly. They are not counting stars. In about forty seconds they are answering one question: does this look like someone who has worked with others?

What answers it:

• A README at the top of the repository that says what this is and how to run it.
• A commit history with more than one commit, and messages that are sentences.
• A .gitignore, so the repository is code and not a .venv directory and a 200MB CSV.
• No credentials anywhere.
• Branches and pull requests, even on a solo project: it shows you know the shape of team work.

What answers it badly: one commit called final, then final2, then actually final.

The commands that are ninety-five per cent of it

git status                 # what have I changed
git add -p                 # stage changes hunk by hunk, reading them
git commit -m "Fix timezone handling in the nightly load"
git push
git switch -c fix/timezones
git pull --rebase

git add -p is the one to adopt deliberately. It walks you through your own changes before you commit them, and it catches the debug print, the hard-coded path and the accidental password more often than any tool.

Commit messages: imperative mood, saying why where the what is not obvious. Fix double-counting in the weekly report — orders were joined to items before summing is worth more than bug fix, because the next person searching the history is you.

The secret that cannot be deleted

You commit a .env with an API key, notice, delete the file, commit again. The key is still in the repository, because git stores snapshots and every past snapshot is still there. On a public repository, automated scrapers index new commits within minutes, and several providers now scan public code themselves and revoke keys they find.

The order of the fix matters and people get it backwards:

1. Revoke and rotate the key first. Immediately. Assume it is already copied.
2. Then clean the history, with git filter-repo or the provider’s support process.

Rewriting history first and rotating later leaves a live key in circulation while you do the harder task. Rotating first makes the exposed key worthless in a minute.

Prevent it: put .env in .gitignore on the first commit of every project, and keep a .env.example with the names of the variables and no values.

Pull requests as writing, not ceremony

A pull request description is the most-read thing you will write at work. The shape that works:

What this changes: the nightly load now retries on a
timeout instead of failing the whole run.

Why: the run died three times last week, always on the
same slow endpoint, and a rerun always succeeded.

How I checked: forced a timeout locally and confirmed
two retries then success; ran against last Tuesday's
data and the row counts match.

What I did not do: no backoff between retries yet —
worth adding if this recurs.

That takes four minutes and it is the difference between a review that takes an hour and one that takes five minutes. It is also, not incidentally, an audition for every promotion conversation you will ever have.

What to do with a large file

Do not commit the 400MB dataset. The repository keeps it forever, clones become painful, and some hosts refuse pushes over a size limit. Commit a small sample (a hundred rows) plus the script that fetches the real thing, and say in the README where the full data lives.

The free path

Git itself is free and always was. GitHub’s free tier includes unlimited private repositories and CI minutes; GitLab and Codeberg are alternatives if you prefer. Nothing in this lesson needs a paid plan. GitHub Copilot and team plans are the paid products; neither affects how your history reads.

Why it feels arbitrary for a year

Git’s commands feel inconsistent because they expose an underlying model rather than hiding it: git stores complete snapshots of your files, addressed by a hash of their content, and branches are just labels pointing at one of those snapshots. Once that clicks, rebase and reset stop being magic spells. Until it does, you will follow recipes and occasionally break things, and that is the normal experience of everyone who uses it, including people who have used it for a decade.

Keep one recipe handy for the situation that frightens beginners most: you have committed to the wrong branch, or you want to undo the last commit but keep the work.

git reset --soft HEAD~1     # undo the commit, keep the changes staged

Nothing is lost. Almost nothing in git is ever lost, which is worth knowing at 23:00 when it appears to be.