Branching and Committing Discipline

git checkout -b feature/add-loyalty-discount
# make changes...
git add .
git commit -m "Add loyalty discount calculation to CheckoutService"
git push origin feature/add-loyalty-discount

git checkout -b feature/add-loyalty-discount creates and switches to a new branch — an isolated line of work that doesn't affect main until it's explicitly merged. This means half-finished, experimental work never risks breaking what everyone else is using.

BAD:  "fixed stuff"
BAD:  "updates"
GOOD: "Fix null check in enroll() that let a null Student crash the roster"

A commit message should explain why the change happened, not just restate the diff (which git show already displays). "fixed stuff" tells a future reader nothing; the good example tells them exactly what problem existed and what fixed it — genuinely useful six months later when nobody remembers the details.

BAD:  one commit that adds a feature, fixes an unrelated bug,
      and reformats three other files

GOOD: three separate commits, each doing exactly one of those things

A commit that mixes unrelated changes is hard to review (a reviewer can't approve just the bug fix without also approving the reformatting) and hard to revert (undoing the bug fix would also undo the feature). One commit, one logical change — this discipline pays off every time something needs to be reviewed, reverted, or understood later.