Tracking changes.
WHAT TO COMMIT
Source code Configuration examples Documentation Dependency declarations and lock files
WHAT NOT TO COMMIT
Dependencies Secrets Build output Large media, usually
WHAT TO SET UP FIRST
The ignore file, before the first commit.
WHY
Once a secret is committed it remains in history.
WHAT TO DO IF ONE WAS
Rotate it, assuming compromise.
WHAT MAKES A GOOD COMMIT
One logical change, with a message stating what and why.
WHAT NOT TO COMBINE
A behaviour change with reformatting.
WHY
The real change becomes invisible among reformatted lines.
WHAT BRANCHING APPROACH SUITS MOST PROJECTS
A main branch that always works, with short-lived branches for each piece of work.
WHY SHORT-LIVED
Long-running branches diverge, and merging becomes painful.
WHAT TO PROTECT
The main branch, so changes arrive through review.
WHAT TO TAG
Releases, so you can return to exactly what was deployed.
