Git
Commits are save points, branches are sandboxes, history is documentation. Treat them accordingly.
Commit discipline
- Commit after each successful slice. Don’t accumulate work — a commit is a save point you can return to.
- One logical change per commit. A commit that refactors and adds a feature is two commits.
- Explain intent, not mechanics. Describe why the change matters, not what files were touched.
Change sizing
- ~100 lines per commit: good.
- ~300 lines: acceptable if one logical change.
- 1000+ lines: too large — split it.
Separate refactoring from feature work. Separate formatting from behavior changes.
Branch workflow
- Start from latest main branch.
- Keep branches short-lived — merge within days, not weeks.
- Rewrite local history before pushing — amend, rebase, squash to keep history clean. Commit noise should never become permanent.
- Never amend commits already pushed to remote.
- Use
--force-with-leaseover--force.
Save-point pattern
When exploring uncertain changes, commit early with a clear message. If the approach doesn’t work out, you can revert cleanly. Uncommitted work can’t be reverted — only lost.
Change summaries
After a set of changes, provide a structured summary:
- What changed — the diff in plain language
- What was intentionally excluded — scope discipline
- What to watch — potential concerns for reviewers
Red flags
- Long-lived branches diverging from main
- Commits with “misc”, “fix”, “update” as the entire message
- Force-pushing to shared branches
- Mixing unrelated changes in one commit
- Working without committing for extended periods