What commit message conventions do you follow?

I've written mine up as I've noticed I was repeating myself a bit once my opinions stabilized.

See https://jiby.tech/post/my-git-worfklow/

I've noticed that I split commits and make very verbose but clear messages for each commit, only to never use this afterwards.

Meanwhile my coworkers just commit with "lol" and get the same result. What I learned from this is that you don't need to split commits, just commit everything at once and add a "good enough" message. E.g. if you're working on a provider just use "Updated provider"

I've never worked on a team that had conventions for both commits and PRs. In general, the goal of such things is to help trace work across multiple systems, and for future research trying to track down old changes. All the places I've worked or consulted, they do that at the PR level, not the commit level. So PRs will start with a ticket #, commits are freeform.

That being said, some places do have commit standards. Just ask the team what they do when you start somewhere. Don't bring conventions in where a team doesn't use them - it just adds noise. If you or the team see how adding conventions can benefit your work, talk about it and make a decision together.

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

The only "convention" that exists is the Conventional Commits' one. It is sensible and compatible with some tools. As long as you write "fix:", "feat:" or "chore:" you'll be fine.

Don't overthink it though, it's a thing that is used in some open-source projects and companies. As long as you follow the rules of the project, you'll be fine. Same for the coding style and format, do like everyone else.

Doesn't matter much. What works for me is it's easily skimmable. Rather than say "fix the command widget", it's better to say "command widget fixed". Because if you do verbs, most of your commits will start with "fixed" and stuff and won't be helpful when people actually try to read it.

Some people do require to do the whole fix:, chore:, docs:, refactor:, but I find this is more as some quality control tool rather than a documentation tool.

Ours is integrated heavily with Jira, so using the ticket number helps the most. We're likely to find commits/PRs from tickets, or jump to the ticket for the context of the commit. The other entry point is looking at git blame on an IDE, especially a funky looking line of code like `if (nonsense logic)` is causing a bug regression. When this happens, I want the ticket. I can immediately just paste the ticket number into Jira.

As always, different styles are suited to different cultures. Read everything here for ideas, but pick one that fits your culture the best.

The official documentation contains some guidelines and the reasoning behind them:

https://git-scm.com/book/ms/v2/Distributed-Git-Contributing-...

https://git-scm.com/docs/SubmittingPatches#describe-changes

For examples of projects that do this very well, I usually point people to the Linux kernel (for which Git was invented) and Go.

https://www.kernel.org/doc/html/latest/process/submitting-pa...

https://go.dev/doc/contribute#commit_messages

On some hobby projects I just do a "git add ./*" and set an exquisite commit message along the lines of

   > sync
   > blah
   > i haven't committed this since a week, so let's do this now
   > fix that bug, and 15 other things

At work, and when I push some OSS code, I do as the Romans do.

For my projects I just use "Temp" and "Works". Sometimes a couple-words summary, which works as a temporary anchor for diffs. Never found myself reading through old commit messages to grasp something, in any vcs (used cvs, svn, git). If there's a necessity to find a commit, I just blame or log with files. But there's usually no necessity, cause I prefer to move forward rather than digging the past.

Before anyone screams, I don't expect you to browse my projects, even when they are public or shared. Writing this because it's one of the practical ways. I know you don't like it and would fire me asap even for my project commits, yeah dream about it.

My company has a terrible commit message culture. Half of the commits begin with "in which our hero..." - you can imagine how insanely irritating it is to find relevant changes in logs...

For branch commits, anything (no profanity lol!)

For merge commits -

An "and" or long description hints it needs to be broke up

I usually use the one we use in the FreeBSD project, which is to have the subject be of the form "component: action".

Start with a verb in imperative mode, first letter uppercase, no punctuation at the end, for example: “Add about page”.

To me it depends on your goals:

Do you want to use it to power versioning and CI?

Do you want commits traceable to tickets/issues

Do you want to do merge commits or squashes?

Do you want to generate change logs from the commits?

Different strategies will benefit different needs.

I put the ticket number first, that way I always know which commits are mine if I do a rebase. I don't know why everyone doesn't do this.

I describe in past tense what I just did.

For example -

" uuid added to the test to make the newly created mailbox different each time "

line 1: short description. fit on 1 line. put effort into making it as short as possible while still giving the gist of what was done. maybe a github/lab issue #.

line 2: blank

line 3+: long description, paragraphs, details, context for decisions made, rambling

applicable for feature or bugfix:

1. describe how things work (or not work) currently

2. proposed solution to the problem this commit attempts

3. more implementation/technical details

4. (optionally) tests or reproduction scenario

For juniors, whatever gets you yelled at less. For seniors, whatever you wouldn't yell at. In any case there will be yelling.

"fixed some stuff"

“Why” not “what”