Skip to main content

Do you use either semantic commit messages or conventional commits?

#EvanPoll #poll

https://www.conventionalcommits.org/en/v1.0.0/
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716


Semantic Commit Messages

Semantic Commit Messages. GitHub Gist: instantly share code, notes, and snippets.
Gist

  • Always (16%, 16 votes)
  • Often (22%, 22 votes)
  • Rarely (23%, 23 votes)
  • Never (37%, 37 votes)
98 voters. Poll end: 1 month ago

#poll #evanpoll
This entry was edited (1 month ago)

Evan Prodromou reshared this.

in reply to Evan Prodromou

Evan Prodromou
Evan Prodromou
• •
i dont know a lot abt the relationship between these formats.
in reply to Evan Prodromou

Tommy Boy :verified:
Tommy Boy :verified:
• •

You just reminded me, I had this bookmarked to share with my nonprofit's interns and I never read it myself yet. So much to learn...

https://dev.to/otienorabin/are-you-writing-your-git-commit-messages-properly-54cl


Are You Writing Your Git Commit Messages Properly?

When it comes to version control, Git is a very effective tool. However, like any other tool you have...
Rabin Otieno (DEV Community)
in reply to Evan Prodromou

Aljoscha Rittner (beandev)
Aljoscha Rittner (beandev)
• •
We (in the companies where I worked) use normal human readable commit messages and only a bug ticket ID. The bug ticket provides the meta data (classification, release management, status handling, group by stories and epics,...).
in reply to Evan Prodromou

mthie
mthie
• •
It's hard to answer an "or" question with these poll answers.
in reply to Evan Prodromou

penryu
penryu
• •
Almost always, because it's not always useful, but a noble endeavor.
in reply to Evan Prodromou

Eric G.
Eric G.
• •
I chose 'often' but its a bit of a lie because the formatting/labeling discipline I have is inconsistent and sloppy.
in reply to Evan Prodromou

Hippo 🍉
Hippo 🍉
• •

I vaguely knew such things were there (especially when I see a lot of people adding `feat:` to the beginning of a message) but I've never bothered to investigate further :git:

I do put effort into making sure my commit messages are descriptive (even in the title); in fact I've often realised during this process that maybe some changes don't belong in the same commit. But if you asked me to describe them I'd guess my messages were more "fun, literary vibes" than "formal, structured" 🤪

This entry was edited (1 month ago)
in reply to Evan Prodromou

ms. liz
ms. liz
• •
100% i use conventional commits, it’s super human-scannable. then one could also automatically parse the meta into a changelog, and other useful automation and documentation. this is essential for large teams and long term maintenance (and future us!)
in reply to Evan Prodromou

ch0ccyra1n :she_her::neocat_floof_cute:
ch0ccyra1n :she_her::neocat_floof_cute:
• •
if a project I'm committing to requires it, sure I do. Otherwise just not my thing. Hence, I picked Rarely
This entry was edited (1 month ago)
in reply to Evan Prodromou

Evan Prodromou
Evan Prodromou
• •
Interesting. My current team uses them and at first I thought they were too precious by half. Then, when I needed to do Changelog files for releases, I got how helpful they are. At the cost of a few seconds of developer time, you can see exactly what happened since the last release. I use them in scripts all the time now. So, Often.
in reply to Evan Prodromou

Emelia 👸🏻
Emelia 👸🏻
• •

used to use them both heavily, and conventional branching and more, but ultimately I've decided the benefits weren't actually worth it.

I rather do manual releases, and I now often prefer merge commits over rebase merges. The format can be a burden to other developers too!

I've even contributed to that tooling before! @stevendotjs can attest to that!

@Steven 🏳️‍🌈
in reply to Evan Prodromou

Olivier Mehani
Olivier Mehani
• •

I do if the project needs it. Mainly for #changelog http://keepachangelog.com/ generation and automatic #semanticVersionning/#semanticRelease https://semantic-release.gitbook.io/semantic-release, but also for many-contributors projects.

I find it helps structure the commit history, too (avid user of interactive-rebase-before-merge here) so each commit is a meaningful set of changes, rather than a baby-uncertain bath+kitchen sink water [pause here, and picture in your mind].

I do this structuring even without semantic commits, but they make the approach explicit.


README | semantic-release

semantic-release.gitbook.io
#changelog #semanticversionning
in reply to Evan Prodromou

Duncan Lock
Duncan Lock
• •
If I'm writing a component or library, i.e. the consumer is a developer, yes. If it's user facing, I write the changelog by hand, from the users point of view.
⇧