← Back to context

Comment by Tinos

7 days ago

My advice is never use conventions for personal/solo projects - they do not matter.

When it comes to working in teams I actually do recommend them because during a code review you can - at a glance - read what each commit has done so you can familiarise yourself with the steps the developer took to reach the state in the PR.

For small teams I'm a big proponent of slimmed down version of Conventional Commits' standard. At our startup we would only really use these types: fix/feat/chore/docs/refactor/revert/ci/test.

Something simple like:

fix(ControlPanel): popover animation no longer causes layout shifts

is perfect

Depends on the size of the project. Some informal convention can be pretty helpful when a personal projects gets sufficiently large, to the point where you may at some point have to look at the git log.

  • Yes you are right, well said! I suppose it's key to look at your project from a birds' eye view and try and estimate how large scale you expect it to be.

    If you're building the next open source self-hosted facebook, yeah I think a convention is necessary. However, if you're building "my calculator app in Rust" then you're probably okay just doing commits "abcd123" just so that you can have remote code storage :^)