The commit message
- Subject in the imperative, under about fifty characters, no full stop.
- A blank line, then the body — wrapped at seventy-two, because terminals.
- The body answers why. The diff already says what.
- One commit, one idea. If the subject needs an "and", it is two commits.
Fix the total when a line is discounted
The line total used the catalogue price instead of unit_price, so any
order with an agreed discount invoiced at the wrong amount. Nothing
before this commit needs correcting — the invoice PDF was already
generated from the line.
Closes #214.gitignore, and what must never be in a repository
The rule is: if a command can regenerate it, it does not belong in git. The exceptions are lock files (package-lock.json) — those are the source of truth for which versions you used, and they must be committed.
# dependencies and build output — anyone can regenerate these
node_modules/
dist/
.next/
# secrets
.env
.env.*
!.env.example # …but keep the template
# noise
*.log
.DS_Store
coverage/Deleting it in a new commit leaves it in the history, and rewriting the history does not help anyone who already cloned. Rotate the key. Then clean the history if you like, but rotate first.
Big files
Git stores every version of everything, forever. A 40 MB design file changed twenty times is 800 MB in every clone, for the life of the repository — and no later cleanup gives it back without rewriting history for everyone.
Video, PSDs, datasets and binaries belong in Git LFS or in object storage with a reference committed instead. Decide before the first one goes in.
A branch strategy that fits the team
They differ mainly in how long a branch lives. Longer branches mean bigger conflicts and later feedback; choose the shortest one your release process allows, and write it down where a new person will read it.
| Strategy | Shape | Fits |
|---|---|---|
| Trunk-based | short branches, merged daily, feature flags | continuous deployment |
| GitHub flow | a branch per change, pull request, merge to main, deploy | most teams |
| Git flow | develop, release/, hotfix/, main | versioned software with support windows |
The small habits that pay
- Commit before you go to lunch; a broken commit on your own branch costs nothing.
git statusbefore every commit, and read it.git diff --stagedbefore every commit — that is your first review.- Pull, or rebase onto main, at the start of every day.
- Delete branches after merging; a list of ninety stale branches helps nobody.
- Put the setup instructions in a README that you actually follow on a clean machine once a year.