Working with versions: branches, merges and history
A simple flow
A stable main branch, short branches per change, a merge after review and tests. A branch that lives two weeks will create conflicts and a frightening merge — and that's almost always a sign the task is too big.
Change messages
A short first line stating what changed, then why. The “why” is what can't be recovered from the code, and it's what you'll search for in a year.
Link to the task or discussion. A change with no context is a future riddle.
Hygiene
Don't store built files, secrets or large files in the repository. Tag versions with tags. And don't rewrite history that's already been published — it breaks others' work.
Going deeper
Decide on one merge policy — keeping full history or squashing to a single change — and enforce it. Consistency matters more than the choice itself, because a mixed history is hard to navigate exactly when you need to find when something broke.