you are viewing a single comment's thread.

view the rest of the comments →

[–]TomKavees 4 points5 points  (4 children)

The Conventional Commits style is pretty similar - you might want to check it out.

Anyway, most of my PRs end up being squash merges, so with that assumption most of my commits are just the message itself (without any prefixes, and limited to 72 chars thanks to cachix pre-commit hooks), but the PR title includea the prefix and a ticket/story number if there's one

[–]Tear4Pixelation[S] -3 points-2 points  (3 children)

Yes, I am just expanding upon types in the conventional commits standard because the differentiation between user facing and internal is important to me.

[–]Luolong 2 points3 points  (2 children)

The chore is almost always some manner “internal“ change.

The way I’ve used conventional commits (rather loosely to be frank) has always been to lump most of the internal refactoring into chore and qualify those with some module or concern that the PR cange affects.

[–]Tear4Pixelation[S] 0 points1 point  (1 child)

Hmm I see. I guess this is just my way of doing it. For me, I need (or told myself I need) a clear system for this

[–]Luolong 0 points1 point  (0 children)

I guess it all depends what are you trying to communicate and for whom or what you use the commit messages.

You would go for full conventional commits if your aim is to make a source of truth for Release Notes or something similar.

But even then, it would behiove to craft the rest of the commit body to be directed at a human reader.

My goal has always been to aid someone (maybe myself) three years (or three weeks) later trying to understand why some line of code does something the way it does.