feat: support new line chart
fix: update props for new line chart
chore: bump dependency version
What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore etc) to determine the next appropriate version [1].
Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versioning, it just gets you into the habit of thinking about the scope of the commits.
The laughable part about building that full paved road pipeline is that the biggest friction point was always when devs didn't use semantic commits. At the time when I implemented it I didn't have checks for the commit format at the pr phase. I DID have a commitizen cli option as well but that was "Too much friction". Oh boy did I get bit. As someone who was working on DX I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds.
also, +1 on fully paved road approach!
You might want to check out this GitHub Action to enforce PR title matches the spec: https://github.com/amannn/action-semantic-pull-request
I'm not. Writing code and writing git commit messages take entirely different types of thinking. With code you are having to think logically and problem solve to tell the computer what to do. Git messages are more analogous to writing a term paper (though shorter). You have to think about the what you are trying to communicate, how best to describe what this commit is all about, maybe trying to figure out if this counts as a fix or something else, etc. Writing code is fairly easy for me. Writing git commit messages is extremely difficult for me. I sometimes go days without commiting because I'm dreading having to write a commit message.
https://github.com/synek/git-plan
One feature I wanted to add was for it to parse your source code for comments with a specific format (e.g. `# git-plan feat xyz` or `# git-plan fix xyz`) and then stitch all the hunks together into commits for you. So all you'd have to do is comment your code and then run `git plan commit` and it would generate commits for you to confirm with y/n.
I built a prototype of that here:
https://github.com/synek/codeline
I haven't worked these for a while unfortunately :(
The commit messages are meant to be read by humans
It helps get everyone using it familiar quickly despite being annoying as you get used to it.
This is probably more appropriate for private projects rather than public contributed projects perhaps where the benefit of conventional style is to be able to easily create changelogs of large number of commits.
The other thing is that in an internal context, what does knowing whether it's a feature or a bugfix do for you? If it's such a big issue, then it'd be integrated into the issue prefix
BUG-001
FEA-002 < less likely as each feature epic will probably have it's own code, so it'll be more XXXX-001 XXXX-002
Now you have a nice short log that aligns nicely, and you can figure out mostly where your merge points were anyway, so no need for merge commits, rebase works mostly fine.
- BUG-001 fix for this thing
- FEA-005 initial commit
- FEA-005 unit tests
- FEA-005 implement this thing
- FEA-005 implement that thing
- FEA-005 fixes for code review
- BUG-002 fix for another thing
- BUG-002 revert fix did not work
- BUG-003 fix for that annoying thing
Of course, just my 2c and my limited personal experience.
[1] https://github.com/github-changelog-generator/github-changel...
Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.
* [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way.
* [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature
* [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug.
Sometimes I also use:
* [build] -> for build-improvements
* [performance] -> for performance-improvements
Specifically, I'm quite fond of https://gitmoji.dev
- Commit messages are shorter, even with ticket IDs.
- Commit log is easy to read
- Less prone to typos (chroe vs chore)
- Easy to enforce with push rules
- Easy to generate changelogs/release notes
- Easy to measure (metrics)
- Helpful IDE integrations
- It's a bit more fun than conventional commits
See https://github.com/tiangolo/fastapi for an example
Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself.
I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.
> Do I want to clean my house? Yes. Is it still a chore?
> Do you seriously perceive any chores as not worth doing?
None of these are relevant as to whether 'chore' has negative connotations.
It clearly does to me and I'm baffled at the opposition. Do I want to clean my house? No of course not, and you don't either. If your house cleaned itself automatically would you still wish to do it? No, you do it because you need to, not because you want to.
Just about every dictionary definition mentions chores as at least possibly considered negative:
> a hard or unpleasant task: Solving the problem was quite a chore.
([1])
> A chore is a task that you must do but that you find unpleasant or boring.
> She sees exercise primarily as an unavoidable chore.
> Making pasta by hand with a rolling pin can be a real chore.
([2])
An entire article that wouldn't exist if chores were fun activities: [3].
> “Chore” can have a negative connotation and feel like a burden to a child.
[1]: https://www.dictionary.com/browse/chore
[2]: https://www.collinsdictionary.com/dictionary/english/chore
[3]: https://www.nspt4kids.com/parenting/take-the-chore-out-of-do...
If I didn’t do them, my life would be worse than if I didn’t! It’s pretty easy stuff! Embrace the chore, clean up after yourself! It’s worth doing.
Same with bumping versions on dependencies. If I didn’t have to do it I’d love to just get the new features in a non-breaking way. But I can’t, so I do, and it’s a chore.
> Chore: A routine or minor duty or task
Rather than
> Chore: An unpleasant or burdensome task
So "update". Attaching emotionally charged words like "chore" does nobody any favors, and in fact has negative consequences.
What's emotionally charged about this? It seems neutral to me.
Marking it as a simple chore sounds like the impact has not been fully analyzed.
I understand the practice and if done meticulously by all contributors, it should at least signal a well organized project but most of the time, it just shovels your entire commit log as a release notes. It's OK to have it, but I much prefer projects that takes time to summarize the impacts to their users.
chore: resolve a merge conflict
chore: fix code formatting
chore: update dependency type definitions library
Each of these things is nice to have tracked as their own commit so they don’t show up in other more impactful or isolated commits. They don’t add a lot to the code but are rather little house keeping actions that help keep a codebase clean and up to date.
This should never be a standalone commit! A merge conflict is solved by the merge commit, and if you were to override the automatic commit message, this seems like a very information-poor text to replace it with.