Commits you can still follow later

A commit is a recorded change. In a month you will need to know what changed and why. The habit below is the one I use on this notebook's own prototypes.

Each commit should contain one decision: one bug, one layout change, one new legal-move filter. If you have to write "and" in the subject, split the commit. The subject line states the decision in the imperative ("Reject throw-ins above the defender's remaining cards"), not a vague "updates" or "fixes." The body, when needed, says what you observed and how you checked it.

Do not commit generated files that you cannot read, and do not commit secrets. If a change is unfinished, say so in the subject and leave the program in a state that still starts. A half-applied move generator that throws on page load is harder to resume than a small, complete filter with a test fixture sitting next to it.

This is not a complete branching policy. It is enough that git log --oneline can be read like a lab index.