06-22-2026, 12:01 PM
Commit discipline is one of those things where the habits you build early define how painful your future self finds rebasing, debugging regressions, and collaborating.
Commit messages that are actually useful
The subject line should complete the sentence "If applied, this commit will..."
Commit small and often
A commit with 50 lines changed is easy to review and easy to revert. A commit with 2000 lines across 30 files is a liability. If you're squashing everything into one commit at PR time anyway, at least have checkpoints locally.
Don't commit broken states
Every commit on main should pass tests and run. Feature branches can be messy but clean them up before merging. Future you running git bisect will thank present you.
Use branches for everything
Even small changes. It costs nothing and lets you context-switch cleanly without stashing half-finished work onto main.
Tags for releases
Annotated tags on release commits make it trivial to check out exactly what was running in production on a given date. git tag -a v1.4.0 -m "Release 1.4.0"
.gitattributes for line endings
If you work across Windows and Unix: set this up on day one or spend a day debugging mystery diffs. * text=auto in .gitattributes handles most cases.
What version control habits do you swear by?
Commit messages that are actually useful
The subject line should complete the sentence "If applied, this commit will..."
- Good: Fix race condition in session token refresh
- Bad: fix bug, wip, asdf
Commit small and often
A commit with 50 lines changed is easy to review and easy to revert. A commit with 2000 lines across 30 files is a liability. If you're squashing everything into one commit at PR time anyway, at least have checkpoints locally.
Don't commit broken states
Every commit on main should pass tests and run. Feature branches can be messy but clean them up before merging. Future you running git bisect will thank present you.
Use branches for everything
Even small changes. It costs nothing and lets you context-switch cleanly without stashing half-finished work onto main.
Tags for releases
Annotated tags on release commits make it trivial to check out exactly what was running in production on a given date. git tag -a v1.4.0 -m "Release 1.4.0"
.gitattributes for line endings
If you work across Windows and Unix: set this up on day one or spend a day debugging mystery diffs. * text=auto in .gitattributes handles most cases.
What version control habits do you swear by?