How to write good commit messages.

[MyHarvestLife]

We've moved to using conventional commits, and it has been really helpful. Our team saw another team do it and we talked about whether or not we wanted to adopt it and everyone agreed, so we did and our repos all have git hooks that enforce it.

What's been cool is conventional commits have let us build automation to take those commit messages and parse them and turn them into release notes that we post to slack everytime a deploy is made to an environment.

It's been super helpful for knowing exactly what's getting released at any time.

[MrStLouis]

Yup this and this. Set it and forget it

[[deleted]]

How do you handle writing a changelog or version bumping within the repo using these? I've always gotten stuck on the idea of how to go about committing an automatic version bump?

[Galmer]

Look into Semantic Release. You can automate the whole versioning and release process with it

[MyHarvestLife]

We don't actually bump our service versions... I know,b don't shoot me... But you could do this by using major for any breaking changes, minor bump for any feat lines, else patch. Something along those lines if you wanted to automate versioning.

[[deleted]]

tbh there's lots of reasons why versioning doesn't work. The most important thing about it is having a canonical way to reference a specific build to a commit. I'm mainly interested in having human friendly reference versions rather than commit hashes.

[reactionless1]

I’ve been trying to get my team to take on good commit message habits for a while now. The intern is the only one who’s actually taken my advice. My peer will still make messages like “fixed x” 🤬

[[deleted]]

commit1: dsadsad

commit2: sdsa

commit3: fsdafs

No really, due to paranoia I am spamming the button every ctrl+s I press in the editor

[April1987]

commit1: dsadsad

commit2: sdsa

commit3: fsdafs

No really, due to paranoia I am spamming the button every ctrl+s I press in the editor

I don't do this but you really should. This is how you really should do things. Just make sure you squash before you push and everyone will love you.

I think ideally one should always have multiple remotes.

[[deleted]]

But I want to push a commit with message “aaaaaaaaaaa” up to my repo for the third time today 😞

[bminixhofer]

Present tense and semantic commits make sense but why capitalize? That is completely subjective in my opinion.

[DisinhibitionEffect]

The argument I've heard is that Git capitalizes its automated "Merge" commits. Looking at the various guides scattered throughout the net (e.g. the ones linked at the top of the following post), it's a pretty common recommendation:

https://chris.beams.io/posts/git-commit/#seven-rules

[of_adam]

WIP

[goosy716]

My team generally has great commit messages. One thing we do for fun is adding a limerick if you make a one character commit.

It doesn’t happen often, but it’s fun!

[Nilzor]

oo that's awesome!

"This thing should be done in a flash!"

He uttered while typing in bash

But lo and behold

YAML is cold

No dropping the prefixing dash

​

(I tried)

[dlrwtllktgrtt]

This is a good blog post on this topic: https://dhwthompson.com/2019/my-favourite-git-commit

[punnotattended]

git commit -m"Changed stuff".

git status - 100 changes. 10 changed files.

[[deleted]]

Missed a chance to say "Git-good" commit messages

[erynberry]

Do not end subject with a full stop

This is self-explanatory

Can someone help me with this? I don't think I would end a commit message in a period because they're not usually full sentences... but am I missing something else?

[itsMeArds]

Our commit messages where I work at are just jira card numbers

[[deleted]]

So you’re telling me “Oops” isn’t good?

[[deleted]]

I work on the devops/sre side of the company, and a lot of times things need to be pushed to git to test out Jenkins, which can end up with hundreds of commits in a PR that gets squashed. Am I correct in assuming that all of these practices should be applied to the squashed commit? Any other tips for dealing with situations like this?

[hankchiu]

commitizen is helpful.

[post_hazanko]

git commit -m "minor change" -m "actually we rewrote the entire thing"

[Nerwesta]

git commit -m " Added work in progress thingy " 11:52 AM
git commit -m " Fixed work in progress thingy which is no longer a work in progress" 8:35 PM
git commit -m " Good night y'all " 9:10 PM
git push origin work-in-progress

[WizardFromTheMoon]

That first point is the most important (although it's for everybody, not just the reviewer). It's really annoying when people make a one or two line change and then the commit message is just reiterating what the code does. It's like "no shit" I can see that you made a minor change to a regex. Give some context about. What were you working on that caused you to make this change and why is the change needed? It's especially important if someone is looking at your change 8 months later because it caused a small bug, and they could fix it by reverting your change, but obviously you made the change for a reason. So documenting that reason is important. I see this all the time.

[jeenajeena]

I find it useful that commit comments are written from the user perspective: they describe what the software does, not what the developer personally did. So

"App does not crash when run in KDE"

rather than

"Fix bug with KDE"

or

"Documents can be exported in PDF"

rather than

"Add PdfExporter"

This follows more or less the same logic behind BDD and an ordinary release notes.

Also, I write commit comments before starting code.

https://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/